< draft-ietf-dnsext-gss-tsig-05.txt   draft-ietf-dnsext-gss-tsig-06.txt >
INTERNET-DRAFT Stuart Kwan INTERNET-DRAFT Stuart Kwan
<draft-ietf-dnsext-gss-tsig-05.txt> Praerit Garg <draft-ietf-dnsext-gss-tsig-06.txt> Praerit Garg
January 30, 2002 James Gilroy February 28, 2003 James Gilroy
Expires July 30, 2002 Levon Esibov Expires August 28, 2003 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 1, line 41 skipping to change at page 1, line 41
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The TSIG protocol provides transaction level authentication for DNS. The TSIG protocol provides transaction level authentication for DNS.
TSIG is extensible through the definition of new algorithms. This TSIG is extensible through the definition of new algorithms. This
document specifies an algorithm based on the Generic Security Service document specifies an algorithm based on the Generic Security Service
Application Program Interface (GSS-API) (RFC2743). Application Program Interface (GSS-API) (RFC2743). This document updates
RFC 2845.
Table of Contents Table of Contents
1: Introduction......................................................2 1: Introduction......................................................2
2: Algorithm Overview................................................3 2: Algorithm Overview................................................3
2.1: GSS Details...................................................4 2.1: GSS Details...................................................4
2.2: Modifications to the TSIG protocol (RFC 2845).................4
3: Client Protocol Details...........................................4 3: Client Protocol Details...........................................4
3.1: Negotiating Context...........................................4 3.1: Negotiating Context...........................................5
3.1.1: Call GSS_Init_sec_context.................................5 3.1.1: Call GSS_Init_sec_context.................................5
3.1.2: Send TKEY Query to Server.................................6 3.1.2: Send TKEY Query to Server.................................7
3.1.3: Receive TKEY Query-Response from Server...................7 3.1.3: Receive TKEY Query-Response from Server...................7
3.2: Context Established...........................................9 3.2: Context Established..........................................10
3.2.1: Terminating a Context....................................10 3.2.1: Terminating a Context....................................10
4: Server Protocol Details..........................................10 4: Server Protocol Details..........................................10
4.1: Negotiating Context..........................................10 4.1: Negotiating Context..........................................10
4.1.1: Receive TKEY Query from Client...........................10 4.1.1: Receive TKEY Query from Client...........................11
4.1.2: Call GSS_Accept_sec_context..............................11 4.1.2: Call GSS_Accept_sec_context..............................11
4.1.3: Send TKEY Query-Response to Client.......................11 4.1.3: Send TKEY Query-Response to Client.......................12
4.2: Context Established..........................................13 4.2: Context Established..........................................13
4.2.1: Terminating a Context....................................13 4.2.1: Terminating a Context....................................13
5: Sending and Verifying Signed Messages............................13 5: Sending and Verifying Signed Messages............................14
5.1: Sending a Signed Message - Call GSS_GetMIC...................13 5.1: Sending a Signed Message - Call GSS_GetMIC...................14
5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............14 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............15
6: Example usage of GSS-TSIG algorithm..............................15 6: Example usage of GSS-TSIG algorithm..............................16
7: Security Considerations..........................................19 7: Security Considerations..........................................20
8: IANA Considerations..............................................19 8: IANA Considerations..............................................20
9: Conformance......................................................19 9: Conformance......................................................20
10:Acknowledgements.................................................20 10:Acknowledgements.................................................20
11:References.......................................................20 11:References.......................................................20
1. Introduction 1. Introduction
The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
protocol was developed to provide a lightweight authentication and protocol was developed to provide a lightweight authentication and
integrity of 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 server or server and server. TSIG can be used to protect dynamic
update messages, authenticate regular message or to off-load update messages, authenticate regular message or to off-load
skipping to change at page 4, line 26 skipping to change at page 4, line 26
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 [RFC2930] 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].
2.2 Modifications to the TSIG protocol (RFC 2845)
Modification to RFC 2845 allows use of TSIG through signing server's
response in an explicitly specified place in multi message exchange
between two DNS entities even if client's request wasn't signed.
Specifically Section 4.2 of RFC 2845 MUST be modified as follows.
Replace:
"The server MUST not generate a signed response to an unsigned
request."
With:
"The server MUST not generate a signed response to an unsigned request,
except in case of response to client's unsigned TKEY query if secret
key is established on server side after server processed client's
query. Signing responses to unsigned TKEY queries MUST be explicitly
specified in the description of an individual secret key establishment
algorithm."
3. Client Protocol Details 3. Client Protocol Details
A unique context is required for each server to which the client sends A unique context is required for each server to which the client sends
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
skipping to change at page 7, line 48 skipping to change at page 8, line 18
3.1.3.1 Value of major_status == GSS_S_COMPLETE 3.1.3.1 Value of major_status == GSS_S_COMPLETE
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_COMPLETE and a non-NULL output_token was sent to the server, of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
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. Note
signature in the TSIG record MUST be verified using the procedure that server is allowed to sign a response to unsigned client's query
due to modification to the RFC 2845 specified in Section 2.2 above.
The 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. In this case the has attempted to send the client a false response. In this case the
client MAY continue waiting for a response to its last TKEY query until client MAY continue waiting for a response to its last TKEY query until
the time period since the client sent last TKEY query expires. Such a the time period since the client sent last TKEY query expires. Such a
time period is specified by the policy local to the client. This is a time period is specified by the policy local to the client. This is a
new option that allows DNS client to accept multiple answers for one 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 query ID and select one (not necessarily the first one) based on some
criteria. criteria.
skipping to change at page 12, line 28 skipping to change at page 12, line 48
GSS_S_FAILURE GSS_S_FAILURE
If OUTPUT major_status is set to GSS_S_COMPLETE or If OUTPUT major_status is set to GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED then server MUST act as described below. GSS_S_CONTINUE_NEEDED then server MUST act as described below.
If major_status is GSS_S_COMPLETE the server component of the If major_status is GSS_S_COMPLETE the server component of the
negotiation is finished. If output_token is non-NULL, then it MUST be negotiation is finished. If output_token is non-NULL, then it MUST be
returned to the client in a Key Data field of the RDATA in TKEY. The returned to the client in a Key Data field of the RDATA in TKEY. The
error field in the TKEY record is set to NOERROR. The message MUST be error field in the TKEY record is set to NOERROR. The message MUST be
signed with a TSIG record as described in section 5, Sending and signed with a TSIG record as described in section 5, Sending and
Verifying Signed Messages. The context state is advanced to Context Verifying Signed Messages. Note that server is allowed to sign a
Established. Section 4.2 discusses the usage of the security context. response to unsigned client's query due to modification to the RFC
2845 specified in Section 2.2 above. The context state is advanced to
Context Established. Section 4.2 discusses the usage of the security
context.
If major_status is GSS_S_COMPLETE and output_token is NULL, then the If major_status is GSS_S_COMPLETE and output_token is NULL, then the
TKEY record received from the client MUST be returned in the Answer TKEY record received from the client MUST be returned in the Answer
section of the response. The message MUST be signed with a TSIG record section of the response. The message MUST be signed with a TSIG record
as described in section 5, Sending and Verifying Signed Messages. The as described in section 5, Sending and Verifying Signed Messages. Note
that server is allowed to sign a response to unsigned client's query
due to modification to the RFC 2845 specified in section 2.2 above. The
context state is advanced to Context Established. Section 4.2 discusses context state is advanced to Context Established. Section 4.2 discusses
the usage of the security context. the usage of the security context.
If major_status is GSS_S_CONTINUE, the server component of the If major_status is GSS_S_CONTINUE, the server component of the
negotiation is not yet finished. The server responds to the TKEY negotiation is not yet finished. The server responds to the TKEY
query with a standard query response, placing in the answer section a query with a standard query response, placing in the answer section a
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.
 End of changes. 13 change blocks. 
21 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/