diff --git a/doc/draft/draft-ietf-dnsext-gss-tsig-02.txt b/doc/draft/draft-ietf-dnsext-gss-tsig-03.txt similarity index 90% rename from doc/draft/draft-ietf-dnsext-gss-tsig-02.txt rename to doc/draft/draft-ietf-dnsext-gss-tsig-03.txt index 32b72562c2..df211faeb2 100644 --- a/doc/draft/draft-ietf-dnsext-gss-tsig-02.txt +++ b/doc/draft/draft-ietf-dnsext-gss-tsig-03.txt @@ -1,9 +1,9 @@ - INTERNET-DRAFT Stuart Kwan - Praerit Garg -March 1, 2001 James Gilroy -Expires September 1, 2001 Levon Esibov + Praerit Garg +September 20, 2001 James Gilroy +Expires March 20, 2002 Levon Esibov + Jeff Westhead Microsoft Corp. Randy Hall Lucent Technologies @@ -54,9 +54,9 @@ Application Program Interface (GSS-API) (RFC2743). -Expires September 1, 2001 [Page 1] +Expires March 20, 2002 [Page 1] -INTERNET-DRAFT GSS-TSIG March 1, 2001 +INTERNET-DRAFT GSS-TSIG September 20, 2001 Table of Contents @@ -69,13 +69,13 @@ Table of Contents 3.1.2: Send TKEY Query to Server.................................6 3.1.3: Receive TKEY Query-Response from Server...................7 3.2: Context Established...........................................9 - 3.2.1: Terminating a Context.....................................9 + 3.2.1: Terminating a Context....................................10 4: Server Protocol Details..........................................10 4.1: Negotiating Context..........................................10 4.1.1: Receive TKEY Query from Client...........................10 - 4.1.2: Call GSS_Accept_sec_context..............................10 + 4.1.2: Call GSS_Accept_sec_context..............................11 4.1.3: Send TKEY Query-Response to Client.......................11 - 4.2: Context Established..........................................12 + 4.2: Context Established..........................................13 4.2.1: Terminating a Context....................................13 5: Sending and Verifying Signed Messages............................13 5.1: Sending a Signed Message - Call GSS_GetMIC...................13 @@ -112,9 +112,9 @@ over time. For example, a client and server may use Kerberos [RFC1964] for one transaction, whereas that same server may use SPKM [RFC2025] with a different client. -Expires September 1, 2001 [Page 2] +Expires March 20, 2002 [Page 2] -INTERNET-DRAFT GSS-TSIG March 1, 2001 +INTERNET-DRAFT GSS-TSIG September 20, 2001 * The protocol developer is removed from the responsibility of creating and managing a security infrastructure. For example, the @@ -170,9 +170,9 @@ states of a context associated with a connection: | | +----------+ -Expires September 1, 2001 [Page 3] +Expires March 20, 2002 [Page 3] -INTERNET-DRAFT GSS-TSIG March 1, 2001 +INTERNET-DRAFT GSS-TSIG September 20, 2001 Every connection begins in the uninitialized state. @@ -228,9 +228,10 @@ tokens between client and server. The TKEY record is a general mechanism for establishing secret keys for use with TSIG. For more information, see [RFC2930]. -Expires September 1, 2001 [Page 4] +Expires March 20, 2002 [Page 4] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 -INTERNET-DRAFT GSS-TSIG March 1, 2001 3.1.1 Call GSS_Init_sec_context @@ -259,13 +260,12 @@ indicated with the output values below. Consult Sections 2.2.1 BOOLEAN deleg_req_flag = TRUE BOOLEAN sequence_req_flag = TRUE BOOLEAN anon_req_flag = FALSE - BOOLEAN conf_req_flag = TRUE BOOLEAN integ_req_flag = TRUE INTEGER lifetime_req = 0 (0 requests a default value). Client MAY instead specify another upper bound for the lifetime of the context to be established in seconds. 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 INTEGER major_status @@ -286,9 +286,9 @@ indicated with the output values below. Consult Sections 2.2.1 -Expires September 1, 2001 [Page 5] +Expires March 20, 2002 [Page 5] -INTERNET-DRAFT GSS-TSIG March 1, 2001 +INTERNET-DRAFT GSS-TSIG September 20, 2001 The client MUST abandon the algorithm if returned major_status is set to @@ -344,9 +344,9 @@ global uniqueness, the name MAY contain a UUID/GUID [ISO11578]. -Expires September 1, 2001 [Page 6] +Expires March 20, 2002 [Page 6] -INTERNET-DRAFT GSS-TSIG March 1, 2001 +INTERNET-DRAFT GSS-TSIG September 20, 2001 TKEY Record @@ -402,9 +402,9 @@ is specified by the policy local to the client. -Expires September 1, 2001 [Page 7] +Expires March 20, 2002 [Page 7] -INTERNET-DRAFT GSS-TSIG March 1, 2001 +INTERNET-DRAFT GSS-TSIG September 20, 2001 If the signature is verified the context state is advanced to Context @@ -460,10 +460,9 @@ If OUTPUT major_status is set to one of the following values GSS_S_BAD_MECH GSS_S_FAILURE -Expires September 1, 2001 [Page 8] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 +Expires March 20, 2002 [Page 8] +INTERNET-DRAFT GSS-TSIG September 20, 2001 the client MUST abandon this negotiation sequence. The client MUST @@ -476,6 +475,17 @@ security context must be limited. If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then client MUST act as described below. +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 +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. + 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 record by repeating the negotiation sequence beginning with section @@ -502,6 +512,17 @@ The procedures for sending and receiving signed messages are described in section 5, Sending and Verifying Signed Messages. + + + + + + +Expires March 20, 2002 [Page 9] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 + + 3.2.1 Terminating a Context When the client is not intended to continue using the established @@ -513,16 +534,6 @@ by using TKEY RR with the Mode field set to 5, i.e. "key deletion" - - - - - -Expires September 1, 2001 [Page 9] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 - - 4. Server Protocol Details As on the client-side, the result of a successful context negotiation @@ -560,6 +571,16 @@ found, then the server interprets this query as a start of new security context negotiation. + + + + + +Expires March 20, 2002 [Page 10] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 + + 4.1.2 Call GSS_Accept_sec_context The server performs its side of a context negotiation by calling @@ -575,13 +596,6 @@ for syntax definitions. OCTET STRING input_token = token specified in the Key field from TKEY RR (from Additional records Section of the client's query) - -Expires September 1, 2001 [Page 10] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 - - - CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use default"). Server MAY instead specify some other valid handle to its credentials. @@ -618,6 +632,12 @@ TKEY record. The server MUST respond to the client with a TKEY query response with RCODE = NOERROR, that contains a TKEY record in the answer section. + + +Expires March 20, 2002 [Page 11] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 + If OUTPUT major_status is one of the following errors the error field in the TKEY record set to BADKEY. @@ -633,20 +653,16 @@ in the TKEY record set to BADKEY. GSS_S_BAD_MECH GSS_S_FAILURE - -Expires September 1, 2001 [Page 11] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 - - - If OUTPUT major_status is set to GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED then server MUST act as described below. 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 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. +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 +Verifying Signed Messages. 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 TKEY record received from the client MUST be returned in the Answer @@ -675,6 +691,13 @@ The remaining fields in the TKEY RDATA, i.e. Inception, Expiration, Error, Other Size and Data Fields, MUST be set according to [RFC2930]. + +Expires March 20, 2002 [Page 12] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 + + + 4.2 Context Established When context negotiation is complete, the handle context_handle @@ -690,13 +713,6 @@ The procedures for sending and receiving signed messages are given in section 5, Sending and Verifying Signed Messages. - - -Expires September 1, 2001 [Page 12] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 - - 4.2.1 Terminating a Context A server can terminate any established context at any time. The @@ -730,6 +746,14 @@ parameters MUST be used. The outcome of the call is indicated with the output values specified below. Consult Sections 2.3.1 "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions. + + + + +Expires March 20, 2002 [Page 13] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 + INPUTS CONTEXT HANDLE context_handle = context_handle for key_name OCTET STRING message = outgoing message plus TSIG @@ -738,7 +762,6 @@ call" of the RFC 2743[RFC2743] for syntax definitions. value). Caller MAY instead specify other valid value (for details see Section 1.2.4 in [RFC2743]) - OUTPUTS INTEGER major_status INTEGER minor_status @@ -748,13 +771,6 @@ If major_status is GSS_S_COMPLETE, then signature generation succeeded. The signature in per_msg_token is inserted into the Signature field of the TSIG RR and the message is transmitted. - - -Expires September 1, 2001 [Page 13] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 - - If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED or GSS_S_FAILURE the caller MUST delete the security context, return to the uninitialized state and SHOULD negotiate a new security context, as @@ -781,7 +797,6 @@ standard TSIG error response to the client indicating BADKEY in the TSIG error field (as described in [RFC2845]). For the GSS algorithm, a signature is verified by using GSS_VerifyMIC: - INPUTS CONTEXT HANDLE context_handle = context_handle for key_name OCTET STRING message = incoming message plus TSIG @@ -793,6 +808,10 @@ For the GSS algorithm, a signature is verified by using GSS_VerifyMIC: INTEGER minor_status INTEGER qop_state +Expires March 20, 2002 [Page 14] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 + If major_status is GSS_S_COMPLETE, the signature is authentic and the message was delivered intact. Per [RFC2845], the timer values of the TSIG record MUST also be valid before considering the message to be @@ -806,13 +825,6 @@ if major_status is set to one of the following values GSS_S_DEFECTIVE_TOKEN GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_DUPLICATE_TOKEN - - -Expires September 1, 2001 [Page 14] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 - - GSS_S_OLD_TOKEN GSS_S_UNSEQ_TOKEN GSS_S_GAP_TOKEN @@ -840,7 +852,7 @@ to the algorithm described above. (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example) CONTEXT HANDLE input_context_handle = 0 - INTERNAL NAME targ_name = "DNS/ server.example.com" + INTERNAL NAME targ_name = "DNS@server.example.com" OCTET STRING input_token = NULL BOOLEAN replay_det_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE @@ -852,10 +864,16 @@ to the algorithm described above. BOOLEAN replay_det_state = TRUE BOOLEAN mutual_state = TRUE + + +Expires March 20, 2002 [Page 15] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 + Client verifies that replay_det_state and mutual_state values are TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a success OUTPUT major_status value, client stores context_handle that - maps to "DNS/server.example.com" and proceeds to the next step. + maps to "DNS@server.example.com" and proceeds to the next step. II. Client sends a query with QTYPE = TKEY to server @@ -865,12 +883,6 @@ to the algorithm described above. the following fields (Note that some fields not specific to this algorithm are not specified) - -Expires September 1, 2001 [Page 15] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 - - NAME = 789.client.example.com.server.example.com. RDATA Algorithm Name = gss-tsig @@ -911,6 +923,11 @@ INTERNET-DRAFT GSS-TSIG March 1, 2001 in its (key_name, context_handle) mapping table. + +Expires March 20, 2002 [Page 16] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 + V. Server responds to the TKEY query Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's call to GSS_Accept_sec_context, the server responds to the TKEY query @@ -919,25 +936,15 @@ INTERNET-DRAFT GSS-TSIG March 1, 2001 0. The RCODE in the query response is set to NOERROR. - - - - - -Expires September 1, 2001 [Page 16] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 - - VI. Client processes token returned by server When the client receives the TKEY query response from the server, the client calls GSS_Init_sec_context with the following parameters (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example) CONTEXT HANDLE input_context_handle = the context_handle stored - in the client's mapping table entry (DNS/server.example.com., + in the client's mapping table entry (DNS@server.example.com., 789.client.example.com.server.example.com., context_handle) - INTERNAL NAME targ_name = "DNS/server.example.com" + INTERNAL NAME targ_name = "DNS@server.example.com" OCTET STRING input_token = token from Key field of TKEY record from the Answer section of the server's response BOOLEAN replay_det_req_flag = TRUE @@ -970,6 +977,15 @@ INTERNET-DRAFT GSS-TSIG March 1, 2001 Key Data = output_token + + + + + +Expires March 20, 2002 [Page 17] + +INTERNET-DRAFT GSS-TSIG September 20, 2001 + VIII. Server receives a TKEY query When the server receives a TKEY query, the server verifies that Mode and Algorithm fields in the TKEY record in the Additional records @@ -978,16 +994,6 @@ INTERNET-DRAFT GSS-TSIG March 1, 2001 listed in its (key_name, context_handle) mapping table. - - - - -Expires September 1, 2001 [Page 17] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 - - - IX. Server calls GSS_Accept_sec_context To continue security context negotiation server calls GSS_Accept_sec_context with the following parameters (Note that some @@ -1034,15 +1040,9 @@ INTERNET-DRAFT GSS-TSIG March 1, 2001 Signature field in the TSIG record is set to per_msg_token. +Expires March 20, 2002 [Page 18] - - - - - -Expires September 1, 2001 [Page 18] - -INTERNET-DRAFT GSS-TSIG March 1, 2001 +INTERNET-DRAFT GSS-TSIG September 20, 2001 XI. Client processes token returned by server @@ -1098,9 +1098,9 @@ GSS-TSIG it is required that -Expires September 1, 2001 [Page 19] +Expires March 20, 2002 [Page 19] -INTERNET-DRAFT GSS-TSIG March 1, 2001 +INTERNET-DRAFT GSS-TSIG September 20, 2001 - DNS servers specify SPNEGO mech_type @@ -1156,9 +1156,9 @@ Ram Viswanathan, Olafur Gudmundsson and Donald E. Eastlake 3rd. [RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, Bull, December 1998. -Expires September 1, 2001 [Page 20] +Expires March 20, 2002 [Page 20] -INTERNET-DRAFT GSS-TSIG March 1, 2001 +INTERNET-DRAFT GSS-TSIG September 20, 2001 [ISO11578]"Information technology", "Open Systems @@ -1185,13 +1185,13 @@ USA USA levone@microsoft.com -Randy Hall -Lucent Technologies -400 Lapp Road -Malvern PA 19355 -USA +Randy Hall Jeff Westhead +Lucent Technologies Microsoft Corporation +400 Lapp Road One Microsoft Way +Malvern PA 19355 Redmond, WA 98052 +USA USA randyhall@lucent.com -Expires September 1, 2001 [Page 21] \ No newline at end of file +Expires March 20, 2002 [Page 21]