draft-ietf-dnsext-gss-tsig-04.txt   draft-ietf-dnsext-gss-tsig-05.txt 
INTERNET-DRAFT Stuart Kwan INTERNET-DRAFT Stuart Kwan
<draft-ietf-dnsext-gss-tsig-04.txt> Praerit Garg <draft-ietf-dnsext-gss-tsig-05.txt> Praerit Garg
November 19, 2001 James Gilroy January 30, 2002 James Gilroy
Expires May 19, 2002 Levon Esibov Expires July 30, 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 36 skipping to change at page 2, line 36
5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............14 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............14
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 Authentication for DNS (TSIG) [RFC2845]
was developed to provide a lightweight authentication and integrity of protocol was developed to provide a lightweight authentication and
messages between two DNS entities, such as client and server or server integrity of messages between two DNS entities, such as client and
and server. TSIG can be used to protect dynamic update messages, server or server and server. TSIG can be used to protect dynamic
authenticate regular message or to off-load complicated DNSSEC update messages, authenticate regular message or to off-load
[RFC2535] processing from a client to a server and still allow the complicated DNSSEC [RFC2535] processing from a client to a server and
client to be assured of the integrity off the answers. still allow the client to be assured of the integrity of 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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
(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 DNS client and server MAY use various underlying security mechanisms to
establish security context as described in sections 3 and 4. At the establish security context as described in sections 3 and 4. At the
same time, in order to guarantee interoperability between DNS clients same time, in order to guarantee interoperability between DNS clients
and servers that support GSS-TSIG it is required that security and servers that support GSS-TSIG it is REQUIRED that security
mechanism used by client enables use of Kerberos v5 (see Section 9 mechanism used by client enables use of Kerberos v5 (see Section 9
for more information). 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
skipping to change at page 6, line 10 skipping to change at page 6, line 10
OBJECT IDENTIFIER mech_type OBJECT IDENTIFIER mech_type
BOOLEAN deleg_state BOOLEAN deleg_state
BOOLEAN sequence_state BOOLEAN sequence_state
BOOLEAN anon_state BOOLEAN anon_state
BOOLEAN trans_state BOOLEAN trans_state
BOOLEAN prot_ready_state BOOLEAN prot_ready_state
BOOLEAN conf_avail BOOLEAN conf_avail
BOOLEAN integ_avail BOOLEAN integ_avail
INTEGER lifetime_rec INTEGER lifetime_rec
The client MUST abandon the algorithm if returned major_status is set to If returned major_status is set to one of the following errors
one of the following errors:
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_TOKEN
GSS_S_DEFECTIVE_CREDENTIAL GSS_S_DEFECTIVE_CREDENTIAL
GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_BAD_SIG (GSS_S_BAD_MIC)
GSS_S_NO_CRED GSS_S_NO_CRED
GSS_S_CREDENTIALS_EXPIRED GSS_S_CREDENTIALS_EXPIRED
GSS_S_BAD_BINDINGS GSS_S_BAD_BINDINGS
GSS_S_OLD_TOKEN GSS_S_OLD_TOKEN
GSS_S_DUPLICATE_TOKEN GSS_S_DUPLICATE_TOKEN
GSS_S_NO_CONTEXT GSS_S_NO_CONTEXT
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
then the the client MUST abandon the algorithm and MUST NOT use the
GSS-TSIG algorithm to establish this security contex. This document
does not prescribe which other mechanism could be used to establish
a security context. Next time when this client needs to establish
security context, the client MAY use GSS-TSIG algorithm.
Success values of major_status are GSS_S_CONTINUE_NEEDED and Success values of major_status are GSS_S_CONTINUE_NEEDED and
GSS_S_COMPLETE. The exact success code is important during later GSS_S_COMPLETE. The exact success code is important during later
processing. processing.
The values of replay_det_state and mutual_state indicate if the The values of replay_det_state and mutual_state indicate if the
security package provides replay detection and mutual authentication, security package provides replay detection and mutual authentication,
respectively. If returned major_status is GSS_S_COMPLETE AND one or both respectively. If returned major_status is GSS_S_COMPLETE AND one or both
of these values are FALSE, the client MUST abandon this algorithm. of these values are FALSE, the client MUST abandon this algorithm.
Client's behavior MAY depend on other OUTPUT parameters according Client's behavior MAY depend on other OUTPUT parameters according
skipping to change at page 7, line 21 skipping to change at page 7, line 27
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 [RFC2930]. 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. Client's behavior in this case is
described above in Section 3.1.1.
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
to the description in Section 4. This Section specifies the behavior to the description in Section 4. This Section specifies the behavior
of the client after it receives the matching response to its query. of the client after it receives the matching response to its query.
The next processing step depends on the value of major_status from the The next processing step depends on the value of major_status from the
most recent call that client performed to GSS_Init_sec_context: either most recent call that client performed to GSS_Init_sec_context: either
GSS_S_COMPLETE or GSS_S_CONTINUE. GSS_S_COMPLETE or GSS_S_CONTINUE.
skipping to change at page 7, line 47 skipping to change at page 7, line 54
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 MAY has attempted to send the client a false response. In this case the
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 client MAY continue waiting for a response to its last TKEY query until
is specified by the policy local to the client. This is a new option the time period since the client sent last TKEY query expires. Such a
that allows DNS client to accept multiple answers for one query ID and time period is specified by the policy local to the client. This is a
select one (not necessarily the first one) based on some criteria. 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
skipping to change at page 9, line 5 skipping to change at page 9, line 12
GSS_S_CREDENTIALS_EXPIRED GSS_S_CREDENTIALS_EXPIRED
GSS_S_BAD_BINDINGS GSS_S_BAD_BINDINGS
GSS_S_OLD_TOKEN GSS_S_OLD_TOKEN
GSS_S_DUPLICATE_TOKEN GSS_S_DUPLICATE_TOKEN
GSS_S_NO_CONTEXT GSS_S_NO_CONTEXT
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. This means that the
delete an active context by calling GSS_Delete_sec_context providing client MUST delete an active context by calling GSS_Delete_sec_context
the associated context_handle. The client MAY repeat the negotiation providing the associated context_handle. The client MAY repeat the
sequence starting with the uninitialized state as described in section negotiation sequence starting with the uninitialized state as described
3.1. To prevent infinite looping the number of attempts to establish a in section 3.1. To prevent infinite looping the number of attempts to
security context MUST be limited to ten or less. establish a 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. This means that the client MUST delete an active
calling GSS_Delete_sec_context providing the associated context_handle. context by calling GSS_Delete_sec_context providing the associated
The client MAY repeat the negotiation sequence starting with the context_handle. The client MAY repeat the negotiation sequence starting
uninitialized state as described in section 3.1. To prevent infinite with the uninitialized state as described in section 3.1. To prevent
looping the number of attempts to establish a security context MUST be infinite looping the number of attempts to establish a security context
limited to ten or less. MUST be 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 10, line 43 skipping to change at page 10, line 43
Upon receiving a query with QTYPE = TKEY, the server MUST examine Upon receiving a query with QTYPE = TKEY, the server MUST examine
whether the Mode and Algorithm Name fields of the TKEY record in the whether the Mode and Algorithm Name fields of the TKEY record in the
additional records section of the message contain values of 3 and additional records section of the message contain values of 3 and
gss-tsig, respectively. If they do, then the (key_name, context_handle) gss-tsig, respectively. If they do, then the (key_name, context_handle)
mapping table is searched for the key_name matching the owner name of mapping table is searched for the key_name matching the owner name of
the TKEY record in the additional records section of the query. If the the TKEY record in the additional records section of the query. If the
name is found in the table and the security context for this name is name is found in the table and the security context for this name is
established and not expired, then the server MUST respond to the query established and not expired, then the server MUST respond to the query
with BADNAME error in the TKEY error field. If the name is found in the with BADNAME error in the TKEY error field. If the name is found in the
table and the security context is not established, the corresponding table and the security context is not established, the corresponding
context_handle is used in subsequent GSS operations. If the name is not context_handle is used in subsequent GSS operations. If the name is
found but the security context is expired, then the server deletes this
security context, as described in Section 4.2.1, and interprets this
query as a start of new security context negotiation and performs
operations described in Section 4.1.2 and 4.1.3. If the name is not
found, then the server interprets this query as a start of new security found, then the server interprets this query as a start of new security
context negotiation. context negotiation and performs operations described in Section 4.1.2
and 4.1.3.
4.1.2 Call GSS_Accept_sec_context 4.1.2 Call GSS_Accept_sec_context
The server performs its side of a context negotiation by calling The server performs its side of a context negotiation by calling
GSS_Accept_sec_context. The following input parameters MUST be used. The GSS_Accept_sec_context. The following input parameters MUST be used. The
outcome of the call is indicated with the output values below. Consult outcome of the call is indicated with the output values below. Consult
Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743[RFC2743] Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743[RFC2743]
for syntax definitions. for syntax definitions.
INPUTS INPUTS
skipping to change at page 20, line 17 skipping to change at page 20, line 17
- GSS APIs called by DNS server support SPNEGO [RFC2478] and - GSS APIs called by DNS server support SPNEGO [RFC2478] and
Kerberos v5. Kerberos v5.
In addition to these, GSS APIs used by DNS client and server MAY also In addition to these, GSS APIs used by DNS client and server MAY also
support other underlying security mechanisms. 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, Donald E. Eastlake 3rd and Erik
Nordmark.
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 Authentication for DNS (TSIG)",
ISC, NAI Labs, Motorola, Nominum, May, 2000, RFC 2845, ISC, NAI Labs, Motorola, Nominum, May, 2000,
[RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)", [RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, Motorola, September 2000. 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.
 End of changes. 

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