draft-ietf-dnsext-gss-tsig-00.txt   draft-ietf-dnsext-gss-tsig-01.txt 
INTERNET-DRAFT Stuart Kwan INTERNET-DRAFT Stuart Kwan
<draft-ietf-dnsext-gss-tsig-00.txt> Praerit Garg <draft-ietf-dnsext-gss-tsig-01.txt> Praerit Garg
James Gilroy James Gilroy
Levon Esibov Levon Esibov
Microsoft Corp. Microsoft Corp.
July 2000 November 22, 2000
Expires January 2001 Expires May 22, 2001
GSS Algorithm for TSIG (GSS-TSIG) GSS Algorithm for TSIG (GSS-TSIG)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 37 skipping to change at page 2, line 37
7: Security Considerations..........................................18 7: Security Considerations..........................................18
8: IANA Considerations..............................................18 8: IANA Considerations..............................................18
9: Conformance......................................................18 9: Conformance......................................................18
10:Acknowledgements.................................................18 10:Acknowledgements.................................................18
11:References.......................................................19 11:References.......................................................19
1. Introduction 1. Introduction
The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol
was developed to provide a lightweight end to end authentication and was developed to provide a lightweight end to end authentication and
integrity off messages between two DNS entities, such as client and integrity of messages between two DNS entities, such as client and
server or server and server. TSIG can be used to protect dynamic update server or server and server. TSIG can be used to protect dynamic update
messages, authenticate regular message or to off-load complicated messages, authenticate regular message or to off-load complicated
DNSSEC [RFC2535] processing from a client to a server and still allow DNSSEC [RFC2535] processing from a client to a server and still allow
the client to be assured of the integrity off the answers. the client to be assured of the integrity off the answers.
The TSIG protocol [RFC2845] is extensible through the definition of new The TSIG protocol [RFC2845] is extensible through the definition of new
algorithms. This document specifies an algorithm based on the Generic algorithms. This document specifies an algorithm based on the Generic
Security Service Application Program Interface (GSS-API) [RFC2743]. Security Service Application Program Interface (GSS-API) [RFC2743].
GSS-API is a framework that provides an abstraction of security to the GSS-API is a framework that provides an abstraction of security to the
application protocol developer. The security services offered can application protocol developer. The security services offered can
skipping to change at page 3, line 16 skipping to change at page 3, line 16
creating and managing a security infrastructure. For example, the creating and managing a security infrastructure. For example, the
developer does not need to create new key distribution or key developer does not need to create new key distribution or key
management systems. Instead the developer relies on the security management systems. Instead the developer relies on the security
service mechanism to manage this on its behalf. service mechanism to manage this on its behalf.
The scope of this document is limited to the description of an The scope of this document is limited to the description of an
authentication mechanism only. It does not discuss and/or propose an authentication mechanism only. It does not discuss and/or propose an
authorization mechanism. Readers that are unfamiliar with GSS-API authorization mechanism. Readers that are unfamiliar with GSS-API
concepts are encouraged to read the characteristics and concepts section concepts are encouraged to read the characteristics and concepts section
of [RFC2743] before examining this protocol in detail. It is also of [RFC2743] before examining this protocol in detail. It is also
assumed that the reader is familiar with [RFC2845], [TKEY], [RFC1034] assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034]
and [RFC1035]. and [RFC1035].
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119 "MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
2. Algorithm Overview 2. Algorithm Overview
In GSS, client and server interact to create a "security context". In GSS, client and server interact to create a "security context".
The security context can be used to create and verify transaction The security context can be used to create and verify transaction
skipping to change at page 4, line 17 skipping to change at page 4, line 17
2.1 GSS Details 2.1 GSS Details
Client and server MUST be locally authenticated and have acquired Client and server MUST be locally authenticated and have acquired
default credentials before using this protocol as specified in default credentials before using this protocol as specified in
Section 1.1.1 "Credentials" in RFC 2743 [RFC2743]. Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
The GSS-TSIG algorithm consists of two stages: The GSS-TSIG algorithm consists of two stages:
I. Establish security context. The Client and Server use the I. Establish security context. The Client and Server use the
GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate the GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate the
tokens that they pass to each other using [TKEY] as a transport tokens that they pass to each other using [RFC2930] as a transport
mechanism. mechanism.
II. Once the security context is established it is used to generate and II. Once the security context is established it is used to generate and
verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. These verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. These
signatures are exchanged by the Client and Server as a part of the TSIG signatures are exchanged by the Client and Server as a part of the TSIG
records exchanged in DNS messages sent between the Client and Server, records exchanged in DNS messages sent between the Client and Server,
as described in [RFC2845]. as described in [RFC2845].
3. Client Protocol Details 3. Client Protocol Details
skipping to change at page 4, line 50 skipping to change at page 4, line 50
In GSS, establishing a security context involves the passing of opaque In GSS, establishing a security context involves the passing of opaque
tokens between the client and the server. The client generates the tokens between the client and the server. The client generates the
initial token and sends it to the server. The server processes the initial token and sends it to the server. The server processes the
token and if necessary, returns a subsequent token to the client. The token and if necessary, returns a subsequent token to the client. The
client processes this token, and so on, until the negotiation is client processes this token, and so on, until the negotiation is
complete. The number of times the client and server exchange tokens complete. The number of times the client and server exchange tokens
depends on the underlying security mechanism. A completed negotiation depends on the underlying security mechanism. A completed negotiation
results in a context handle. results in a context handle.
The TKEY resource record [TKEY] is used as the vehicle to transfer The TKEY resource record [RFC2930] is used as the vehicle to transfer
tokens between client and server. The TKEY record is a general tokens between client and server. The TKEY record is a general
mechanism for establishing secret keys for use with TSIG. For more mechanism for establishing secret keys for use with TSIG. For more
information, see [TKEY]. information, see [RFC2930].
3.1.1 Call GSS_Init_sec_context 3.1.1 Call GSS_Init_sec_context
To obtain the first token to be sent to a server, a client MUST call To obtain the first token to be sent to a server, a client MUST call
GSS_Init_sec_context API. GSS_Init_sec_context API.
The following input parameters MUST be used. The outcome of the call is The following input parameters MUST be used. The outcome of the call is
indicated with the output values below. Consult Sections 2.2.1 indicated with the output values below. Consult Sections 2.2.1
"GSS_Init_sec_context call" of [RFC2743] for syntax definitions. "GSS_Init_sec_context call" of [RFC2743] for syntax definitions.
INPUTS INPUTS
CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
default"). Client MAY instead specify some other valid handle default"). Client MAY instead specify some other valid handle
to its credentials. to its credentials.
CONTEXT HANDLE input_context_handle = 0 CONTEXT HANDLE input_context_handle = 0
INTERNAL NAME targ_name = "DNS/<target_server_name>" INTERNAL NAME targ_name = "DNS@<target_server_name>"
OBJECT IDENTIFIER mech_type = Underlying security OBJECT IDENTIFIER mech_type = Underlying security
mechanism chosen by implementers. To guarantee mechanism chosen by implementers. To guarantee
interoperability of the implementations of the GSS-TSIG interoperability of the implementations of the GSS-TSIG
mechanism client MUST specify a valid underlying security mechanism client MUST specify a valid underlying security
mechanism that enables use of Kerberos v5. mechanism that enables use of Kerberos v5 (see Section 9 for
more information).
OCTET STRING input_token = NULL OCTET STRING input_token = NULL
BOOLEAN replay_det_req_flag = TRUE BOOLEAN replay_det_req_flag = TRUE
BOOLEAN mutual_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE
BOOLEAN deleg_req_flag = TRUE BOOLEAN deleg_req_flag = TRUE
BOOLEAN sequence_req_flag = TRUE BOOLEAN sequence_req_flag = TRUE
BOOLEAN anon_req_flag = FALSE BOOLEAN anon_req_flag = FALSE
BOOLEAN conf_req_flag = TRUE BOOLEAN conf_req_flag = TRUE
BOOLEAN integ_req_flag = TRUE BOOLEAN integ_req_flag = TRUE
INTEGER lifetime_req = 0 (0 requests a default INTEGER lifetime_req = 0 (0 requests a default
value). Client MAY instead specify another upper bound for the value). Client MAY instead specify another upper bound for the
skipping to change at page 6, line 48 skipping to change at page 6, line 48
3.1.2 Send TKEY Query to Server 3.1.2 Send TKEY Query to Server
An opaque output_token returned by GSS_Init_sec_context is transmitted An opaque output_token returned by GSS_Init_sec_context is transmitted
to the server in a query request with QTYPE=TKEY. The token itself to the server in a query request with QTYPE=TKEY. The token itself
will be placed in a Key Data field of the RDATA field in the TKEY will be placed in a Key Data field of the RDATA field in the TKEY
resource record in the additional records section of the query. The resource record in the additional records section of the query. The
owner name of the TKEY resource record set queried for and the owner owner name of the TKEY resource record set queried for and the owner
name of the supplied TKEY resource record in the additional records name of the supplied TKEY resource record in the additional records
section MUST be the same. This name uniquely identifies the security section MUST be the same. This name uniquely identifies the security
context to both the client and server, and thus the client SHOULD use context to both the client and server, and thus the client SHOULD use
a value which is globally unique as described in [TKEY]. a value which is globally unique as described in [RFC2930].
TKEY Record TKEY Record
NAME = client-generated globally unique domain name string NAME = client-generated globally unique domain name string
(as described in [TKEY]) (as described in [RFC2930])
RDATA RDATA
Algorithm Name = gss-tsig Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [TKEY]) Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets Key Size = size of output_token in octets
Key Data = output_token Key Data = output_token
The remaining fields in the TKEY RDATA, i.e. Inception, Expiration, The remaining fields in the TKEY RDATA, i.e. Inception, Expiration,
Error, Other Size and Data Fields, MUST be set according to [TKEY]. Error, Other Size and Data Fields, MUST be set according to [RFC2930].
The query is transmitted to the server. The query is transmitted to the server.
Note: if the original client call to GSS_Init_sec_context returned any Note: if the original client call to GSS_Init_sec_context returned any
major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then
the client MUST NOT send TKEY query. the client MUST NOT send TKEY query.
3.1.3 Receive TKEY Query-Response from Server 3.1.3 Receive TKEY Query-Response from Server
Upon the reception of the TKEY query DNS server MUST respond according Upon the reception of the TKEY query DNS server MUST respond according
skipping to change at page 10, line 37 skipping to change at page 10, line 37
context_handle matching context_handle matching
key_name if ongoing negotiation key_name if ongoing negotiation
OCTET STRING input_token = token specified in the Key OCTET STRING input_token = token specified in the Key
field from TKEY RR (from Additional records Section of field from TKEY RR (from Additional records Section of
the client's query) the client's query)
CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
default"). Server MAY instead specify some other valid handle default"). Server MAY instead specify some other valid handle
to its credentials. to its credentials.
OCTET STRING chan_bindings = Any valid channel bindings OCTET STRING chan_bindings = Any valid channel bindings
as specified in Section 1.1.6 "Channel Bindings" in [RFC2734] as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
OUTPUTS OUTPUTS
INTEGER major_status INTEGER major_status
CONTEXT_HANDLE output_context_handle CONTEXT_HANDLE output_context_handle
OCTET STRING output_token OCTET STRING output_token
INTEGER minor_status INTEGER minor_status
INTERNAL NAME src_name INTERNAL NAME src_name
OBJECT IDENTIFIER mech_type OBJECT IDENTIFIER mech_type
BOOLEAN deleg_state BOOLEAN deleg_state
BOOLEAN mutual_state BOOLEAN mutual_state
skipping to change at page 12, line 10 skipping to change at page 12, line 10
TKEY record containing output_token in the Key Data RDATA field. The TKEY record containing output_token in the Key Data RDATA field. The
error field in the TKEY record is set to NOERROR. The server MUST limit error field in the TKEY record is set to NOERROR. The server MUST limit
the number of times that a given context is allowed to repeat, to the number of times that a given context is allowed to repeat, to
prevent endless looping. Such limit SHOULD NOT exceed value of 10. prevent endless looping. Such limit SHOULD NOT exceed value of 10.
In all cases except if major_status is GSS_S_COMPLETE and output_token In all cases except if major_status is GSS_S_COMPLETE and output_token
is NULL other TKEY record fields MUST contain the following values: is NULL other TKEY record fields MUST contain the following values:
NAME = key_name NAME = key_name
RDATA RDATA
Algorithm Name = gss-tsig Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [TKEY]) Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets Key Size = size of output_token in octets
The remaining fields in the TKEY RDATA, i.e. Inception, Expiration, The remaining fields in the TKEY RDATA, i.e. Inception, Expiration,
Error, Other Size and Data Fields, MUST be set according to [TKEY]. Error, Other Size and Data Fields, MUST be set according to [RFC2930].
4.2 Context Established 4.2 Context Established
When context negotiation is complete, the handle context_handle When context negotiation is complete, the handle context_handle
is used for the generation and verification of transaction signatures. is used for the generation and verification of transaction signatures.
The handle is valid for a finite amount of time determined by the The handle is valid for a finite amount of time determined by the
underlying security mechanism. A server MAY unilaterally terminate underlying security mechanism. A server MAY unilaterally terminate
a context at any time (see section 4.2.1). a context at any time (see section 4.2.1).
The procedures for sending and receiving signed messages are given in The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages. section 5, Sending and Verifying Signed Messages.
4.2.1 Terminating a Context 4.2.1 Terminating a Context
A server can terminate any established context at any time. The A server can terminate any established context at any time. The
server MAY hint to the client that the context is being deleted server MAY hint to the client that the context is being deleted
by including a TKEY RR in a response with the Mode field set to 5, i.e. by including a TKEY RR in a response with the Mode field set to 5, i.e.
"key deletion" [TKEY]. "key deletion" [RFC2930].
An active context is deleted by calling GSS_Delete_sec_context An active context is deleted by calling GSS_Delete_sec_context
providing the associated context_handle. providing the associated context_handle.
5. Sending and Verifying Signed Messages 5. Sending and Verifying Signed Messages
5.1 Sending a Signed Message - Call GSS_GetMIC 5.1 Sending a Signed Message - Call GSS_GetMIC
The procedure for sending a signature-protected message is specified The procedure for sending a signature-protected message is specified
in [RFC2845]. The data to be passed to the signature routine includes in [RFC2845]. The data to be passed to the signature routine includes
the whole DNS message with specific TSIG variables appended. For the the whole DNS message with specific TSIG variables appended. For the
skipping to change at page 15, line 37 skipping to change at page 15, line 37
II. Client sends a query with QTYPE = TKEY to server II. Client sends a query with QTYPE = TKEY to server
Client sends a query with QTYPE = TKEY for a client-generated globally Client sends a query with QTYPE = TKEY for a client-generated globally
unique domain name string, 789.client.example.com.server.example.com. unique domain name string, 789.client.example.com.server.example.com.
Query contains a TKEY record in its Additional records section with Query contains a TKEY record in its Additional records section with
the following fields (Note that some fields not specific to this the following fields (Note that some fields not specific to this
algorithm are not specified) algorithm are not specified)
NAME = 789.client.example.com.server.example.com. NAME = 789.client.example.com.server.example.com.
RDATA RDATA
Algorithm Name = gss-tsig Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [TKEY]) Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets Key Size = size of output_token in octets
Key Data = output_token Key Data = output_token
After the key_name 789.client.example.com.server.example.com. After the key_name 789.client.example.com.server.example.com.
is generated it is stored in the client's (target_name, key_name, is generated it is stored in the client's (target_name, key_name,
context_handle) mapping table. context_handle) mapping table.
III. Server receives a query with QTYPE = TKEY III. Server receives a query with QTYPE = TKEY
When server receives a query with QTYPE = TKEY, the server verifies When server receives a query with QTYPE = TKEY, the server verifies
that Mode and Algorithm fields in the TKEY record in the Additional that Mode and Algorithm fields in the TKEY record in the Additional
skipping to change at page 17, line 14 skipping to change at page 17, line 14
VII. Client sends a query with QTYPE = TKEY to server VII. Client sends a query with QTYPE = TKEY to server
Client sends to the server a TKEY query for the Client sends to the server a TKEY query for the
789.client.example.com.server.example.com. name. Query contains a TKEY 789.client.example.com.server.example.com. name. Query contains a TKEY
record in its Additional records section with the following fields record in its Additional records section with the following fields
(Note that some INPUT and OUTPUT parameters not critical to this (Note that some INPUT and OUTPUT parameters not critical to this
algorithm are not described in this example) algorithm are not described in this example)
NAME = 789.client.example.com.server.example.com. NAME = 789.client.example.com.server.example.com.
RDATA RDATA
Algorithm Name = gss-tsig Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [TKEY]) Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets Key Size = size of output_token in octets
Key Data = output_token Key Data = output_token
VIII. Server receives a TKEY query VIII. Server receives a TKEY query
When the server receives a TKEY query, the server verifies that Mode When the server receives a TKEY query, the server verifies that Mode
and Algorithm fields in the TKEY record in the Additional records and Algorithm fields in the TKEY record in the Additional records
section of the query are set to 3 and gss-tsig, repectively. It section of the query are set to 3 and gss-tsig, repectively. It
finds that the key_name 789.client.example.com.server.example.com. is finds that the key_name 789.client.example.com.server.example.com. is
listed in its (key_name, context_handle) mapping table. listed in its (key_name, context_handle) mapping table.
skipping to change at page 19, line 15 skipping to change at page 19, line 15
8. IANA Considerations 8. IANA Considerations
The authors request that the IANA reserve the TSIG Algorithm name The authors request that the IANA reserve the TSIG Algorithm name
gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource
records. This Algorithm name refers to the algorithm described in this records. This Algorithm name refers to the algorithm described in this
document. The requirement to have this name registered with IANA is document. The requirement to have this name registered with IANA is
specified in RFC 2845. specified in RFC 2845.
9. Conformance 9. Conformance
The GSS API provides maximum flexibility to choose the underlying The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
security mechanisms that enables security context negotiation. GSS API choose the underlying security mechanisms that enables security context
enables client and server to negotiate and choose such underlying negotiation. GSS API using SPNEGO [RFC2478] enables client and server to
security mechanisms on the fly. At the same time, in order to guarantee negotiate and choose such underlying security mechanisms on the fly. To
interoperability between clients and servers that support GSS-TSIG it is support such flexibility, DNS clients and servers SHOULD specify SPNEGO
required that a GSS APIs called by such client and server MUST support mech_type in their GSS API calls. At the same time, in order to
Kerberos v5 as an underlying security mechanisms. In addition to this, guarantee interoperability between DNS clients and servers that support
GSS APIs used by client and server MAY also support other underlying GSS-TSIG it is required that
security mechanisms. - DNS servers specify SPNEGO mech_type
- GSS APIs called by DNS client support Kerberos v5
- GSS APIs called by DNS server support SPNEGO [RFC2478] and
Kerberos v5.
In addition to these, GSS APIs used by DNS client and server MAY also
support other underlying security mechanisms.
10. Acknowledgements 10. Acknowledgements
The authors of this document would like to thank the following people The authors of this document would like to thank the following people
for their contribution to this specification: Chuck Chan, Mike Swift, for their contribution to this specification: Chuck Chan, Mike Swift,
Ram Viswanathan, Olafur Gudmundsson and Donald E. Eastlake 3rd. Ram Viswanathan, Olafur Gudmundsson and Donald E. Eastlake 3rd.
11. References 11. References
[RFC2743] J. Linn, "Generic Security Service Application Program [RFC2743] J. Linn, "Generic Security Service Application Program
Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories, Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories,
January 2000. January 2000.
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Signatures for DNS (TSIG)," RFC 2845, "Secret Key Transaction Signatures for DNS (TSIG)", RFC 2845,
ISC, NAI Labs, Motorola, Nominum, May, 2000, ISC, NAI Labs, Motorola, Nominum, May, 2000,
[TKEY] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY [RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)",
RR)," draft-ietf-dnsext-tkey-*.txt. RFC 2930, Motorola, September 2000.
[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions," [RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
RFC 2535, IBM, March 1999. RFC 2535, IBM, March 1999.
[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update," [RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
RFC 2137, CyberCash, April 1997. RFC 2137, CyberCash, April 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 20, line 16 skipping to change at page 20, line 22
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1034, November 1987. Specification", STD 13, RFC 1034, November 1987.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, OpenVision Technologies, June 1996. RFC 1964, OpenVision Technologies, June 1996.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
RFC 2025, Bell-Northern Research, October 1996. RFC 2025, Bell-Northern Research, October 1996.
[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, Bull, December 1998.
12. Author's Addresses 12. Author's Addresses
Stuart Kwan Praerit Garg Stuart Kwan Praerit Garg
Microsoft Corporation Microsoft Corporation Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052 Redmond, WA 98052 Redmond, WA 98052
USA USA USA USA
skwan@microsoft.com skwan@microsoft.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/