rfc3645.txt

bind 9.3结合mysql数据库

Network Working Group                                            S. Kwan
Request for Comments: 3645                                       P. Garg
Updates: 2845                                                  J. Gilroy
Category: 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 2003


Table 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 . . . . . . . . . . . . . . . . . . . 26

1.  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_state



Kwan, 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