rfc3645.txt

bind 9.3结合mysql数据库

   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 2003


3.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 2003


3.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 to





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


4.  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]