then the client MUST abandon the algorithm and MUST NOT use the GSS-   TSIG algorithm to establish this security context.  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.   The values of replay_det_state and mutual_state indicate if the   security package provides replay detection and mutual authentication,   respectively.  If returned major_status is GSS_S_COMPLETE AND one or   both of these values are FALSE, the client MUST abandon this   algorithm.   Client's behavior MAY depend on other OUTPUT parameters according to   the policy local to the client.   The handle output_context_handle is unique to this negotiation and is   stored in the client's mapping table as the context_handle that maps   to target_name.Kwan, et al.                Standards Track                     [Page 7]RFC 3645                        GSS-TSIG                    October 20033.1.2.  Send TKEY Query to Server   An opaque output_token returned by GSS_Init_sec_context is   transmitted to the server in a query request with QTYPE=TKEY.  The   token itself 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 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].      TKEY Record        NAME = client-generated globally unique domain name string               (as described in [RFC2930])        RDATA           Algorithm Name      = gss-tsig           Mode                = 3 (GSS-API negotiation - per [RFC2930])           Key Size            = size of output_token in octets           Key Data            = output_token   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,   Error, Other Size and Data Fields, MUST be set according to   [RFC2930].   The query is transmitted to the server.   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.  Client's behavior in this   case is described above in Section 3.1.1.3.1.3.  Receive TKEY Query-Response from Server   Upon the reception of the TKEY query the DNS server MUST respond   according to the description in Section 4.  This section specifies   the behavior 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 most recent call that client performed to GSS_Init_sec_context:   either GSS_S_COMPLETE or GSS_S_CONTINUE.Kwan, et al.                Standards Track                     [Page 8]RFC 3645                        GSS-TSIG                    October 20033.1.3.1.  Value of major_status == GSS_S_COMPLETE   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,   then the client side component of the negotiation is complete and the   client is awaiting confirmation from the server.   Confirmation is in the form of a query response with RCODE=NOERROR   and with the last client supplied TKEY record in the answer section   of the query.  The response MUST be signed with a TSIG record.  Note   that the 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 response is not signed, OR if the response is   signed but the signature is 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 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   the 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.3.1.3.2.  Value of major_status == GSS_S_CONTINUE_NEEDED   If the last call to GSS_Init_sec_context yielded a major_status value   of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete.   The server 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 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 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 the DNS message error is NO_ERROR and the error field in the TKEY   record is 0 (i.e., no error), then the client MUST pass a token   specified in the Key Data field in the TKEY resource record toKwan, et al.                Standards Track                     [Page 9]RFC 3645                        GSS-TSIG                    October 2003   GSS_Init_sec_context using the same parameters values as in previous   call except values for CONTEXT HANDLE input_context_handle and OCTET   STRING input_token as described below:   INPUTS     CONTEXT HANDLE input_context_handle  = context_handle (this is the          context_handle corresponding to the key_name which is the          owner name of the TKEY record in the answer section in the          TKEY query response)     OCTET STRING   input_token           = token from Key field of                                            TKEY record   Depending on the following OUTPUT values of GSS_Init_sec_context        INTEGER        major_status        OCTET STRING   output_token   the client MUST take one of the following actions:   If OUTPUT major_status is set to one of the following values:        GSS_S_DEFECTIVE_TOKEN        GSS_S_DEFECTIVE_CREDENTIAL        GSS_S_BAD_SIG (GSS_S_BAD_MIC)        GSS_S_NO_CRED        GSS_S_CREDENTIALS_EXPIRED        GSS_S_BAD_BINDINGS        GSS_S_OLD_TOKEN        GSS_S_DUPLICATE_TOKEN        GSS_S_NO_CONTEXT        GSS_S_BAD_NAMETYPE        GSS_S_BAD_NAME        GSS_S_BAD_MECH        GSS_S_FAILURE   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.Kwan, et al.                Standards Track                    [Page 10]RFC 3645                        GSS-TSIG                    October 2003   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.  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 record by repeating the negotiation sequence beginning with   section 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 exceed value of 10.   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   output_token MUST be passed to the server by repeating the   negotiation sequence beginning with section 3.1.2.   If major_status is GSS_S_COMPLETE and output_token is NULL, context   negotiation is complete.  The context state is advanced to Context   Established.  Proceed to section 3.2 for usage of the security   context.3.2.  Context Established   When context negotiation is complete, the handle context_handle MUST   be used for the generation and verification of transaction   signatures.   The procedures for sending and receiving signed messages are   described in section 5, Sending and Verifying Signed Messages.3.2.1.  Terminating a Context   When the client is not intended to continue using the established   security context, the client SHOULD delete an active context by   calling GSS_Delete_sec_context providing the associated   context_handle, AND client SHOULD delete the established context on   the DNS server by using TKEY RR with the Mode field set to 5, i.e.,   "key deletion" [RFC2930].Kwan, et al.                Standards Track                    [Page 11]RFC 3645                        GSS-TSIG                    October 20034.  Server Protocol Details   As on the client-side, the result of a successful context negotiation   is a context handle used in future generation and verification of the   transaction signatures.   A server MAY be managing several contexts with several clients.   Clients identify their contexts by providing a key name in their   request.  The server maintains a mapping of key names to handles:      (key_name, context_handle)4.1.  Negotiating Context   A server MUST recognize TKEY queries as security context negotiation   messages.4.1.1.  Receive TKEY Query from Client   Upon receiving a query with QTYPE = TKEY, the server MUST examine   whether the Mode and Algorithm Name fields of the TKEY record in the   additional records section of the message contain values of 3 and   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 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 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 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   and performs operations described in Section 4.1.2 and 4.1.3.4.1.2.  Call GSS_Accept_sec_context   The server performs its side of a context negotiation by calling   GSS_Accept_sec_context.  The following input parameters MUST be used.   The 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] for syntax definitions.Kwan, et al.                Standards Track                    [Page 12]RFC 3645                        GSS-TSIG                    October 2003   INPUTS     CONTEXT HANDLE input_context_handle  = 0 if new negotiation,                                            context_handle matching                                         key_name if ongoing negotiation     OCTET STRING   input_token           = token specified in the Key           field from TKEY RR (from Additional records Section of           the client's query)     CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use           default").  Server MAY instead specify some other valid           handle to its credentials.     OCTET STRING   chan_bindings          = Any valid channel bindings           as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]   OUTPUTS     INTEGER        major_status     CONTEXT_HANDLE output_context_handle     OCTET STRING   output_token     INTEGER        minor_status     INTERNAL NAME  src_name     OBJECT IDENTIFIER  mech_type     BOOLEAN        deleg_state     BOOLEAN        mutual_state     BOOLEAN        replay_det_state     BOOLEAN        sequence_state     BOOLEAN        anon_state     BOOLEAN        trans_state     BOOLEAN        prot_ready_state     BOOLEAN        conf_avail     BOOLEAN        integ_avail     INTEGER        lifetime_rec     CONTEXT_HANDLE delegated_cred_handle   If this is the first call to GSS_Accept_sec_context in a new   negotiation, then output_context_handle is stored in the server's   key-mapping table as the context_handle that maps to the name of the   TKEY record.4.1.3.  Send TKEY Query-Response to Client   The server MUST respond to the client with a TKEY query response with   RCODE = NOERROR, that contains a TKEY record in the answer section.   If OUTPUT major_status is one of the following errors the error field   in the TKEY record set to BADKEY.Kwan, et al.                Standards Track                    [Page 13]