INTERNET-DRAFT                                               Stuart Kwan<draft-ietf-dnsext-gss-tsig-06.txt>                         Praerit GargFebruary 28, 2003                                           James GilroyExpires August 28, 2003                                     Levon Esibov                                                           Jeff Westhead                                                         Microsoft Corp.                                                              Randy Hall                                                     Lucent Technologies                                                                     GSS Algorithm for TSIG (GSS-TSIG)Status of this MemoThis document is an Internet-Draft and is in full conformancewith all provisions of Section 10 of RFC2026.Internet-Drafts are working documents of the Internet EngineeringTask Force (IETF), its areas, and its working groups.  Note thatother groups may also distribute working documents asInternet-Drafts.Internet-Drafts are draft documents valid for a maximum of sixmonths and may be updated, replaced, or obsoleted by otherdocuments at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as"work in progress."The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txtThe list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.AbstractThe TSIG protocol provides transaction level authentication for DNS.TSIG is extensible through the definition of new algorithms.  Thisdocument specifies an algorithm based on the Generic Security ServiceApplication Program Interface (GSS-API) (RFC2743). This document updatesRFC 2845.Expires August 28, 2003                                       [Page 1]INTERNET-DRAFT                   GSS-TSIG            February 28, 2003Table of Contents1: Introduction......................................................22: Algorithm Overview................................................3  2.1: GSS Details...................................................4  2.2: Modifications to the TSIG protocol (RFC 2845).................43: Client Protocol Details...........................................4  3.1: Negotiating Context...........................................5    3.1.1: Call GSS_Init_sec_context.................................5    3.1.2: Send TKEY Query to Server.................................7    3.1.3: Receive TKEY Query-Response from Server...................7  3.2: Context Established..........................................10    3.2.1: Terminating a Context....................................104: Server Protocol Details..........................................10  4.1: Negotiating Context..........................................10    4.1.1: Receive TKEY Query from Client...........................11    4.1.2: Call GSS_Accept_sec_context..............................11    4.1.3: Send TKEY Query-Response to Client.......................12  4.2: Context Established..........................................13    4.2.1: Terminating a Context....................................135: Sending and Verifying Signed Messages............................14  5.1: Sending a Signed Message - Call GSS_GetMIC...................14  5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............156: Example usage of GSS-TSIG algorithm..............................167: Security Considerations..........................................208: IANA Considerations..............................................209: Conformance......................................................2010:Acknowledgements.................................................2011:References.......................................................201. IntroductionThe Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]protocol was developed to provide a lightweight authentication andintegrity of messages between two DNS entities, such as client andserver or server and server. TSIG can be used to protect dynamicupdate messages, authenticate regular message or to off-loadcomplicated DNSSEC [RFC2535] processing from a client to a server andstill allow the client to be assured of the integrity of the answers.The TSIG protocol [RFC2845] is extensible through the definition of newalgorithms.  This document specifies an algorithm based on the GenericSecurity Service Application Program Interface (GSS-API) [RFC2743].GSS-API is a framework that provides an abstraction of security to theapplication protocol developer.  The security services offered caninclude authentication, integrity, and confidentiality.The GSS-API framework has several benefits:* Mechanism and protocol independence.  The underlying mechanisms thatrealize the security services can be negotiated on the fly and variedover 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 August 28, 2003                                       [Page 2]INTERNET-DRAFT                   GSS-TSIG            February 28, 2003* The protocol developer is removed from the responsibility ofcreating and managing a security infrastructure.  For example, thedeveloper does not need to create new key distribution or keymanagement systems.  Instead the developer relies on the securityservice mechanism to manage this on its behalf.The scope of this document is limited to the description of anauthentication mechanism only. It does not discuss and/or propose anauthorization mechanism.  Readers that are unfamiliar with GSS-APIconcepts are encouraged to read the characteristics and concepts sectionof [RFC2743] before examining this protocol in detail. It is alsoassumed 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 asdescribed in RFC 2119 [RFC2119].2. Algorithm OverviewIn GSS, client and server interact to create a "security context".The security context can be used to create and verify transactionsignatures on messages between the two parties.  A unique securitycontext is required for each unique connection between client andserver.Creating a security context involves a negotiation between client andserver.  Once a context has been established, it has a finite lifetimefor which it can be used to secure messages.  Thus there are threestates of a context associated with a connection:                           +----------+                           |          |                           V          |                   +---------------+  |                   | Uninitialized |  |                   |               |  |                   +---------------+  |                           |          |                           V          |                   +---------------+  |                   | Negotiating   |  |                   | Context       |  |                   +---------------+  |                           |          |                           V          |                   +---------------+  |                   | Context       |  |                   | Established   |  |                   +---------------+  |                           |          |                           +----------+Expires August 28, 2003                                       [Page 3]INTERNET-DRAFT                   GSS-TSIG            February 28, 2003Every connection begins in the uninitialized state.2.1 GSS DetailsClient and server MUST be locally authenticated and have acquireddefault credentials before using this protocol as specified inSection 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 theGSS_Init_sec_context and GSS_Accept_sec_context APIs to generate thetokens that they pass to each other using [RFC2930] as a transportmechanism.II. Once the security context is established it is used to generate andverify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. Thesesignatures are exchanged by the Client and Server as a part of the TSIGrecords 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'sresponse in an explicitly specified place in multi message exchangebetween 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 unsignedrequest."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 DetailsA unique context is required for each server to which the client sendssecure messages.  A context is identified by a context handle. Aclient maintains a mapping of servers to handles,     (target_name, key_name, context_handle)Expires August 28, 2003                                       [Page 4]INTERNET-DRAFT                   GSS-TSIG            February 28, 2003The value key_name also identifies a context handle. The key_name isthe owner name of the TKEY and TSIG records sent between a client and aserver to indicate to each other which context MUST be used to processthe current request.DNS client and server MAY use various underlying security mechanisms toestablish security context as described in sections 3 and 4. At thesame time, in order to guarantee interoperability between DNS clientsand servers that support GSS-TSIG it is REQUIRED that securitymechanism used by client enables use of Kerberos v5 (see Section 9for more information).3.1  Negotiating ContextIn GSS, establishing a security context involves the passing of opaquetokens between the client and the server.  The client generates theinitial token and sends it to the server.  The server processes thetoken and if necessary, returns a subsequent token to the client.  Theclient processes this token, and so on, until the negotiation iscomplete.  The number of times the client and server exchange tokensdepends on the underlying security mechanism.  A completed negotiationresults in a context handle.The TKEY resource record [RFC2930] is used as the vehicle to transfertokens between client and server.  The TKEY record is a generalmechanism for establishing secret keys for use with TSIG.  For moreinformation, see [RFC2930].3.1.1 Call GSS_Init_sec_contextTo obtain the first token to be sent to a server, a client MUST callGSS_Init_sec_context API.The following input parameters MUST be used. The outcome of the call isindicated 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   = TRUEExpires August 28, 2003                                       [Page 5]INTERNET-DRAFT                   GSS-TSIG            February 28, 2003     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