INTERNET-DRAFT Stuart Kwan
-<draft-ietf-dnsext-gss-tsig-04.txt> Praerit Garg
-November 19, 2001 James Gilroy
-Expires May 19, 2002 Levon Esibov
+<draft-ietf-dnsext-gss-tsig-05.txt> Praerit Garg
+January 30, 2002 James Gilroy
+Expires July 30, 2002 Levon Esibov
Jeff Westhead
Microsoft Corp.
Randy Hall
-Expires May 19, 2002 [Page 1]
+Expires July 30, 2002 [Page 1]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
Table of Contents
1. Introduction
-The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol
-was developed to provide a lightweight authentication 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 messages,
-authenticate regular message or to off-load complicated DNSSEC
-[RFC2535] processing from a client to a server and still allow the
-client to be assured of the integrity off the answers.
+The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
+protocol was developed to provide a lightweight authentication 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 messages, authenticate regular message or to off-load
+complicated DNSSEC [RFC2535] processing from a client to a server and
+still allow the client to be assured of the integrity of the answers.
The TSIG protocol [RFC2845] is extensible through the definition of new
algorithms. This document specifies an algorithm based on the Generic
for one transaction, whereas that same server MAY use SPKM [RFC2025]
with a different client.
-Expires May 19, 2002 [Page 2]
+Expires July 30, 2002 [Page 2]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
* The protocol developer is removed from the responsibility of
creating and managing a security infrastructure. For example, the
| |
+----------+
-Expires May 19, 2002 [Page 3]
+Expires July 30, 2002 [Page 3]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
Every connection begins in the uninitialized state.
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
+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).
client processes this token, and so on, until the negotiation is
complete. The number of times the client and server exchange tokens
-Expires May 19, 2002 [Page 4]
+Expires July 30, 2002 [Page 4]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
depends on the underlying security mechanism. A completed negotiation
results in a context handle.
BOOLEAN sequence_state
BOOLEAN anon_state
-Expires May 19, 2002 [Page 5]
+Expires July 30, 2002 [Page 5]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
BOOLEAN trans_state
BOOLEAN prot_ready_state
BOOLEAN integ_avail
INTEGER lifetime_rec
-The client MUST abandon the algorithm if returned major_status is set to
-one of the following errors:
+If returned major_status is set to one of the following errors
GSS_S_DEFECTIVE_TOKEN
GSS_S_DEFECTIVE_CREDENTIAL
GSS_S_BAD_MECH
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
GSS_S_COMPLETE. The exact success code is important during later
processing.
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
owner name of the TKEY resource record set queried for and the owner
+
+Expires July 30, 2002 [Page 6]
+
+INTERNET-DRAFT GSS-TSIG January 30, 2002
+
name of the supplied TKEY resource record in the additional records
section MUST be the same. This name uniquely identifies the security
context to both the client and server, and thus the client SHOULD use
a value which is globally unique as described in [RFC2930]. To achieve
global uniqueness, the name MAY contain a UUID/GUID [ISO11578].
-Expires May 19, 2002 [Page 6]
-
-INTERNET-DRAFT GSS-TSIG November 19, 2001
-
-
TKEY Record
NAME = client-generated globally unique domain name string
(as described in [RFC2930])
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
-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
detailed in section 5, Sending and Verifying Signed Messages. If the
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
-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
-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 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.
-
+has attempted to send the client a false response. In this case the
+
+Expires July 30, 2002 [Page 7]
-Expires May 19, 2002 [Page 7]
+INTERNET-DRAFT GSS-TSIG January 30, 2002
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+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
+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
+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
Established. Proceed to section 3.2 for usage of the security context.
GSS_S_NO_CRED
GSS_S_CREDENTIALS_EXPIRED
GSS_S_BAD_BINDINGS
+
+Expires July 30, 2002 [Page 8]
+
+INTERNET-DRAFT GSS-TSIG January 30, 2002
+
GSS_S_OLD_TOKEN
GSS_S_DUPLICATE_TOKEN
GSS_S_NO_CONTEXT
GSS_S_BAD_MECH
GSS_S_FAILURE
-Expires May 19, 2002 [Page 8]
-
-INTERNET-DRAFT GSS-TSIG November 19, 2001
-
-
-the client MUST abandon this negotiation sequence. The client MUST
-delete an active context by calling GSS_Delete_sec_context providing
-the associated context_handle. The client MAY repeat the negotiation
-sequence starting with the uninitialized state as described in section
-3.1. To prevent infinite looping the number of attempts to establish a
-security context MUST be limited to ten or less.
+the client MUST abandon this negotiation sequence. This means that the
+client MUST delete an active context by calling GSS_Delete_sec_context
+providing the associated context_handle. The client MAY repeat the
+negotiation sequence starting with the uninitialized state as described
+in section 3.1. To prevent infinite looping the number of attempts to
+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
client MUST act as described below.
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
Messages. If the signature is invalid, then the client MUST abandon this
-negotiation sequence. The client MUST delete an active context by
-calling GSS_Delete_sec_context providing the associated context_handle.
-The client MAY repeat the negotiation sequence starting with the
-uninitialized state as described in section 3.1. To prevent infinite
-looping the number of attempts to establish a security context MUST be
-limited to ten or less.
+negotiation sequence. This means that the client MUST delete an active
+context by calling GSS_Delete_sec_context providing the associated
+context_handle. The client MAY repeat the negotiation sequence starting
+with the uninitialized state as described in section 3.1. To prevent
+infinite looping the number of attempts to establish a security context
+MUST be limited to ten or less.
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
The procedures for sending and receiving signed messages are described
in section 5, Sending and Verifying Signed Messages.
+Expires July 30, 2002 [Page 9]
-
-
-
-
-
-
-Expires May 19, 2002 [Page 9]
-
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
3.2.1 Terminating a Context
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
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
-context negotiation.
-
-
+context negotiation and performs operations described in Section 4.1.2
+and 4.1.3.
+Expires July 30, 2002 [Page 10]
-
-
-Expires May 19, 2002 [Page 10]
-
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
4.1.2 Call GSS_Accept_sec_context
-Expires May 19, 2002 [Page 11]
+Expires July 30, 2002 [Page 11]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
If OUTPUT major_status is one of the following errors the error field
in the TKEY record set to BADKEY.
-Expires May 19, 2002 [Page 12]
+Expires July 30, 2002 [Page 12]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
-Expires May 19, 2002 [Page 13]
+Expires July 30, 2002 [Page 13]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name
INTEGER minor_status
INTEGER qop_state
-Expires May 19, 2002 [Page 14]
+Expires July 30, 2002 [Page 14]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
If major_status is GSS_S_COMPLETE, the signature is authentic and the
message was delivered intact. Per [RFC2845], the timer values of the
-Expires May 19, 2002 [Page 15]
+Expires July 30, 2002 [Page 15]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
Client verifies that replay_det_state and mutual_state values are
TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
-Expires May 19, 2002 [Page 16]
+Expires July 30, 2002 [Page 16]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
V. Server responds to the TKEY query
Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
-Expires May 19, 2002 [Page 17]
+Expires July 30, 2002 [Page 17]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
VIII. Server receives a TKEY query
When the server receives a TKEY query, the server verifies that Mode
Signature field in the TSIG record is set to per_msg_token.
-Expires May 19, 2002 [Page 18]
+Expires July 30, 2002 [Page 18]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
XI. Client processes token returned by server
guarantee interoperability between DNS clients and servers that support
GSS-TSIG it is required that
-Expires May 19, 2002 [Page 19]
-
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+Expires July 30, 2002 [Page 19]
+INTERNET-DRAFT GSS-TSIG January 30, 2002
- DNS servers specify SPNEGO mech_type
- GSS APIs called by DNS client support Kerberos v5
The authors of this document would like to thank the following people
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
January 2000.
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
- "Secret Key Transaction Signatures for DNS (TSIG)", RFC 2845,
- ISC, NAI Labs, Motorola, Nominum, May, 2000,
+ "Secret Key Transaction Authentication for DNS (TSIG)",
+ RFC 2845, ISC, NAI Labs, Motorola, Nominum, May, 2000,
[RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, Motorola, September 2000.
[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, Bull, December 1998.
-Expires May 19, 2002 [Page 20]
+Expires July 30, 2002 [Page 20]
-INTERNET-DRAFT GSS-TSIG November 19, 2001
+INTERNET-DRAFT GSS-TSIG January 30, 2002
[ISO11578]"Information technology", "Open Systems
-Expires May 19, 2002 [Page 21]
+Expires July 30, 2002 [Page 21]
projects / thirdparty / bind9.git / commitdiff
