draft-ietf-dnsext-gss-tsig-03.txt   draft-ietf-dnsext-gss-tsig-04.txt 
INTERNET-DRAFT Stuart Kwan INTERNET-DRAFT Stuart Kwan
<draft-ietf-dnsext-gss-tsig-03.txt> Praerit Garg <draft-ietf-dnsext-gss-tsig-04.txt> Praerit Garg
September 20, 2001 James Gilroy November 19, 2001 James Gilroy
Expires March 20, 2002 Levon Esibov Expires May 19, 2002 Levon Esibov
Jeff Westhead Jeff Westhead
Microsoft Corp. Microsoft Corp.
Randy Hall Randy Hall
Lucent Technologies Lucent Technologies
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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
6: Example usage of GSS-TSIG algorithm..............................15 6: Example usage of GSS-TSIG algorithm..............................15
7: Security Considerations..........................................19 7: Security Considerations..........................................19
8: IANA Considerations..............................................19 8: IANA Considerations..............................................19
9: Conformance......................................................19 9: Conformance......................................................19
10:Acknowledgements.................................................20 10:Acknowledgements.................................................20
11:References.......................................................20 11:References.......................................................20
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 authentication and integrity of
integrity of messages between two DNS entities, such as client and messages between two DNS entities, such as client and server or server
server or server and server. TSIG can be used to protect dynamic update and server. TSIG can be used to protect dynamic update messages,
messages, authenticate regular message or to off-load complicated authenticate regular message or to off-load complicated DNSSEC
DNSSEC [RFC2535] processing from a client to a server and still allow [RFC2535] processing from a client to a server and still allow the
the client to be assured of the integrity off the answers. 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
include authentication, integrity, and confidentiality. include authentication, integrity, and confidentiality.
The GSS-API framework has several benefits: The GSS-API framework has several benefits:
* Mechanism and protocol independence. The underlying mechanisms that * Mechanism and protocol independence. The underlying mechanisms that
realize the security services can be negotiated on the fly and varied realize the security services can be negotiated on the fly and varied
over time. For example, a client and server may use Kerberos [RFC1964] over time. For example, a client and server MAY use Kerberos [RFC1964]
for one transaction, whereas that same server may use SPKM [RFC2025] for one transaction, whereas that same server MAY use SPKM [RFC2025]
with a different client. with a different client.
* The protocol developer is removed from the responsibility of * The protocol developer is removed from the responsibility of
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], [RFC2930], [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", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"MAY" in this document are to be interpreted as described in RFC 2119 "RECOMMENDED", and "MAY" in this document are to be interpreted as
[RFC2119]. described in RFC 2119 [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
signatures on messages between the two parties. A unique security signatures on messages between the two parties. A unique security
context is required for each unique connection between client and context is required for each unique connection between client and
server. server.
Creating a security context involves a negotiation between client and Creating a security context involves a negotiation between client and
skipping to change at page 4, line 39 skipping to change at page 4, line 39
secure messages. A context is identified by a context handle. A secure messages. A context is identified by a context handle. A
client maintains a mapping of servers to handles, client maintains a mapping of servers to handles,
(target_name, key_name, context_handle) (target_name, key_name, context_handle)
The value key_name also identifies a context handle. The key_name is The value key_name also identifies a context handle. The key_name is
the owner name of the TKEY and TSIG records sent between a client and a the owner name of the TKEY and TSIG records sent between a client and a
server to indicate to each other which context MUST be used to process server to indicate to each other which context MUST be used to process
the current request. the current request.
DNS client and server MAY use various underlying security mechanisms to
establish security context as described in sections 3 and 4. At the
same time, in order to guarantee interoperability between DNS clients
and servers that support GSS-TSIG it is required that security
mechanism used by client enables use of Kerberos v5 (see Section 9
for more information).
3.1 Negotiating Context 3.1 Negotiating Context
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 [RFC2930] 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 [RFC2930]. information, see [RFC2930].
3.1.1 Call GSS_Init_sec_context 3.1.1 Call GSS_Init_sec_context
skipping to change at page 7, line 47 skipping to change at page 7, line 47
then the client side component of the negotiation is complete and the then the client side component of the negotiation is complete and the
client is awaiting confirmation from the server. client is awaiting confirmation from the server.
Confirmation is in the form of a query response with RCODE=NOERROR Confirmation is in the form of a query response with RCODE=NOERROR
and with the last client supplied TKEY record in the answer section and with the last client supplied TKEY record in the answer section
of the query. The response MUST be signed with a TSIG record. The of the query. The response MUST be signed with a TSIG record. The
signature in the TSIG record MUST be verified using the procedure signature in the TSIG record MUST be verified using the procedure
detailed in section 5, Sending and Verifying Signed Messages. If the detailed in section 5, Sending and Verifying Signed Messages. If the
response is not signed, OR if the response is signed but signature is response is not signed, OR if the response is signed but signature is
invalid, then an attacker has tampered with the message in transit or invalid, then an attacker has tampered with the message in transit or
has attempted to send the client a false response. The client MUST has attempted to send the client a false response. The client MAY
continue waiting for a response to its last TKEY query until the time continue waiting for a response to its last TKEY query until the time
period since the client sent last TKEY query expires. Such a time period period since the client sent last TKEY query expires. Such a time period
is specified by the policy local to the client. is specified by the policy local to the client. This is a new option
that allows DNS client to accept multiple answers for one query ID and
select one (not necessarily the first one) based on some criteria.
If the signature is verified the context state is advanced to Context If the signature is verified the context state is advanced to Context
Established. Proceed to section 3.2 for usage of the security context. Established. Proceed to section 3.2 for usage of the security context.
3.1.3.2 Value of major_status == GSS_S_CONTINUE 3.1.3.2 Value of major_status == GSS_S_CONTINUE
If the last call to GSS_Init_sec_context yielded a major_status value If the last call to GSS_Init_sec_context yielded a major_status value
of GSS_S_CONTINUE, then the negotiation is not yet complete. The server of GSS_S_CONTINUE, then the negotiation is not yet complete. The server
will return to the client a query-response with a TKEY record in the will return to the client a query-response with a TKEY record in the
Answer section. If the DNS message error is not NO_ERROR or error field Answer section. If the DNS message error is not NO_ERROR or error field
in the TKEY record is not 0 (i.e. no error), then the client MUST in the TKEY record is not 0 (i.e. no error), then the client MUST
abandon this negotiation sequence. The client MUST delete an active abandon this negotiation sequence. The client MUST delete an active
context by calling GSS_Delete_sec_context providing the associated context by calling GSS_Delete_sec_context providing the associated
context_handle. The client MAY repeat the negotiation sequence starting context_handle. The client MAY repeat the negotiation sequence starting
with the uninitialized state as described in section 3.1. To prevent with the uninitialized state as described in section 3.1. To prevent
infinite looping the number of attempts to establish a security context infinite looping the number of attempts to establish a security context
must be limited. MUST be limited to ten or less.
If the DNS message error is NO_ERROR and error filed in the TKEY record If the DNS message error is NO_ERROR and error filed in the TKEY record
is 0 (i.e. no error), then the client MUST pass a token specified in the is 0 (i.e. no error), then the client MUST pass a token specified in the
Key Data field in the TKEY resource record to GSS_Init_sec_context Key Data field in the TKEY resource record to GSS_Init_sec_context
using the same parameters values as in previous call except values for using the same parameters values as in previous call except values for
CONTEXT HANDLE input_context_handle and OCTET STRING input_token as CONTEXT HANDLE input_context_handle and OCTET STRING input_token as
described below: described below:
INPUTS INPUTS
CONTEXT HANDLE input_context_handle = context_handle (this is the CONTEXT HANDLE input_context_handle = context_handle (this is the
skipping to change at page 9, line 10 skipping to change at page 9, line 10
GSS_S_BAD_NAMETYPE GSS_S_BAD_NAMETYPE
GSS_S_BAD_NAME GSS_S_BAD_NAME
GSS_S_BAD_MECH GSS_S_BAD_MECH
GSS_S_FAILURE GSS_S_FAILURE
the client MUST abandon this negotiation sequence. The client MUST the client MUST abandon this negotiation sequence. The client MUST
delete an active context by calling GSS_Delete_sec_context providing delete an active context by calling GSS_Delete_sec_context providing
the associated context_handle. The client MAY repeat the negotiation the associated context_handle. The client MAY repeat the negotiation
sequence starting with the uninitialized state as described in section sequence starting with the uninitialized state as described in section
3.1. To prevent infinite looping the number of attempts to establish a 3.1. To prevent infinite looping the number of attempts to establish a
security context must be limited. security context MUST be limited to ten or less.
If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then
client MUST act as described below. client MUST act as described below.
If the response from the server was signed, and the OUTPUT major_status If the response from the server was signed, and the OUTPUT major_status
is GSS_S_COMPLETE,then the signature in the TSIG record MUST be verified is GSS_S_COMPLETE,then the signature in the TSIG record MUST be verified
using the procedure detailed in section 5, Sending and Verifying Signed using the procedure detailed in section 5, Sending and Verifying Signed
Messages. If the signature is invalid, then the client MUST abandon this Messages. If the signature is invalid, then the client MUST abandon this
negotiation sequence. The client MUST delete an active context by negotiation sequence. The client MUST delete an active context by
calling GSS_Delete_sec_context providing the associated context_handle. calling GSS_Delete_sec_context providing the associated context_handle.
The client MAY repeat the negotiation sequence starting with the The client MAY repeat the negotiation sequence starting with the
uninitialized state as described in section 3.1. To prevent infinite uninitialized state as described in section 3.1. To prevent infinite
looping the number of attempts to establish a security context must be looping the number of attempts to establish a security context MUST be
limited. limited to ten or less.
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
finished. The token output_token MUST be passed to the server in a TKEY finished. The token output_token MUST be passed to the server in a TKEY
record by repeating the negotiation sequence beginning with section record by repeating the negotiation sequence beginning with section
3.1.2. The client MUST place a limit on the number of continuations in 3.1.2. The client MUST place a limit on the number of continuations in
a context negotiation to prevent endless looping. Such limit SHOULD NOT a context negotiation to prevent endless looping. Such limit SHOULD NOT
exceed value of 10. exceed value of 10.
If major_status is GSS_S_COMPLETE and output_token is non-NULL, the If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
client-side component of the negotiation is complete but the token client-side component of the negotiation is complete but the token
skipping to change at page 19, line 33 skipping to change at page 19, line 33
client and server will use the established security context to sign client and server will use the established security context to sign
and validate the signatures when they exchange packets with each and validate the signatures when they exchange packets with each
other until the context expires. other until the context expires.
7. Security Considerations 7. Security Considerations
This document describes a protocol for DNS security using GSS-API. This document describes a protocol for DNS security using GSS-API.
The security provided by this protocol is only as effective as the The security provided by this protocol is only as effective as the
security provided by the underlying GSS mechanisms. security provided by the underlying GSS mechanisms.
All the security considerations from RFC2845, RFC2930 and RFC 2743
apply to the protocol described in this document.
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
skipping to change at page 21, line 16 skipping to change at page 21, line 16
Interconnection", "Remote Procedure Call", Interconnection", "Remote Procedure Call",
ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html. ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html.
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 praeritg@microsoft.com
James Gilroy Levon Esibov James Gilroy Levon Esibov
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
levone@microsoft.com jamesg@microsoft.com levone@microsoft.com
Randy Hall Jeff Westhead Randy Hall Jeff Westhead
Lucent Technologies Microsoft Corporation Lucent Technologies Microsoft Corporation
400 Lapp Road One Microsoft Way 400 Lapp Road One Microsoft Way
Malvern PA 19355 Redmond, WA 98052 Malvern PA 19355 Redmond, WA 98052
USA USA USA USA
randyhall@lucent.com randyhall@lucent.com jwesth@microsoft.com
 End of changes. 

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