Network Working Group                                            S. KwanRequest for Comments: 3645                                       P. GargUpdates: 2845                                                  J. GilroyCategory: Standards Track                                      L. Esibov                                                             J. Westhead                                                         Microsoft Corp.                                                                 R. Hall                                                     Lucent Technologies                                                            October 2003                 Generic Security Service Algorithm for        Secret Key Transaction Authentication for DNS (GSS-TSIG)Status of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2003).  All Rights Reserved.Abstract   The Secret Key Transaction Authentication for DNS (TSIG) protocol   provides transaction level authentication for DNS.  TSIG is   extensible through the definition of new algorithms.  This document   specifies an algorithm based on the Generic Security Service   Application Program Interface (GSS-API) (RFC2743).  This document   updates RFC 2845.Kwan, et al.                Standards Track                     [Page 1]RFC 3645                        GSS-TSIG                    October 2003Table of Contents   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2   2.  Algorithm Overview . . . . . . . . . . . . . . . . . . . . . .  3       2.1.  GSS Details. . . . . . . . . . . . . . . . . . . . . . .  4       2.2.  Modifications to the TSIG protocol (RFC 2845). . . . . .  4   3.  Client Protocol Details. . . . . . . . . . . . . . . . . . . .  5       3.1.  Negotiating Context. . . . . . . . . . . . . . . . . . .  5           3.1.1.  Call GSS_Init_sec_context. . . . . . . . . . . . .  6           3.1.2.  Send TKEY Query to Server. . . . . . . . . . . . .  8           3.1.3.  Receive TKEY Query-Response from Server. . . . . .  8       3.2.  Context Established. . . . . . . . . . . . . . . . . . . 11           3.2.1.  Terminating a Context. . . . . . . . . . . . . . . 11   4.  Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12       4.1.  Negotiating Context. . . . . . . . . . . . . . . . . . . 12           4.1.1.  Receive TKEY Query from Client . . . . . . . . . . 12           4.1.2.  Call GSS_Accept_sec_context. . . . . . . . . . . . 12           4.1.3.  Send TKEY Query-Response to Client . . . . . . . . 13       4.2.  Context Established. . . . . . . . . . . . . . . . . . . 15           4.2.1.  Terminating a Context. . . . . . . . . . . . . . . 15   5.  Sending and Verifying Signed Messages. . . . . . . . . . . . . 15       5.1.  Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15       5.2.  Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16   6.  Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 22   8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22   9.  Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22   10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24       12.1.  Normative References. . . . . . . . . . . . . . . . . . 24       12.2.  Informative References. . . . . . . . . . . . . . . . . 24   13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 261.  Introduction   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.Kwan, et al.                Standards Track                     [Page 2]RFC 3645                        GSS-TSIG                    October 2003   The TSIG protocol [RFC2845] is extensible through the definition of   new algorithms.  This document specifies an algorithm based on the   Generic Security Service Application Program Interface (GSS-API)   [RFC2743].  GSS-API is a framework that provides an abstraction of   security to the application protocol developer.  The security   services offered can include authentication, integrity, and   confidentiality.   The GSS-API framework has several benefits:   *  Mechanism and protocol independence.  The underlying mechanisms      that realize the security services can be negotiated on the fly      and varied 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.   *  The protocol developer is removed from the responsibility of      creating and managing a security infrastructure.  For example, the      developer does not need to create new key distribution or key      management systems.  Instead the developer relies on the security      service mechanism to manage this on its behalf.   The scope of this document is limited to the description of an   authentication mechanism only.  It does not discuss and/or propose an   authorization mechanism.  Readers that are unfamiliar with GSS-API   concepts are encouraged to read the characteristics and concepts   section of [RFC2743] before examining this protocol in detail.  It is   also assumed that the reader is familiar with [RFC2845], [RFC2930],   [RFC1034] and [RFC1035].   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",   "RECOMMENDED", and "MAY" in this document are to be interpreted as   described in BCP 14, RFC 2119 [RFC2119].2.  Algorithm Overview   In GSS, client and server interact to create a "security context".   The security context can be used to create and verify transaction   signatures on messages between the two parties.  A unique security   context is required for each unique connection between client and   server.   Creating a security context involves a negotiation between client and   server.  Once a context has been established, it has a finite   lifetime for which it can be used to secure messages.  Thus there are   three states of a context associated with a connection:Kwan, et al.                Standards Track                     [Page 3]RFC 3645                        GSS-TSIG                    October 2003                              +----------+                              |          |                              V          |                      +---------------+  |                      | Uninitialized |  |                      |               |  |                      +---------------+  |                              |          |                              V          |                      +---------------+  |                      | Negotiating   |  |                      | Context       |  |                      +---------------+  |                              |          |                              V          |                      +---------------+  |                      | Context       |  |                      | Established   |  |                      +---------------+  |                              |          |                              +----------+   Every connection begins in the uninitialized state.2.1.  GSS Details   Client and server MUST be locally authenticated and have acquired   default credentials before using this protocol as specified in   Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].   The GSS-TSIG algorithm consists of two stages:   I.  Establish security context.  The Client and Server use 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 mechanism.   II. Once the security context is established it is used to generate       and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs.       These 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, 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.Kwan, et al.                Standards Track                     [Page 4]RFC 3645                        GSS-TSIG                    October 2003   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   A unique context is required for each server to which the client   sends secure messages.  A context is identified by a context handle.   A client maintains a mapping of servers to handles:      (target_name, key_name, context_handle)   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 server to indicate to each other which context MUST be used to   process the current request.   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 mechanism used by client enables use of Kerberos v5 (see   Section 9 for more information).3.1.  Negotiating Context   In GSS, establishing a security context involves the passing of   opaque tokens between the client and the server.  The client   generates 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 client processes this token, and so on, until the   negotiation is complete.  The number of times the client and server   exchange tokens depends on the underlying security mechanism.  A   completed negotiation results in a context handle.Kwan, et al.                Standards Track                     [Page 5]RFC 3645                        GSS-TSIG                    October 2003   The TKEY resource record [RFC2930] is used as the vehicle to transfer   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].3.1.1.  Call GSS_Init_sec_context   To obtain the first token to be sent to a server, a client MUST call   GSS_Init_sec_context API.   The following input parameters MUST be used.  The outcome of the call   is indicated with the output values below.  Consult Sections 2.2.1,   "GSS_Init_sec_context call", of [RFC2743] for syntax definitions.   INPUTS     CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use         default").  Client MAY instead specify some other valid         handle to its credentials.     CONTEXT HANDLE input_context_handle  = 0     INTERNAL NAME  targ_name             = "DNS@<target_server_name>"     OBJECT IDENTIFIER mech_type          = Underlying security         mechanism chosen by implementers.  To guarantee         interoperability of the implementations of the GSS-TSIG         mechanism client MUST specify a valid underlying security         mechanism that enables use of Kerberos v5 (see Section 9 for         more information).     OCTET STRING   input_token           = NULL     BOOLEAN        replay_det_req_flag   = TRUE     BOOLEAN        mutual_req_flag       = TRUE     BOOLEAN        deleg_req_flag        = TRUE     BOOLEAN        sequence_req_flag     = TRUE     BOOLEAN        anon_req_flag         = FALSE     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 [RFC2743]   OUTPUTS     INTEGER        major_status     CONTEXT HANDLE output_context_handle     OCTET STRING   output_token     BOOLEAN        replay_det_state     BOOLEAN        mutual_state     INTEGER        minor_status     OBJECT IDENTIFIER mech_type     BOOLEAN        deleg_stateKwan, et al.                Standards Track                     [Page 6]RFC 3645                        GSS-TSIG                    October 2003     BOOLEAN        sequence_state     BOOLEAN        anon_state     BOOLEAN        trans_state     BOOLEAN        prot_ready_state     BOOLEAN        conf_avail     BOOLEAN        integ_avail     INTEGER        lifetime_rec   If returned major_status is set to one of the following errors:     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