draft-ietf-dnsext-gss-tsig-01.txt   draft-ietf-dnsext-gss-tsig-02.txt 
INTERNET-DRAFT Stuart Kwan INTERNET-DRAFT Stuart Kwan
<draft-ietf-dnsext-gss-tsig-01.txt> Praerit Garg <draft-ietf-dnsext-gss-tsig-02.txt> Praerit Garg
James Gilroy March 1, 2001 James Gilroy
Levon Esibov Expires September 1, 2001 Levon Esibov
Microsoft Corp. Microsoft Corp.
November 22, 2000 Randy Hall
Expires May 22, 2001 Lucent Technologies
GSS Algorithm for TSIG (GSS-TSIG) GSS Algorithm for TSIG (GSS-TSIG)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1: Introduction......................................................2 1: Introduction......................................................2
2: Algorithm Overview................................................3 2: Algorithm Overview................................................3
2.1: GSS Details...................................................4 2.1: GSS Details...................................................4
3: Client Protocol Details...........................................4 3: Client Protocol Details...........................................4
3.1: Negotiating Context...........................................4 3.1: Negotiating Context...........................................4
3.1.1: Call GSS_Init_sec_context.................................5 3.1.1: Call GSS_Init_sec_context.................................5
3.1.2: Send TKEY Query to Server.................................6 3.1.2: Send TKEY Query to Server.................................6
3.1.3: Receive TKEY Query-Response from Server...................7 3.1.3: Receive TKEY Query-Response from Server...................7
3.2: Context Established...........................................9 3.2: Context Established...........................................9
4: Server Protocol Details...........................................9 3.2.1: Terminating a Context.....................................9
4.1: Negotiating Context...........................................9 4: Server Protocol Details..........................................10
4.1: Negotiating Context..........................................10
4.1.1: Receive TKEY Query from Client...........................10 4.1.1: Receive TKEY Query from Client...........................10
4.1.2: Call GSS_Accept_sec_context..............................10 4.1.2: Call GSS_Accept_sec_context..............................10
4.1.3: Send TKEY Query-Response to Client.......................11 4.1.3: Send TKEY Query-Response to Client.......................11
4.2: Context Established..........................................12 4.2: Context Established..........................................12
4.2.1: Terminating a Context....................................12 4.2.1: Terminating a Context....................................13
5: Sending and Verifying Signed Messages............................12 5: Sending and Verifying Signed Messages............................13
5.1: Sending a Signed Message - Call GSS_GetMIC...................12 5.1: Sending a Signed Message - Call GSS_GetMIC...................13
5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............13 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............14
6: Example usage of GSS-TSIG algorithm..............................14 6: Example usage of GSS-TSIG algorithm..............................15
7: Security Considerations..........................................18 7: Security Considerations..........................................19
8: IANA Considerations..............................................18 8: IANA Considerations..............................................19
9: Conformance......................................................18 9: Conformance......................................................19
10:Acknowledgements.................................................18 10:Acknowledgements.................................................20
11:References.......................................................19 11:References.......................................................20
1. Introduction 1. Introduction
The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol
was developed to provide a lightweight end to end authentication and was developed to provide a lightweight end to end authentication and
integrity of messages between two DNS entities, such as client 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 server or server and server. TSIG can be used to protect dynamic update
messages, authenticate regular message or to off-load complicated messages, authenticate regular message or to off-load complicated
DNSSEC [RFC2535] processing from a client to a server and still allow DNSSEC [RFC2535] processing from a client to a server and still allow
the client to be assured of the integrity off the answers. the client to be assured of the integrity off the answers.
skipping to change at page 6, line 27 skipping to change at page 6, line 27
GSS_S_BAD_NAMETYPE GSS_S_BAD_NAMETYPE
GSS_S_BAD_NAME GSS_S_BAD_NAME
GSS_S_BAD_MECH GSS_S_BAD_MECH
GSS_S_FAILURE GSS_S_FAILURE
Success values of major_status are GSS_S_CONTINUE_NEEDED and Success values of major_status are GSS_S_CONTINUE_NEEDED and
GSS_S_COMPLETE. The exact success code is important during later GSS_S_COMPLETE. The exact success code is important during later
processing. processing.
The values of replay_det_state and mutual_state indicate if the The values of replay_det_state and mutual_state indicate if the
security package provides replay detection and mutual security package provides replay detection and mutual authentication,
authentication, respectively. If one or both of these values respectively. If returned major_status is GSS_S_COMPLETE AND one or both
are FALSE, the client MUST abandon this algorithm. of these values are FALSE, the client MUST abandon this algorithm.
Client's behavior MAY depend on other OUTPUT parameters according Client's behavior MAY depend on other OUTPUT parameters according
to the policy local to the client. to the policy local to the client.
The handle output_context_handle is unique to this negotiation and The handle output_context_handle is unique to this negotiation and
is stored in the client's mapping table as the context_handle that is stored in the client's mapping table as the context_handle that
maps to target_name. maps to target_name.
3.1.2 Send TKEY Query to Server 3.1.2 Send TKEY Query to Server
An opaque output_token returned by GSS_Init_sec_context is transmitted 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 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 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 resource record in the additional records section of the query. The
owner name of the TKEY resource record set queried for and the owner owner name of the TKEY resource record set queried for and the owner
name of the supplied TKEY resource record in the additional records name of the supplied TKEY resource record in the additional records
section MUST be the same. This name uniquely identifies the security section MUST be the same. This name uniquely identifies the security
context to both the client and server, and thus the client SHOULD use context to both the client and server, and thus the client SHOULD use
a value which is globally unique as described in [RFC2930]. a value which is globally unique as described in [RFC2930]. To achieve
global uniqueness, the name MAY contain a UUID/GUID [ISO11578].
TKEY Record TKEY Record
NAME = client-generated globally unique domain name string NAME = client-generated globally unique domain name string
(as described in [RFC2930]) (as described in [RFC2930])
RDATA RDATA
Algorithm Name = gss-tsig Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [RFC2930]) Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets Key Size = size of output_token in octets
Key Data = output_token Key Data = output_token
skipping to change at page 8, line 13 skipping to change at page 8, line 13
is specified by the policy local to the client. is specified by the policy local to the client.
If the signature is verified the context state is advanced to Context If the signature is verified the context state is advanced to Context
Established. Proceed to section 3.2 for usage of the security context. Established. Proceed to section 3.2 for usage of the security context.
3.1.3.2 Value of major_status == GSS_S_CONTINUE 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 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 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 will return to the client a query-response with a TKEY record in the
Answer section. Since the message is not signed, the client MUST Answer section. If the DNS message error is not NO_ERROR or error field
disregard the error code of the DNS message and the TKEY record. The in the TKEY record is not 0 (i.e. no error), then the client MUST
client MUST pass a token specified in the Key Data field in the TKEY abandon this negotiation sequence. The client MUST delete an active
resource record to GSS_Init_sec_context using the same parameters values context by calling GSS_Delete_sec_context providing the associated
as in previous call except values for CONTEXT HANDLE context_handle. The client MAY repeat the negotiation sequence starting
input_context_handle and OCTET STRING input_token as described below: 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.
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:
INPUTS INPUTS
CONTEXT HANDLE input_context_handle = context_handle (this is the CONTEXT HANDLE input_context_handle = context_handle (this is the
context_handle corresponding to the key_name which is the context_handle corresponding to the key_name which is the
owner name of the TKEY record in the answer section in the owner name of the TKEY record in the answer section in the
TKEY query response) TKEY query response)
OCTET STRING input_token = token from Key field of OCTET STRING input_token = token from Key field of
TKEY record TKEY record
Depending on the following OUTPUT values of GSS_Init_sec_context Depending on the following OUTPUT values of GSS_Init_sec_context
skipping to change at page 8, line 48 skipping to change at page 9, line 5
GSS_S_CREDENTIALS_EXPIRED GSS_S_CREDENTIALS_EXPIRED
GSS_S_BAD_BINDINGS GSS_S_BAD_BINDINGS
GSS_S_OLD_TOKEN GSS_S_OLD_TOKEN
GSS_S_DUPLICATE_TOKEN GSS_S_DUPLICATE_TOKEN
GSS_S_NO_CONTEXT GSS_S_NO_CONTEXT
GSS_S_BAD_NAMETYPE GSS_S_BAD_NAMETYPE
GSS_S_BAD_NAME GSS_S_BAD_NAME
GSS_S_BAD_MECH GSS_S_BAD_MECH
GSS_S_FAILURE GSS_S_FAILURE
then client MUST abandon this negotiation sequence. The client MAY the client MUST abandon this negotiation sequence. The client MUST
repeat the negotiation sequence starting with the uninitialized state as delete an active context by calling GSS_Delete_sec_context providing
described in section 3.1. To prevent infinite looping the number of the associated context_handle. The client MAY repeat the negotiation
attempts to establish a security context must be limited. 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.
If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then
client MUST act as described below. client MUST act as described below.
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet 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 finished. The token output_token MUST be passed to the server in a TKEY
record by repeating the negotiation sequence beginning with section record by repeating the negotiation sequence beginning with section
3.1.2. The client MUST place a limit on the number of continuations in 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 a context negotiation to prevent endless looping. Such limit SHOULD NOT
exceed value of 10. exceed value of 10.
skipping to change at page 9, line 29 skipping to change at page 9, line 39
Established. Proceed to section 3.2 for usage of the security context. Established. Proceed to section 3.2 for usage of the security context.
3.2 Context Established 3.2 Context Established
When context negotiation is complete, the handle context_handle MUST be When context negotiation is complete, the handle context_handle MUST be
used for the generation and verification of transaction signatures. used for the generation and verification of transaction signatures.
The procedures for sending and receiving signed messages are described The procedures for sending and receiving signed messages are described
in section 5, Sending and Verifying Signed Messages. 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 4. Server Protocol Details
As on the client-side, the result of a successful context negotiation As on the client-side, the result of a successful context negotiation
is a context handle used in future generation and verification of the is a context handle used in future generation and verification of the
transaction signatures. transaction signatures.
A server MAY be managing several contexts with several clients. A server MAY be managing several contexts with several clients.
Clients identify their contexts by providing a key name in their Clients identify their contexts by providing a key name in their
request. The server maintains a mapping of key names to handles: request. The server maintains a mapping of key names to handles:
skipping to change at page 10, line 13 skipping to change at page 10, line 30
messages. messages.
4.1.1 Receive TKEY Query from Client 4.1.1 Receive TKEY Query from Client
Upon receiving a query with QTYPE = TKEY, the server MUST examine Upon receiving a query with QTYPE = TKEY, the server MUST examine
whether the Mode and Algorithm Name fields of the TKEY record in the whether the Mode and Algorithm Name fields of the TKEY record in the
additional records section of the message contain values of 3 and additional records section of the message contain values of 3 and
gss-tsig, respectively. If they do, then the (key_name, context_handle) 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 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 the TKEY record in the additional records section of the query. If the
name is found in the table, the corresponding context_handle is used in name is found in the table and the security context for this name is
subsequent GSS operations. If the name is not found, then the server established and not expired, then the server MUST respond to the query
interprets this as a start of new security context negotiation. 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 not
found, then the server interprets this query as a start of new security
context negotiation.
4.1.2 Call GSS_Accept_sec_context 4.1.2 Call GSS_Accept_sec_context
The server performs its side of a context negotiation by calling The server performs its side of a context negotiation by calling
GSS_Accept_sec_context. The following input parameters MUST be used. The GSS_Accept_sec_context. The following input parameters MUST be used. The
outcome of the call is indicated with the output values below. Consult 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] Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743[RFC2743]
for syntax definitions. for syntax definitions.
INPUTS INPUTS
skipping to change at page 12, line 24 skipping to change at page 12, line 47
Error, Other Size and Data Fields, MUST be set according to [RFC2930]. Error, Other Size and Data Fields, MUST be set according to [RFC2930].
4.2 Context Established 4.2 Context Established
When context negotiation is complete, the handle context_handle When context negotiation is complete, the handle context_handle
is used for the generation and verification of transaction signatures. is used for the generation and verification of transaction signatures.
The handle is valid for a finite amount of time determined by the The handle is valid for a finite amount of time determined by the
underlying security mechanism. A server MAY unilaterally terminate underlying security mechanism. A server MAY unilaterally terminate
a context at any time (see section 4.2.1). a context at any time (see section 4.2.1).
Server SHOULD limit the amount of memory used to cache established
contexts.
The procedures for sending and receiving signed messages are given in The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages. section 5, Sending and Verifying Signed Messages.
4.2.1 Terminating a Context 4.2.1 Terminating a Context
A server can terminate any established context at any time. The A server can terminate any established context at any time. The
server MAY hint to the client that the context is being deleted server MAY hint to the client that the context is being deleted by
by including a TKEY RR in a response with the Mode field set to 5, i.e. including a TKEY RR in a response with the Mode field set to 5, i.e.
"key deletion" [RFC2930]. "key deletion" [RFC2930].
An active context is deleted by calling GSS_Delete_sec_context An active context is deleted by calling GSS_Delete_sec_context
providing the associated context_handle. providing the associated context_handle.
5. Sending and Verifying Signed Messages 5. Sending and Verifying Signed Messages
5.1 Sending a Signed Message - Call GSS_GetMIC 5.1 Sending a Signed Message - Call GSS_GetMIC
The procedure for sending a signature-protected message is specified The procedure for sending a signature-protected message is specified
in [RFC2845]. The data to be passed to the signature routine includes in [RFC2845]. The data to be passed to the signature routine includes
skipping to change at page 14, line 24 skipping to change at page 14, line 48
INTEGER major_status INTEGER major_status
INTEGER minor_status INTEGER minor_status
INTEGER qop_state INTEGER qop_state
If major_status is GSS_S_COMPLETE, the signature is authentic and the If major_status is GSS_S_COMPLETE, the signature is authentic and the
message was delivered intact. Per [RFC2845], the timer values of the message was delivered intact. Per [RFC2845], the timer values of the
TSIG record MUST also be valid before considering the message to be TSIG record MUST also be valid before considering the message to be
authentic. The caller MUST not act on the request or response in the authentic. The caller MUST not act on the request or response in the
message until these checks are verified. message until these checks are verified.
If major_status is set to one of the following values, the negotiated When a server is processing a client request,
context is no longer valid. the server MUST send a standard TSIG error response to the client
indicating BADKEY in the TSIG error field as described in [RFC2845],
if major_status is set to one of the following values
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_TOKEN
GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_BAD_SIG (GSS_S_BAD_MIC)
GSS_S_DUPLICATE_TOKEN GSS_S_DUPLICATE_TOKEN
GSS_S_OLD_TOKEN GSS_S_OLD_TOKEN
GSS_S_UNSEQ_TOKEN GSS_S_UNSEQ_TOKEN
GSS_S_GAP_TOKEN GSS_S_GAP_TOKEN
GSS_S_CONTEXT_EXPIRED GSS_S_CONTEXT_EXPIRED
GSS_S_NO_CONTEXT GSS_S_NO_CONTEXT
GSS_S_FAILURE GSS_S_FAILURE
If this failure occurs when a server is processing a client request,
the server MUST send a standard TSIG error response to the client
indicating BADKEY in the TSIG error field as described in [RFC2845].
If the timer values of the TSIG record are invalid, the message MUST If the timer values of the TSIG record are invalid, the message MUST
NOT be considered authentic. If this error checking fails when a server NOT be considered authentic. If this error checking fails when a server
is processing a client request, the appropriate error response MUST be is processing a client request, the appropriate error response MUST be
sent to the client according to [RFC2845]. sent to the client according to [RFC2845].
6. Example usage of GSS-TSIG algorithm 6. Example usage of GSS-TSIG algorithm
This Section describes an example where a Client, client.example.com, This Section describes an example where a Client, client.example.com,
and a Server, server.example.com, establish a security context according and a Server, server.example.com, establish a security context according
to the algorithm described above. to the algorithm described above.
skipping to change at page 20, line 26 skipping to change at page 21, line 5
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, OpenVision Technologies, June 1996. RFC 1964, OpenVision Technologies, June 1996.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
RFC 2025, Bell-Northern Research, October 1996. RFC 2025, Bell-Northern Research, October 1996.
[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API [RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, Bull, December 1998. Negotiation Mechanism", RFC 2478, Bull, December 1998.
[ISO11578]"Information technology", "Open Systems
Interconnection", "Remote Procedure Call",
ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html.
12. Author's Addresses 12. Author's Addresses
Stuart Kwan Praerit Garg Stuart Kwan Praerit Garg
Microsoft Corporation Microsoft Corporation Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052 Redmond, WA 98052 Redmond, WA 98052
USA USA USA USA
skwan@microsoft.com skwan@microsoft.com
James Gilroy Levon Esibov James Gilroy Levon Esibov
Microsoft Corporation Microsoft Corporation Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052 Redmond, WA 98052 Redmond, WA 98052
USA USA USA USA
levone@microsoft.com levone@microsoft.com
Randy Hall
Lucent Technologies
400 Lapp Road
Malvern PA 19355
USA
randyhall@lucent.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/