INTERNET-DRAFT Stuart Kwan
Praerit Garg
Ram Viswanathan
Microsoft Corp.
November 1997
<draft-skwan-gss-tsig-00.txt> Expires May 1998
GSS Algorithm for TSIG (GSS-TSIG)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
The 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) [RFC2078].
Expires May 1998 [Page 1]
INTERNET-DRAFT GSS-TSIG November 1997
Table of Contents
1: Introduction......................................................2
2: Record Format for GSS-API Algorithm...............................3
3: Overall Protocol Comments.........................................3
4: Client Protocol Details...........................................4
4.1: Negotiate Security Context......................................4
4.1.1: Continue Negotiation..........................................4
4.1.2: Negotiation Complete..........................................5
4.2: Send Signed Request.............................................5
4.3: Verify Signed Response..........................................6
4.4: Fatal Context Error Response....................................6
5: Server Protocol Details...........................................7
5.1: Process Message.................................................7
5.2: Negotiate Security Context......................................8
5.2.1: Continue Negotiation..........................................8
5.2.2: Negotiation Complete..........................................8
5.3: Verify Signed Request...........................................9
5.4: Send Signed Response............................................9
5.5: Send Fatal Context Error Response..............................10
6: Security Considerations..........................................10
7: Acknowledgements.................................................11
8: References.......................................................11
9: Author's Addresses...............................................11
1. Introduction
The Secret Key Transaction Signature for DNS [TSIG] protocol was
developed to provide a lightweight alternative to full DNS security
[RFC2065] and secure dynamic update [RFC2137], where full security is
impractical due to implementation complexity, management overhead, or
computation cost.
The [TSIG] protocol is extensible through the definition of new
algorithms. This document specifies an algorithm based on the Generic
Security Service Application Program Interface (GSS-API) [RFC2078].
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 for one
transaction, whereas that same server may use TLS with a different
client.
Expires May 1998 [Page 2]
INTERNET-DRAFT GSS-TSIG November 1997
* 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.
GSS-API is not suitable as a comprehensive security mechanism for all
DNS operations. Complete DNS security is addressed by [RFC2065].
The GSS-API algorithm is suitable for the scenarios outlined in
[TSIG].
2. Record Format for GSS-API Algorithm
The format of the TSIG record is specified in [TSIG]. The algorithm
name is TBD. When using this algorithm, the Signature field is
divided up into several sub-fields:
Sub-Field Name Data Type Description
----------------------------------------------------------------
Context ID u_int32_t Uniquely identifies context
Control Flags u_int32_t Flags to control context
GSS_Token Size u_int16_t Size of token if included
GSS_Signature Size u_int16_t Size of signature if included
GSS_Token octet stream Binary encoding of GSS token
GSS_Signature octet stream Binary encoding of signature
3. Overall Protocol Comments
Readers that are unfamiliar with the GSS-API concepts are encouraged
to read the characteristics and concepts section of [RFC2078] before
examining this protocol in detail.
Client and server must be locally authenticated and have acquired
default credentials per [RFC2078] before using this protocol.
Not all flags used in GSS-API interfaces are specified in this
document. Where omitted, clients and servers may select the default
or use a value based on local system policy.
Not all error return values from GSS-API interfaces are specified in
this document. When errors are encountered, the client and server
should act appropriately.
Expires May 1998 [Page 3]
INTERNET-DRAFT GSS-TSIG November 1997
4. Client Protocol Details
4.1 Negotiate Security Context
To begin, the client establishes a security context with a target
server. A security context is established by an exchange of tokens.
To obtain the first token GSS_Init_sec_context is called,
input_context_handle = 0
targ_name = output_name from GSS_Import_Name
(called with SERVICE:dns@servername)
input_token = NULL
The following flags are required by this protocol:
replay_det_req_flag = TRUE (require replay detection)
mutual_req_flag = TRUE (require mutual authentication)
GSS_Init_sec_context returns a token output_token, a return code
major_status, and a set of flags that indicate the capabilities of
the underlying security mechanism. The client must ensure that
replay_det_req_flag and mutual_req_flag are supported before
continuing. Success values of major_status are GSS_S_CONTINUE_NEEDED
and GSS_S_COMPLETE.
4.1.1 Continue Negotiation (major_status == GSS_S_CONTINUE_NEEDED)
If major_status indicates GSS_S_CONTINUE_NEEDED, the client must
send output_token to the server. The server will send a token in
reply. The token is delivered to the server encapsulated in a TSIG
record, where:
Context ID = 0 (new context negotiation)
Control Flags = 0 (no flags)
GSS_Token = output_token from GSS_Init_sec_context
Until the context negotiation is complete, GSS_Signature is empty.
The Time Signed and Expire fields are ignored on unsigned messages
during the negotiation. The output_token is itself signed and
protected against replay attack.
The server will send a token encapsulated in a TSIG RR to the client
in a response message. The Context ID field will have been set by
the server to uniquely identify the session being negotiated. The
client must use this ID in all future messages associated with this
security context. If the response from the server does not contain
a TSIG RR with a token and matching TSIG algorithm name or if the
message RCODE is REFUSED, the client must abandon this algorithm.
Expires May 1998 [Page 4]
INTERNET-DRAFT GSS-TSIG November 1997
The client extracts GSS_Token from the record and passes it as
input_token to GSS_Init_sec_context. If GSS_Init_sec_context again
returns GSS_S_CONTINUE_NEEDED, the process is repeated by sending
another message to the server with a TSIG RR attached, where:
Context ID = Context ID assigned by server in previous message
GSS_Token = output_token from the last call
to GSS_Init_sec_context
Clients should place a limit on the number of continuations for a
given Context ID to prevent endless looping.
4.1.2 Negotiation Complete (major_status == GSS_S_COMPLETE)
If major_status indicates GSS_S_COMPLETE, the client is authenticated.
The client can now exchange signed, secure messages with the server.
GSS_Init_sec_context returns a non-NULL value in output_context_handle
to be used in future GSS operations.
The client may receive GSS_S_COMPLETE on the very first call to
GSS_Init_sec_context, or after exchanging tokens one or more times
with the server. If GSS_S_COMPLETE was received after exchanging
tokens with the server, the message containing the last token may
have been signed by the server, and the client must verify this
signature per the procedure in section 4.3.
4.2 Send Signed Request
To send a signed message to the server, the client creates the
outgoing DNS request message and attaches a TSIG RR:
Time Signed = as appropriate (see [TSIG])
Expire = as appropriate (see [TSIG])
Context ID = Context ID previously assigned by server
If the client wishes to retain the current context for future
messages, it must set the Control Flags field to 0. If the client
is done with this security context it must set Control Flags to 1,
informing the server that it is terminating the context. The context
will be deleted after a response has arrived from the server.
If this is the first message to the server after GSS_Init_sec_context
returned GSS_S_COMPLETE, and if GSS_Init_sec_context returned a
non-NULL output_token, then output_token must be placed in the
GSS_Token field. Subsequent messages do not need to include
output_token.
Expires May 1998 [Page 5]
INTERNET-DRAFT GSS-TSIG November 1997
Signatures are generated using GSS_GetMIC,
context_handle = output_context_handle from GSS_Init_sec_context
message = whole outgoing message in wire format
including TSIG RR with GSS_Signature
field set to zero
If GSS_GetMIC returns GSS_S_COMPLETE, the message signature is
returned in per_msg_token. The message signature is placed into
GSS_Signature in the TSIG RR and the message is sent to the server.
If the client cannot successfully generate a signature, it should log
an appropriate error and terminate the security context.
4.3 Verify Signed Response
When using this protocol, a client can only trust a response from a
server if that response is signed.
A signed message has a non-zero GSS_Signature Size field in the
TSIG RR. Signatures are verified by calling GSS_VerifyMIC,
context_handle = output_context_handle from GSS_Init_sec_context
per_msg_token = GSS_Signature extracted from TSIG RR
message = whole incoming message in wire format
including TSIG RR with GSS_Signature
field set to zero
If GSS_VerifyMIC returns GSS_S_COMPLETE and the Time Signed and
Expire fields are valid according to [TSIG], then the message is
intact and the client can trust the response.
If an error is returned, then the client should log this event
appropriately. The client should resend the original message to the
server at least once to see if a properly signed response can be
obtained.
If the server set Control Flags to 1 in the response, the context is
terminated. The client must delete its context by passing
output_context_handle to GSS_Delete_sec_context.
4.4 Fatal Context Error Response
If the server encounters a fatal error in security context processing,
then it will send to the client an unsigned response with RCODE
REFUSED. The client should assume that the security context is no
longer valid, and negotiate a new context for further transmissions.
Expires May 1998 [Page 6]
INTERNET-DRAFT GSS-TSIG November 1997
5. Server Protocol Details
5.1 Process Message
When a server receives a message containing a TSIG RR with the defined
algorithm, it examines the Context ID field of the record to determine
the state of the security context negotiation.
If Context ID == 0, then the sender is negotiating a new security
context per section 5.2.
If Context ID is non-zero and maps to a context negotiation that has
not yet completed, the server continues the negotiation per section
5.2.1.
If Context ID is non-zero and maps to a completed negotiation, the
server can verify the signature on the message and send a signed
response.
If Context ID is non-zero and does not map to a currently active
context, the server must send the client a fatal context error
response.
5.2 Negotiate Security Context
The client is establishing a new security context with the server.
The server calls GSS_Accept_sec_context,
input_context_handle = 0
input_token = GSS_Token extracted from TSIG RR
The Time Signed and Expire fields must be ignored on unsigned
messages during an unfinished negotiation.
GSS_Accept_sec_context returns output_token and a return code
major_status. Success values of major_status are
GSS_S_CONTINUE_NEEDED and GSS_S_COMPLETE. If the call is successful
then the server associates a unique Context ID to this context. If a
fatal context error is returned, the server must send a fatal context
error message to the client.
Expires May 1998 [Page 7]
INTERNET-DRAFT GSS-TSIG November 1997
5.2.1 Continue Negotiation (major_status == GSS_S_CONTINUE_NEEDED)
If major_status indicates GSS_S_CONTINUE_NEEDED then the context
negotiation is not yet complete. The server must send output_token to
the client and wait for the client to respond with another token. The
token is delivered to the client encapsulated in a TSIG record, where:
Context ID = value associated with this negotiation
Control Flags = 0 (no flags)
GSS_Token = output_token from GSS_Accept_sec_context
After sending the response to the client, the server waits for the
client to send a TSIG RR back with matching Context ID. When the
message arrives, input_token is extracted from the GSS_Token field in
the TSIG RR and passed to GSS_Accept_sec_context.
If GSS_Accept_sec_context again returns GSS_S_CONTINUE_NEEDED, the
process is repeated by sending another message to the client with a
TSIG RR attached, where:
Context ID = Context ID from previous message
GSS_Token = output_token from the last call
to GSS_Accept_sec_context
If GSS_Accept_sec_context returns a fatal context error, the server
must send a fatal context error message to the client.
Servers should place a limit on the number of continuations for a
given Context ID to prevent endless looping. Excessive continuations
should be treated as a fatal context error, and an error message
should be sent to the client.
5.2.2 Negotiation Complete (major_status == GSS_S_COMPLETE)
If major_status indicates GSS_S_COMPLETE, the client is
authenticated. GSS_Accept_sec_context returns a non-NULL value in
output_context_handle. This handle is associated with the current
Context ID and is used in future GSS operations. The context handle
may also be used for other security operations, such as access
control (where available). If the client set the deleg_req_flag to
TRUE when it called GSS_Init_sec_context, then the server may also
call out to other services under the context of the client.
The last message from the client may be signed. If the message is
signed, the signature must be verified using the procedure in
section 5.3.
Expires May 1998 [Page 8]
INTERNET-DRAFT GSS-TSIG November 1997
If the message is not signed then the last call to
GSS_Accept_sec_context must have returned a non-NULL output_token.
This will occur if the server completes its half of the negotiation
before the client. The token must be sent to the client in a signed
response using the procedure in section 5.4.
If the message is not signed and GSS_Accept_sec_context returned
NULL for output_token, then the server was expecting a signed message
from the client. An error message must be sent to the client using
the procedure in section 5.5.
5.3 Verify Signed Request
When using this protocol, the server must not act on any DNS request
from a client if the signature is missing from the message, if the
signature check fails, or if the signature cannot be verified.
A signed message has a non-zero value in the GSS_Signature Size field
of the TSIG RR. To verify a signature in a message the server calls
GSS_VerifyMIC,
context_handle = output_context_handle associated with current
Context ID
per_msg_token = GSS_Signature extracted from TSIG RR
message = whole incoming message in wire format
including TSIG RR with GSS_Signature
field set to zero
If GSS_VerifyMIC returns GSS_S_COMPLETE and the Time Signed and
Expire fields are valid according to [TSIG], then the message is
intact and the server can now act on the DNS request received from
the client.
If GSS_VerifyMIC returns a fatal context error, the server must send
a fatal context error message to the client.
5.4 Send Signed Response
After the server has verified an incoming message and performed the
requested DNS operation, it can send a signed response to the client.
To send a signed response to a client, the client must create the
outgoing DNS request message and then attach a TSIG RR:
Time Signed = as appropriate (see [TSIG])
Expire = as appropriate (see [TSIG])
Context ID = Context ID from request message
Expires May 1998 [Page 9]
INTERNET-DRAFT GSS-TSIG November 1997
If the server wishes to terminate the security context after this
response, it must set Control Flags to 1. Otherwise, Control Flags
must be set the same as the Control Flags in the client's request
message.
If this is the first message to the client after
GSS_Accept_sec_context returned GSS_S_COMPLETE, and if
GSS_Accept_sec_context returned a non-NULL output_token, then
output_token must be placed in the GSS_Token field. Subsequent
messages do not need to include output_token.
The server creates the signature for the response message by calling
GSS_GetMIC,
context_handle = output_context_handle associated with
Context ID from client
message = whole outgoing message in wire format
including TSIG RR with GSS_Signature
field set to zero
If GSS_GetMIC returns GSS_S_COMPLETE, the message signature is
returned in per_msg_token. The message signature is placed into
GSS_Signature and the message is sent to the client.
If GSS_GetMIC returns a fatal context error, the server must send
a fatal context error message to the client.
If the client or server set Control Flags to 1, the server can
terminate the security context by passing the output_context_handle
associated with this Context ID to GSS_Delete_sec_context. The value
of Context ID can now be reused. The server should not reuse this
value in the near future if possible, to avoid possible conflict
between valid clients and clients attempting to reuse a stale context.
5.5 Send Fatal Context Error Response
To send a fatal context error response, the server sends a response
message to the client with the RCODE set to REFUSED.
6. Security Considerations
This document describes a protocol for DNS security using GSS-API.
The security provided by this protocol is only as good as the
security provided by the underlying GSS mechanisms.
Expires May 1998 [Page 10]
INTERNET-DRAFT GSS-TSIG November 1997
7. Acknowledgements
The authors of this document would like to thank the following people
for their contribution to this specification: Chuck Chan and
James Gilroy.
8. References
[RFC2078] J. Linn, "Generic Security Service Application Program
Interface, Version 2," RFC 2078, OpenVision Technologies,
January 1997.
[TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key
Transaction Signatures for DNS (TSIG),"
draft-ietf-dnsind-tsig-01.txt, ISC, TIS, Cybercash,
November 1996, WORK IN PROGRESS: contact paul@vix.com
[RFC2065] D. Eastlake 3rd, C. Kaufman, "Domain Name System Security
Extensions," RFC 2065, Cybercash, Iris, January 1997.
[RFC2137] D. Eastlate 3rd, "Secure Domain Name System Dynamic Update,"
RFC 2137, CyberCash, April 1997.
9. Author's Addresses
Stuart Kwan Praerit Garg
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
<skwan@microsoft.com> <praeritg@microsoft.com>
Ram Viswanathan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
<ramv@microsoft.com>
Expires May 1998 [Page 11]