draft-ietf-dnsext-gss-tsig-06.txt

bind-3.2.

     BOOLEAN        mutual_state
     INTEGER        minor_status
     OBJECT IDENTIFIER mech_type
     BOOLEAN        deleg_state
     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

then the the client MUST abandon the algorithm and MUST NOT use the
GSS-TSIG algorithm to establish this security contex. 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.

Expires August 28, 2003                                       [Page 6]

INTERNET-DRAFT                   GSS-TSIG            February 28, 2003


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.



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

Expires August 28, 2003                                       [Page 7]

INTERNET-DRAFT                   GSS-TSIG            February 28, 2003

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.


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

If the last call to GSS_Init_sec_context yielded a major_status value
of GSS_S_CONTINUE, 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 error filed 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 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:

Expires August 28, 2003                                       [Page 8]

INTERNET-DRAFT                   GSS-TSIG            February 28, 2003


   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.

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

Expires August 28, 2003                                       [Page 9]

INTERNET-DRAFT                   GSS-TSIG            February 28, 2003


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



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.

Expires August 28, 2003                                      [Page 10]

INTERNET-DRAFT                   GSS-TSIG            February 28, 2003


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.

   INPUTS
     CONTEXT HANDLE input_context_handle  = 0 if new negotiation,