draft-ietf-dnsext-gss-tsig-06.txt   rfc3645.txt 
INTERNET-DRAFT Stuart Kwan Network Working Group S. Kwan
<draft-ietf-dnsext-gss-tsig-06.txt> Praerit Garg Request for Comments: 3645 P. Garg
February 28, 2003 James Gilroy Updates: 2845 J. Gilroy
Expires August 28, 2003 Levon Esibov Category: Standards Track L. Esibov
Jeff Westhead J. Westhead
Microsoft Corp. Microsoft Corp.
Randy Hall R. Hall
Lucent Technologies Lucent Technologies
October 2003
GSS Algorithm for TSIG (GSS-TSIG) Generic Security Service Algorithm for
Secret Key Transaction Authentication for DNS (GSS-TSIG)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document specifies an Internet standards track protocol for the
with all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
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."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
The TSIG protocol provides transaction level authentication for DNS. The Secret Key Transaction Authentication for DNS (TSIG) protocol
TSIG is extensible through the definition of new algorithms. This provides transaction level authentication for DNS. TSIG is
document specifies an algorithm based on the Generic Security Service extensible through the definition of new algorithms. This document
Application Program Interface (GSS-API) (RFC2743). This document updates specifies an algorithm based on the Generic Security Service
RFC 2845. Application Program Interface (GSS-API) (RFC2743). This document
updates RFC 2845.
Table of Contents Table of Contents
1: Introduction......................................................2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2: Algorithm Overview................................................3 2. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . . 3
2.1: GSS Details...................................................4 2.1. GSS Details. . . . . . . . . . . . . . . . . . . . . . . 4
2.2: Modifications to the TSIG protocol (RFC 2845).................4 2.2. Modifications to the TSIG protocol (RFC 2845). . . . . . 4
3: Client Protocol Details...........................................4 3. Client Protocol Details. . . . . . . . . . . . . . . . . . . . 5
3.1: Negotiating Context...........................................5 3.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 5
3.1.1: Call GSS_Init_sec_context.................................5 3.1.1. Call GSS_Init_sec_context. . . . . . . . . . . . . 6
3.1.2: Send TKEY Query to Server.................................7 3.1.2. Send TKEY Query to Server. . . . . . . . . . . . . 8
3.1.3: Receive TKEY Query-Response from Server...................7 3.1.3. Receive TKEY Query-Response from Server. . . . . . 8
3.2: Context Established..........................................10 3.2. Context Established. . . . . . . . . . . . . . . . . . . 11
3.2.1: Terminating a Context....................................10 3.2.1. Terminating a Context. . . . . . . . . . . . . . . 11
4: Server Protocol Details..........................................10 4. Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
4.1: Negotiating Context..........................................10 4.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 12
4.1.1: Receive TKEY Query from Client...........................11 4.1.1. Receive TKEY Query from Client . . . . . . . . . . 12
4.1.2: Call GSS_Accept_sec_context..............................11 4.1.2. Call GSS_Accept_sec_context. . . . . . . . . . . . 12
4.1.3: Send TKEY Query-Response to Client.......................12 4.1.3. Send TKEY Query-Response to Client . . . . . . . . 13
4.2: Context Established..........................................13 4.2. Context Established. . . . . . . . . . . . . . . . . . . 15
4.2.1: Terminating a Context....................................13 4.2.1. Terminating a Context. . . . . . . . . . . . . . . 15
5: Sending and Verifying Signed Messages............................14 5. Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
5.1: Sending a Signed Message - Call GSS_GetMIC...................14 5.1. Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............15 5.2. Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
6: Example usage of GSS-TSIG algorithm..............................16 6. Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
7: Security Considerations..........................................20 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
8: IANA Considerations..............................................20 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
9: Conformance......................................................20 9. Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
10:Acknowledgements.................................................20 10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
11:References.......................................................20 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 1. Introduction
The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
protocol was developed to provide a lightweight authentication and protocol was developed to provide a lightweight 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 server or server and server. TSIG can be used to protect dynamic
update messages, authenticate regular message or to off-load update messages, authenticate regular message or to off-load
complicated DNSSEC [RFC2535] processing from a client to a server and complicated DNSSEC [RFC2535] processing from a client to a server and
still allow the client to be assured of the integrity of the answers. still allow the client to be assured of the integrity of the answers.
The TSIG protocol [RFC2845] is extensible through the definition of new The TSIG protocol [RFC2845] is extensible through the definition of
algorithms. This document specifies an algorithm based on the Generic new algorithms. This document specifies an algorithm based on the
Security Service Application Program Interface (GSS-API) [RFC2743]. Generic Security Service Application Program Interface (GSS-API)
GSS-API is a framework that provides an abstraction of security to the [RFC2743]. GSS-API is a framework that provides an abstraction of
application protocol developer. The security services offered can security to the application protocol developer. The security
include authentication, integrity, and confidentiality. services offered can include authentication, integrity, and
confidentiality.
The GSS-API framework has several benefits: 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 * Mechanism and protocol independence. The underlying mechanisms
creating and managing a security infrastructure. For example, the that realize the security services can be negotiated on the fly
developer does not need to create new key distribution or key and varied over time. For example, a client and server MAY use
management systems. Instead the developer relies on the security Kerberos [RFC1964] for one transaction, whereas that same server
service mechanism to manage this on its behalf. MAY use SPKM [RFC2025] with a different client.
The scope of this document is limited to the description of an * The protocol developer is removed from the responsibility of
authentication mechanism only. It does not discuss and/or propose an creating and managing a security infrastructure. For example, the
authorization mechanism. Readers that are unfamiliar with GSS-API developer does not need to create new key distribution or key
concepts are encouraged to read the characteristics and concepts section management systems. Instead the developer relies on the security
of [RFC2743] before examining this protocol in detail. It is also service mechanism to manage this on its behalf.
assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034]
and [RFC1035].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The scope of this document is limited to the description of an
"RECOMMENDED", and "MAY" in this document are to be interpreted as authentication mechanism only. It does not discuss and/or propose an
described in RFC 2119 [RFC2119]. 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].
2. Algorithm Overview 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].
In GSS, client and server interact to create a "security context". 2. Algorithm Overview
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 In GSS, client and server interact to create a "security context".
server. Once a context has been established, it has a finite lifetime The security context can be used to create and verify transaction
for which it can be used to secure messages. Thus there are three signatures on messages between the two parties. A unique security
states of a context associated with a connection: 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
V | lifetime for which it can be used to secure messages. Thus there are
+---------------+ | three states of a context associated with a connection:
| Uninitialized | |
| | |
+---------------+ |
| |
V |
+---------------+ |
| Negotiating | |
| Context | |
+---------------+ |
| |
V |
+---------------+ |
| Context | |
| Established | |
+---------------+ |
| |
+----------+
Every connection begins in the uninitialized state. +----------+
| |
V |
+---------------+ |
| Uninitialized | |
| | |
+---------------+ |
| |
V |
+---------------+ |
| Negotiating | |
| Context | |
+---------------+ |
| |
V |
+---------------+ |
| Context | |
| Established | |
+---------------+ |
| |
+----------+
2.1 GSS Details Every connection begins in the uninitialized state.
Client and server MUST be locally authenticated and have acquired 2.1. GSS Details
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: 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].
I. Establish security context. The Client and Server use the The GSS-TSIG algorithm consists of two stages:
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 I. Establish security context. The Client and Server use the
verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. These GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate
signatures are exchanged by the Client and Server as a part of the TSIG the tokens that they pass to each other using [RFC2930] as a
records exchanged in DNS messages sent between the Client and Server, transport mechanism.
as described in [RFC2845].
2.2 Modifications to the TSIG protocol (RFC 2845) 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].
Modification to RFC 2845 allows use of TSIG through signing server's 2.2. Modifications to the TSIG protocol (RFC 2845)
response in an explicitly specified place in multi message exchange
between two DNS entities even if client's request wasn't signed.
Specifically Section 4.2 of RFC 2845 MUST be modified as follows. 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.
Replace: Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
"The server MUST not generate a signed response to an unsigned
request."
With: Replace:
"The server MUST not generate a signed response to an unsigned request, "The server MUST not generate a signed response to an unsigned
except in case of response to client's unsigned TKEY query if secret request."
key is established on server side after server processed client's
query. Signing responses to unsigned TKEY queries MUST be explicitly With:
specified in the description of an individual secret key establishment "The server MUST not generate a signed response to an unsigned
algorithm." 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 3. Client Protocol Details
A unique context is required for each server to which the client sends A unique context is required for each server to which the client
secure messages. A context is identified by a context handle. A sends secure messages. A context is identified by a context handle.
client maintains a mapping of servers to handles, A client maintains a mapping of servers to handles:
(target_name, key_name, context_handle) (target_name, key_name, context_handle)
The value key_name also identifies a context handle. The key_name is 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 the owner name of the TKEY and TSIG records sent between a client and
server to indicate to each other which context MUST be used to process a server to indicate to each other which context MUST be used to
the current request. process the current request.
DNS client and server MAY use various underlying security mechanisms to DNS client and server MAY use various underlying security mechanisms
establish security context as described in sections 3 and 4. At the to establish security context as described in sections 3 and 4. At
same time, in order to guarantee interoperability between DNS clients the same time, in order to guarantee interoperability between DNS
and servers that support GSS-TSIG it is REQUIRED that security clients and servers that support GSS-TSIG it is REQUIRED that
mechanism used by client enables use of Kerberos v5 (see Section 9 security mechanism used by client enables use of Kerberos v5 (see
for more information). Section 9 for more information).
3.1 Negotiating Context 3.1. Negotiating Context
In GSS, establishing a security context involves the passing of opaque In GSS, establishing a security context involves the passing of
tokens between the client and the server. The client generates the opaque tokens between the client and the server. The client
initial token and sends it to the server. The server processes the generates the initial token and sends it to the server. The server
token and if necessary, returns a subsequent token to the client. The processes the token and if necessary, returns a subsequent token to
client processes this token, and so on, until the negotiation is the client. The client processes this token, and so on, until the
complete. The number of times the client and server exchange tokens negotiation is complete. The number of times the client and server
depends on the underlying security mechanism. A completed negotiation exchange tokens depends on the underlying security mechanism. A
results in a context handle. completed negotiation results in a context handle.
The TKEY resource record [RFC2930] is used as the vehicle to transfer The TKEY resource record [RFC2930] is used as the vehicle to transfer
tokens between client and server. The TKEY record is a general tokens between client and server. The TKEY record is a general
mechanism for establishing secret keys for use with TSIG. For more mechanism for establishing secret keys for use with TSIG. For more
information, see [RFC2930]. information, see [RFC2930].
3.1.1 Call GSS_Init_sec_context 3.1.1. Call GSS_Init_sec_context
To obtain the first token to be sent to a server, a client MUST call To obtain the first token to be sent to a server, a client MUST call
GSS_Init_sec_context API. 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 The following input parameters MUST be used. The outcome of the call
"GSS_Init_sec_context call" of [RFC2743] for syntax definitions. is indicated with the output values below. Consult Sections 2.2.1,
"GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
INPUTS INPUTS
CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
default"). Client MAY instead specify some other valid handle default"). Client MAY instead specify some other valid
to its credentials. handle to its credentials.
CONTEXT HANDLE input_context_handle = 0 CONTEXT HANDLE input_context_handle = 0
INTERNAL NAME targ_name = "DNS@<target_server_name>" INTERNAL NAME targ_name = "DNS@<target_server_name>"
OBJECT IDENTIFIER mech_type = Underlying security OBJECT IDENTIFIER mech_type = Underlying security
mechanism chosen by implementers. To guarantee mechanism chosen by implementers. To guarantee
interoperability of the implementations of the GSS-TSIG interoperability of the implementations of the GSS-TSIG
mechanism client MUST specify a valid underlying security mechanism client MUST specify a valid underlying security
mechanism that enables use of Kerberos v5 (see Section 9 for mechanism that enables use of Kerberos v5 (see Section 9 for
more information). more information).
OCTET STRING input_token = NULL OCTET STRING input_token = NULL
BOOLEAN replay_det_req_flag = TRUE BOOLEAN replay_det_req_flag = TRUE
BOOLEAN mutual_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE
BOOLEAN deleg_req_flag = TRUE BOOLEAN deleg_req_flag = TRUE
BOOLEAN sequence_req_flag = TRUE BOOLEAN sequence_req_flag = TRUE
BOOLEAN anon_req_flag = FALSE BOOLEAN anon_req_flag = FALSE
BOOLEAN integ_req_flag = TRUE BOOLEAN integ_req_flag = TRUE
INTEGER lifetime_req = 0 (0 requests a default INTEGER lifetime_req = 0 (0 requests a default
value). Client MAY instead specify another upper bound for the value). Client MAY instead specify another upper bound for the
lifetime of the context to be established in seconds. lifetime of the context to be established in seconds.
OCTET STRING chan_bindings = Any valid channel bindings OCTET STRING chan_bindings = Any valid channel bindings
as specified in Section 1.1.6 "Channel Bindings" in [RFC2743] as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
OUTPUTS OUTPUTS
INTEGER major_status INTEGER major_status
CONTEXT HANDLE output_context_handle CONTEXT HANDLE output_context_handle
OCTET STRING output_token OCTET STRING output_token
BOOLEAN replay_det_state BOOLEAN replay_det_state
BOOLEAN mutual_state BOOLEAN mutual_state
skipping to change at page 6, line 32 skipping to change at page 7, line 12
OBJECT IDENTIFIER mech_type OBJECT IDENTIFIER mech_type
BOOLEAN deleg_state BOOLEAN deleg_state
BOOLEAN sequence_state BOOLEAN sequence_state
BOOLEAN anon_state BOOLEAN anon_state
BOOLEAN trans_state BOOLEAN trans_state
BOOLEAN prot_ready_state BOOLEAN prot_ready_state
BOOLEAN conf_avail BOOLEAN conf_avail
BOOLEAN integ_avail BOOLEAN integ_avail
INTEGER lifetime_rec INTEGER lifetime_rec
If returned major_status is set to one of the following errors If returned major_status is set to one of the following errors:
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_TOKEN
GSS_S_DEFECTIVE_CREDENTIAL GSS_S_DEFECTIVE_CREDENTIAL
GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_BAD_SIG (GSS_S_BAD_MIC)
GSS_S_NO_CRED GSS_S_NO_CRED
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 the the client MUST abandon the algorithm and MUST NOT use the then the client MUST abandon the algorithm and MUST NOT use the GSS-
GSS-TSIG algorithm to establish this security contex. This document TSIG algorithm to establish this security context. This document
does not prescribe which other mechanism could be used to establish does not prescribe which other mechanism could be used to establish a
a security context. Next time when this client needs to establish security context. Next time when this client needs to establish
security context, the client MAY use GSS-TSIG algorithm. security context, the client MAY use GSS-TSIG algorithm.
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 authentication, security package provides replay detection and mutual authentication,
respectively. If returned major_status is GSS_S_COMPLETE AND one or both respectively. If returned major_status is GSS_S_COMPLETE AND one or
of these values are FALSE, the client MUST abandon this algorithm. both 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
to the policy local to the client. 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
is stored in the client's mapping table as the context_handle that stored in the client's mapping table as the context_handle that maps
maps to target_name. 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
to the server in a query request with QTYPE=TKEY. The token itself transmitted to the server in a query request with QTYPE=TKEY. The
will be placed in a Key Data field of the RDATA field in the TKEY token itself will be placed in a Key Data field of the RDATA field in
resource record in the additional records section of the query. The the TKEY resource record in the additional records section of the
owner name of the TKEY resource record set queried for and the owner query. The owner name of the TKEY resource record set queried for
name of the supplied TKEY resource record in the additional records and the owner name of the supplied TKEY resource record in the
section MUST be the same. This name uniquely identifies the security additional records section MUST be the same. This name uniquely
context to both the client and server, and thus the client SHOULD use identifies the security context to both the client and server, and
a value which is globally unique as described in [RFC2930]. To achieve thus the client SHOULD use a value which is globally unique as
global uniqueness, the name MAY contain a UUID/GUID [ISO11578]. 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
The remaining fields in the TKEY RDATA, i.e. Inception, Expiration, The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
Error, Other Size and Data Fields, MUST be set according to [RFC2930]. Error, Other Size and Data Fields, MUST be set according to
[RFC2930].
The query is transmitted to the server. The query is transmitted to the server.
Note: if the original client call to GSS_Init_sec_context returned any Note: if the original client call to GSS_Init_sec_context returned
major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE,
the client MUST NOT send TKEY query. Client's behavior in this case is then the client MUST NOT send TKEY query. Client's behavior in this
described above in Section 3.1.1. case is described above in Section 3.1.1.
3.1.3 Receive TKEY Query-Response from Server 3.1.3. Receive TKEY Query-Response from Server
Upon the reception of the TKEY query DNS server MUST respond according Upon the reception of the TKEY query the DNS server MUST respond
to the description in Section 4. This Section specifies the behavior according to the description in Section 4. This section specifies
of the client after it receives the matching response to its query. 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 The next processing step depends on the value of major_status from
most recent call that client performed to GSS_Init_sec_context: either the most recent call that client performed to GSS_Init_sec_context:
GSS_S_COMPLETE or GSS_S_CONTINUE. either GSS_S_COMPLETE or GSS_S_CONTINUE.
3.1.3.1 Value of major_status == GSS_S_COMPLETE 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 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, 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 then the client side component of the negotiation is complete and the
client is awaiting confirmation from the server. client is awaiting confirmation from the server.
Confirmation is in the form of a query response with RCODE=NOERROR Confirmation is in the form of a query response with RCODE=NOERROR
and with the last client supplied TKEY record in the answer section 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 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 that the server is allowed to sign a response to unsigned client's
due to modification to the RFC 2845 specified in Section 2.2 above. query due to modification to the RFC 2845 specified in Section 2.2
The signature in the TSIG record MUST be verified using the procedure above. The signature in the TSIG record MUST be verified using the
detailed in section 5, Sending and Verifying Signed Messages. If the procedure detailed in section 5, Sending and Verifying Signed
response is not signed, OR if the response is signed but signature is Messages. If the response is not signed, OR if the response is
invalid, then an attacker has tampered with the message in transit or signed but the signature is invalid, then an attacker has tampered
has attempted to send the client a false response. In this case the with the message in transit or has attempted to send the client a
client MAY continue waiting for a response to its last TKEY query until false response. In this case, the client MAY continue waiting for a
the time period since the client sent last TKEY query expires. Such a response to its last TKEY query until the time period since the
time period is specified by the policy local to the client. This is a client sent last TKEY query expires. Such a time period is specified
new option that allows DNS client to accept multiple answers for one by the policy local to the client. This is a new option that allows
query ID and select one (not necessarily the first one) based on some the DNS client to accept multiple answers for one query ID and select
criteria. one (not necessarily the first one) based on some criteria.
If the signature is verified the context state is advanced to Context If the signature is verified, the context state is advanced to
Established. Proceed to section 3.2 for usage of the security context. 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_NEEDED
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_NEEDED, then the negotiation is not yet complete.
will return to the client a query-response with a TKEY record in the The server will return to the client a query response with a TKEY
Answer section. If the DNS message error is not NO_ERROR or error field record in the Answer section. If the DNS message error is not
in the TKEY record is not 0 (i.e. no error), then the client MUST NO_ERROR or error field in the TKEY record is not 0 (i.e., no error),
abandon this negotiation sequence. The client MUST delete an active then the client MUST abandon this negotiation sequence. The client
context by calling GSS_Delete_sec_context providing the associated MUST delete an active context by calling GSS_Delete_sec_context
context_handle. The client MAY repeat the negotiation sequence starting providing the associated context_handle. The client MAY repeat the
with the uninitialized state as described in section 3.1. To prevent negotiation sequence starting with the uninitialized state as
infinite looping the number of attempts to establish a security context described in section 3.1. To prevent infinite looping the number of
MUST be limited to ten or less. 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 If the DNS message error is NO_ERROR and the error field in the TKEY
is 0 (i.e. no error), then the client MUST pass a token specified in the record is 0 (i.e., no error), then the client MUST pass a token
Key Data field in the TKEY resource record to GSS_Init_sec_context specified in the Key Data field in the TKEY resource record to
using the same parameters values as in previous call except values for GSS_Init_sec_context using the same parameters values as in previous
CONTEXT HANDLE input_context_handle and OCTET STRING input_token as call except values for CONTEXT HANDLE input_context_handle and OCTET
described below: 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
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 INTEGER major_status
GSS_S_DEFECTIVE_TOKEN OCTET STRING output_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 the client MUST take one of the following actions:
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 If OUTPUT major_status is set to one of the following values:
client MUST act as described below.
If the response from the server was signed, and the OUTPUT major_status GSS_S_DEFECTIVE_TOKEN
is GSS_S_COMPLETE,then the signature in the TSIG record MUST be verified GSS_S_DEFECTIVE_CREDENTIAL
using the procedure detailed in section 5, Sending and Verifying Signed GSS_S_BAD_SIG (GSS_S_BAD_MIC)
Messages. If the signature is invalid, then the client MUST abandon this GSS_S_NO_CRED
negotiation sequence. This means that the client MUST delete an active GSS_S_CREDENTIALS_EXPIRED
context by calling GSS_Delete_sec_context providing the associated GSS_S_BAD_BINDINGS
context_handle. The client MAY repeat the negotiation sequence starting GSS_S_OLD_TOKEN
with the uninitialized state as described in section 3.1. To prevent GSS_S_DUPLICATE_TOKEN
infinite looping the number of attempts to establish a security context GSS_S_NO_CONTEXT
MUST be limited to ten or less. GSS_S_BAD_NAMETYPE
GSS_S_BAD_NAME
GSS_S_BAD_MECH
GSS_S_FAILURE
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet the client MUST abandon this negotiation sequence. This means that
finished. The token output_token MUST be passed to the server in a TKEY the client MUST delete an active context by calling
record by repeating the negotiation sequence beginning with section GSS_Delete_sec_context providing the associated context_handle. The
3.1.2. The client MUST place a limit on the number of continuations in client MAY repeat the negotiation sequence starting with the
a context negotiation to prevent endless looping. Such limit SHOULD NOT uninitialized state as described in section 3.1. To prevent infinite
exceed value of 10. looping the number of attempts to establish a security context MUST
be limited to ten or less.
If major_status is GSS_S_COMPLETE and output_token is non-NULL, the If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE
client-side component of the negotiation is complete but the token then client MUST act as described below.
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 If the response from the server was signed, and the OUTPUT
negotiation is complete. The context state is advanced to Context major_status is GSS_S_COMPLETE,then the signature in the TSIG record
Established. Proceed to section 3.2 for usage of the security context. 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.
3.2 Context Established 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.
When context negotiation is complete, the handle context_handle MUST be If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
used for the generation and verification of transaction signatures. 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.
The procedures for sending and receiving signed messages are described If major_status is GSS_S_COMPLETE and output_token is NULL, context
in section 5, Sending and Verifying Signed Messages. negotiation is complete. The context state is advanced to Context
Established. Proceed to section 3.2 for usage of the security
context.
3.2.1 Terminating a Context 3.2. Context Established
When the client is not intended to continue using the established When context negotiation is complete, the handle context_handle MUST
security context, the client SHOULD delete an active context by be used for the generation and verification of transaction
calling GSS_Delete_sec_context providing the associated context_handle, signatures.
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" The procedures for sending and receiving signed messages are
[RFC2930]. 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 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:
(key_name, context_handle) (key_name, context_handle)
4.1 Negotiating Context 4.1. Negotiating Context
A server MUST recognize TKEY queries as security context negotiation A server MUST recognize TKEY queries as security context negotiation
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,
mapping table is searched for the key_name matching the owner name of context_handle) mapping table is searched for the key_name matching
the TKEY record in the additional records section of the query. If the the owner name of the TKEY record in the additional records section
name is found in the table and the security context for this name is of the query. If the name is found in the table and the security
established and not expired, then the server MUST respond to the query context for this name is established and not expired, then the server
with BADNAME error in the TKEY error field. If the name is found in the MUST respond to the query with BADNAME error in the TKEY error field.
table and the security context is not established, the corresponding If the name is found in the table and the security context is not
context_handle is used in subsequent GSS operations. If the name is established, the corresponding context_handle is used in subsequent
found but the security context is expired, then the server deletes this GSS operations. If the name is found but the security context is
security context, as described in Section 4.2.1, and interprets this expired, then the server deletes this security context, as described
query as a start of new security context negotiation and performs in Section 4.2.1, and interprets this query as a start of new
operations described in Section 4.1.2 and 4.1.3. If the name is not security context negotiation and performs operations described in
found, then the server interprets this query as a start of new security Section 4.1.2 and 4.1.3. If the name is not found, then the server
context negotiation and performs operations described in Section 4.1.2 interprets this query as a start of new security context negotiation
and 4.1.3. and performs operations described in Section 4.1.2 and 4.1.3.
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.
outcome of the call is indicated with the output values below. Consult The outcome of the call is indicated with the output values below.
Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743[RFC2743] Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743
for syntax definitions. [RFC2743] for syntax definitions.
INPUTS INPUTS
CONTEXT HANDLE input_context_handle = 0 if new negotiation, CONTEXT HANDLE input_context_handle = 0 if new negotiation,
context_handle matching context_handle matching
key_name if ongoing negotiation key_name if ongoing negotiation
OCTET STRING input_token = token specified in the Key OCTET STRING input_token = token specified in the Key
field from TKEY RR (from Additional records Section of field from TKEY RR (from Additional records Section of
the client's query) the client's query)
CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
default"). Server MAY instead specify some other valid handle default"). Server MAY instead specify some other valid
to its credentials. handle to its credentials.
OCTET STRING chan_bindings = Any valid channel bindings OCTET STRING chan_bindings = Any valid channel bindings
as specified in Section 1.1.6 "Channel Bindings" in [RFC2743] as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
OUTPUTS OUTPUTS
INTEGER major_status INTEGER major_status
CONTEXT_HANDLE output_context_handle CONTEXT_HANDLE output_context_handle
OCTET STRING output_token OCTET STRING output_token
INTEGER minor_status INTEGER minor_status
INTERNAL NAME src_name INTERNAL NAME src_name
OBJECT IDENTIFIER mech_type OBJECT IDENTIFIER mech_type
skipping to change at page 12, line 15 skipping to change at page 13, line 38
BOOLEAN replay_det_state BOOLEAN replay_det_state
BOOLEAN sequence_state BOOLEAN sequence_state
BOOLEAN anon_state BOOLEAN anon_state
BOOLEAN trans_state BOOLEAN trans_state
BOOLEAN prot_ready_state BOOLEAN prot_ready_state
BOOLEAN conf_avail BOOLEAN conf_avail
BOOLEAN integ_avail BOOLEAN integ_avail
INTEGER lifetime_rec INTEGER lifetime_rec
CONTEXT_HANDLE delegated_cred_handle CONTEXT_HANDLE delegated_cred_handle
If this is the first call to GSS_Accept_sec_context in a new 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 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 key-mapping table as the context_handle that maps to the name of the
TKEY record. TKEY record.
4.1.3 Send TKEY Query-Response to Client 4.1.3. Send TKEY Query-Response to Client
The server MUST respond to the client with a TKEY query response with The server MUST respond to the client with a TKEY query response with
RCODE = NOERROR, that contains a TKEY record in the answer section. RCODE = NOERROR, that contains a TKEY record in the answer section.
If OUTPUT major_status is one of the following errors the error field If OUTPUT major_status is one of the following errors the error field
in the TKEY record set to BADKEY. in the TKEY record set to BADKEY.
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_TOKEN
GSS_S_DEFECTIVE_CREDENTIAL GSS_S_DEFECTIVE_CREDENTIAL
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_NO_CRED GSS_S_NO_CRED
GSS_S_CREDENTIALS_EXPIRED GSS_S_CREDENTIALS_EXPIRED
GSS_S_BAD_BINDINGS GSS_S_BAD_BINDINGS
GSS_S_NO_CONTEXT GSS_S_NO_CONTEXT
GSS_S_BAD_MECH GSS_S_BAD_MECH
GSS_S_FAILURE GSS_S_FAILURE
If OUTPUT major_status is set to GSS_S_COMPLETE or If OUTPUT major_status is set to GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED then server MUST act as described below. GSS_S_CONTINUE_NEEDED then server MUST act as described below.
If major_status is GSS_S_COMPLETE the server component of the If major_status is GSS_S_COMPLETE the server component of the
negotiation is finished. If output_token is non-NULL, then it MUST be negotiation is finished. If output_token is non-NULL, then it MUST
returned to the client in a Key Data field of the RDATA in TKEY. The be returned to the client in a Key Data field of the RDATA in TKEY.
error field in the TKEY record is set to NOERROR. The message MUST be The error field in the TKEY record is set to NOERROR. The message
signed with a TSIG record as described in section 5, Sending and MUST be signed with a TSIG record as described in section 5, Sending
Verifying Signed Messages. Note that server is allowed to sign a and Verifying Signed Messages. Note that server is allowed to sign a
response to unsigned client's query due to modification to the RFC response to unsigned client's query due to modification to the RFC
2845 specified in Section 2.2 above. The context state is advanced to 2845 specified in Section 2.2 above. The context state is advanced
Context Established. Section 4.2 discusses the usage of the security to Context Established. Section 4.2 discusses the usage of the
context. security context.
If major_status is GSS_S_COMPLETE and output_token is NULL, then the If major_status is GSS_S_COMPLETE and output_token is NULL, then the
TKEY record received from the client MUST be returned in the Answer TKEY record received from the client MUST be returned in the Answer
section of the response. The message MUST be signed with a TSIG record section of the response. The message MUST be signed with a TSIG
as described in section 5, Sending and Verifying Signed Messages. Note record as described in section 5, Sending and Verifying Signed
that server is allowed to sign a response to unsigned client's query Messages. Note that server is allowed to sign a response to unsigned
due to modification to the RFC 2845 specified in section 2.2 above. The client's query due to modification to the RFC 2845 specified in
context state is advanced to Context Established. Section 4.2 discusses section 2.2 above. The context state is advanced to Context
the usage of the security context. Established. Section 4.2 discusses the usage of the security
context.
If major_status is GSS_S_CONTINUE, the server component of the If major_status is GSS_S_CONTINUE_NEEDED, the server component of the
negotiation is not yet finished. The server responds to the TKEY negotiation is not yet finished. The server responds to the TKEY
query with a standard query response, placing in the answer section a query with a standard query response, placing in the answer section a
TKEY record containing output_token in the Key Data RDATA field. The TKEY record containing output_token in the Key Data RDATA field. The
error field in the TKEY record is set to NOERROR. The server MUST limit error field in the TKEY record is set to NOERROR. The server MUST
the number of times that a given context is allowed to repeat, to limit the number of times that a given context is allowed to repeat,
prevent endless looping. Such limit SHOULD NOT exceed value of 10. to prevent endless looping. Such limit SHOULD NOT exceed value of
10.
In all cases except if major_status is GSS_S_COMPLETE and output_token In all cases, except if major_status is GSS_S_COMPLETE and
is NULL other TKEY record fields MUST contain the following values: output_token is NULL, other TKEY record fields MUST contain the
NAME = key_name following values:
RDATA
Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets
The remaining fields in the TKEY RDATA, i.e. Inception, Expiration, NAME = key_name
Error, Other Size and Data Fields, MUST be set according to [RFC2930]. RDATA
Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets
4.2 Context Established The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
Error, Other Size and Data Fields, MUST be set according to
[RFC2930].
When context negotiation is complete, the handle context_handle 4.2. Context Established
is used for the generation and verification of transaction signatures.
The handle is valid for a finite amount of time determined by the
underlying security mechanism. A server MAY unilaterally terminate
a context at any time (see section 4.2.1).
Server SHOULD limit the amount of memory used to cache established When context negotiation is complete, the handle context_handle is
contexts. used for the generation and verification of transaction signatures.
The handle is valid for a finite amount of time determined by the
underlying security mechanism. A server MAY unilaterally terminate a
context at any time (see section 4.2.1).
The procedures for sending and receiving signed messages are given in Server SHOULD limit the amount of memory used to cache established
section 5, Sending and Verifying Signed Messages. contexts.
4.2.1 Terminating a Context The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages.
A server can terminate any established context at any time. The 4.2.1. Terminating a Context
server MAY hint to the client that the context is being deleted by
including a TKEY RR in a response with the Mode field set to 5, i.e.
"key deletion" [RFC2930].
An active context is deleted by calling GSS_Delete_sec_context
providing the associated context_handle.
5. Sending and Verifying Signed Messages A server can terminate any established context at any time. The
server MAY hint to the client that the context is being deleted by
including a TKEY RR in a response with the Mode field set to 5, i.e.,
"key deletion" [RFC2930]. An active context is deleted by calling
GSS_Delete_sec_context providing the associated context_handle.
5.1 Sending a Signed Message - Call GSS_GetMIC 5. Sending and Verifying Signed Messages
The procedure for sending a signature-protected message is specified 5.1. Sending a Signed Message - Call GSS_GetMIC
in [RFC2845]. The data to be passed to the signature routine includes
the whole DNS message with specific TSIG variables appended. For the
exact format, see [RFC2845]. For this protocol, use the following
TSIG variable values:
TSIG Record The procedure for sending a signature-protected message is specified
NAME = key_name that identifies this context in [RFC2845]. The data to be passed to the signature routine
RDATA includes the whole DNS message with specific TSIG variables appended.
Algorithm Name = gss-tsig For the exact format, see [RFC2845]. For this protocol, use the
following TSIG variable values:
Assign the remaining fields in the TSIG RDATA appropriate values TSIG Record
as described in [RFC2845]. NAME = key_name that identifies this context
RDATA
Algorithm Name = gss-tsig
The signature is generated by calling GSS_GetMIC. The following input Assign the remaining fields in the TSIG RDATA appropriate values as
parameters MUST be used. The outcome of the call is indicated with the described in [RFC2845].
output values specified below. Consult Sections 2.3.1 "GSS_GetMIC
call" of the RFC 2743[RFC2743] for syntax definitions. The signature is generated by calling GSS_GetMIC. The following
input parameters MUST be used. The outcome of the call is indicated
with the output values specified below. Consult Sections 2.3.1
"GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions.
INPUTS INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name CONTEXT HANDLE context_handle = context_handle for key_name
OCTET STRING message = outgoing message plus TSIG OCTET STRING message = outgoing message plus TSIG
variables (per [RFC2845]) variables (per [RFC2845])
INTEGER qop_req = 0 (0 requests a default INTEGER qop_req = 0 (0 requests a default
value). Caller MAY instead specify other valid value (for value). Caller MAY instead specify other valid value (for
details see Section 1.2.4 in [RFC2743]) details see Section 1.2.4 in [RFC2743])
OUTPUTS OUTPUTS
INTEGER major_status INTEGER major_status
INTEGER minor_status INTEGER minor_status
OCTET STRING per_msg_token OCTET STRING per_msg_token
If major_status is GSS_S_COMPLETE, then signature generation If major_status is GSS_S_COMPLETE, then signature generation
succeeded. The signature in per_msg_token is inserted into the succeeded. The signature in per_msg_token is inserted into the
Signature field of the TSIG RR and the message is transmitted. Signature field of the TSIG RR and the message is transmitted.
If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED or If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED
GSS_S_FAILURE the caller MUST delete the security context, return to the or GSS_S_FAILURE the caller MUST delete the security context, return
uninitialized state and SHOULD negotiate a new security context, as to the uninitialized state and SHOULD negotiate a new security
described above in Section 3.1 context, as described above in Section 3.1
If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry
for key_name from the (target_ name, key_name, context_handle) mapping for key_name from the (target_ name, key_name, context_handle)
table, return to the uninitialized state and SHOULD negotiate a new mapping table, return to the uninitialized state and SHOULD negotiate
security context, as described above in Section 3.1 a new security context, as described above in Section 3.1
If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the
GSS_GetMIC call with allowed QOP value. The number of such repetitions GSS_GetMIC call with allowed QOP value. The number of such
MUST be limited to prevent infinite loops. repetitions MUST be limited to prevent infinite loops.
5.2 Verifying a Signed Message - Call GSS_VerifyMIC 5.2. Verifying a Signed Message - Call GSS_VerifyMIC
The procedure for verifying a signature-protected message is specified The procedure for verifying a signature-protected message is
in [RFC2845]. specified in [RFC2845].
The NAME of the TSIG record determines which context_handle maps to
the context that MUST be used to verify the signature. If the NAME The NAME of the TSIG record determines which context_handle maps to
does not map to an established context, the server MUST send a the context that MUST be used to verify the signature. If the NAME
standard TSIG error response to the client indicating BADKEY in the does not map to an established context, the server MUST send a
TSIG error field (as described in [RFC2845]). standard TSIG error response to the client indicating BADKEY in the
TSIG error field (as described in [RFC2845]).
For the GSS algorithm, a signature is verified by using
GSS_VerifyMIC:
For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
INPUTS INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name CONTEXT HANDLE context_handle = context_handle for key_name
OCTET STRING message = incoming message plus TSIG OCTET STRING message = incoming message plus TSIG
variables (per [RFC2845]) variables (per [RFC2845])
OCTET STRING per_msg_token = Signature field from TSIG RR OCTET STRING per_msg_token = Signature field from TSIG RR
OUTPUTS OUTPUTS
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.
When a server is processing a client request, When a server is processing a client request, the server MUST send a
the server MUST send a standard TSIG error response to the client standard TSIG error response to the client indicating BADKEY in the
indicating BADKEY in the TSIG error field as described in [RFC2845], TSIG error field as described in [RFC2845], if major_status is set to
if major_status is set to one of the following values one of the following values
GSS_S_DEFECTIVE_TOKEN
GSS_S_BAD_SIG (GSS_S_BAD_MIC)
GSS_S_DUPLICATE_TOKEN
GSS_S_OLD_TOKEN
GSS_S_UNSEQ_TOKEN
GSS_S_GAP_TOKEN
GSS_S_CONTEXT_EXPIRED
GSS_S_NO_CONTEXT
GSS_S_FAILURE
If the timer values of the TSIG record are invalid, the message MUST GSS_S_DEFECTIVE_TOKEN
NOT be considered authentic. If this error checking fails when a server GSS_S_BAD_SIG (GSS_S_BAD_MIC)
is processing a client request, the appropriate error response MUST be GSS_S_DUPLICATE_TOKEN
sent to the client according to [RFC2845]. GSS_S_OLD_TOKEN
GSS_S_UNSEQ_TOKEN
GSS_S_GAP_TOKEN
GSS_S_CONTEXT_EXPIRED
GSS_S_NO_CONTEXT
GSS_S_FAILURE
6. Example usage of GSS-TSIG algorithm 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 is processing a client request, the appropriate error response
MUST be sent to the client according to [RFC2845].
This Section describes an example where a Client, client.example.com, 6. Example usage of GSS-TSIG algorithm
and a Server, server.example.com, establish a security context according
to the algorithm described above. This Section describes an example where a Client, client.example.com,
and a Server, server.example.com, establish a security context
according to the algorithm described above.
I. Client initializes security context negotiation
I. Client initializes security context negotiation
To establish a security context with a server, server.example.com, the To establish a security context with a server, server.example.com, the
Client calls GSS_Init_sec_context with the following parameters Client calls GSS_Init_sec_context with the following parameters.
(Note that some INPUT and OUTPUT parameters not critical for this (Note that some INPUT and OUTPUT parameters not critical for this
algorithm are not described in this example) algorithm are not described in this example.)
CONTEXT HANDLE input_context_handle = 0 CONTEXT HANDLE input_context_handle = 0
INTERNAL NAME targ_name = "DNS@server.example.com" INTERNAL NAME targ_name = "DNS@server.example.com"
OCTET STRING input_token = NULL OCTET STRING input_token = NULL
BOOLEAN replay_det_req_flag = TRUE BOOLEAN replay_det_req_flag = TRUE
BOOLEAN mutual_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE
The OUTPUTS parameters returned by GSS_Init_sec_context include The OUTPUTS parameters returned by GSS_Init_sec_context include
INTEGER major_status = GSS_S_CONTINUE_NEEDED INTEGER major_status = GSS_S_CONTINUE_NEEDED
CONTEXT HANDLE output_context_handle context_handle CONTEXT HANDLE output_context_handle context_handle
OCTET STRING output_token output_token OCTET STRING output_token output_token
BOOLEAN replay_det_state = TRUE BOOLEAN replay_det_state = TRUE
BOOLEAN mutual_state = TRUE BOOLEAN mutual_state = TRUE
Client verifies that replay_det_state and mutual_state values are Client verifies that replay_det_state and mutual_state values are
TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
success OUTPUT major_status value, client stores context_handle that success OUTPUT major_status value, client stores context_handle that
maps to "DNS@server.example.com" and proceeds to the next step. maps to "DNS@server.example.com" and proceeds to the next step.
II. Client sends a query with QTYPE = TKEY to server II. Client sends a query with QTYPE = TKEY to server
Client sends a query with QTYPE = TKEY for a client-generated globally Client sends a query with QTYPE = TKEY for a client-generated globally
unique domain name string, 789.client.example.com.server.example.com. unique domain name string, 789.client.example.com.server.example.com.
Query contains a TKEY record in its Additional records section with Query contains a TKEY record in its Additional records section with
the following fields (Note that some fields not specific to this the following fields. (Note that some fields not specific to this
algorithm are not specified) algorithm are not specified.)
NAME = 789.client.example.com.server.example.com. NAME = 789.client.example.com.server.example.com.
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
After the key_name 789.client.example.com.server.example.com. After the key_name 789.client.example.com.server.example.com.
is generated it is stored in the client's (target_name, key_name, is generated it is stored in the client's (target_name, key_name,
context_handle) mapping table. context_handle) mapping table.
III. Server receives a query with QTYPE = TKEY III. Server receives a query with QTYPE = TKEY
When server receives a query with QTYPE = TKEY, the server verifies When server receives a query with QTYPE = TKEY, the server verifies
that Mode and Algorithm fields in the TKEY record in the Additional that Mode and Algorithm fields in the TKEY record in the Additional
records section of the query are set to 3 and "gss-tsig" respectively. records section of the query are set to 3 and "gss-tsig" respectively.
It finds that the key_name 789.client.example.com.server.example.com. It finds that the key_name 789.client.example.com.server.example.com.
is not listed in its (key_name, context_handle) mapping table. is not listed in its (key_name, context_handle) mapping table.
IV. Server calls GSS_Accept_sec_context IV. Server calls GSS_Accept_sec_context
To continue security context negotiation server calls To continue security context negotiation server calls
GSS_Accept_sec_context with the following parameters (Note that some GSS_Accept_sec_context with the following parameters. (Note that
INPUT and OUTPUT parameters not critical for this algorithm are not some INPUT and OUTPUT parameters not critical for this algorithm
described in this example) are not described in this example.)
INPUTS INPUTS
CONTEXT HANDLE input_context_handle = 0 CONTEXT HANDLE input_context_handle = 0
OCTET STRING input_token = token specified in the Key OCTET STRING input_token = token specified in the Key
field from TKEY RR (from Additional field from TKEY RR (from Additional
records section of the client's query) records section of the client's query)
The OUTPUTS parameters returned by GSS_Accept_sec_context include The OUTPUTS parameters returned by GSS_Accept_sec_context include
INTEGER major_status = GSS_S_CONTINUE_NEEDED INTEGER major_status = GSS_S_CONTINUE_NEEDED
CONTEXT_HANDLE output_context_handle context_handle CONTEXT_HANDLE output_context_handle context_handle
OCTET STRING output_token output_token OCTET STRING output_token output_token
Server stores the mapping of the Server stores the mapping of the
789.client.example.com.server.example.com. to OUTPUT context_handle 789.client.example.com.server.example.com. to OUTPUT context_handle
in its (key_name, context_handle) mapping table. in its (key_name, context_handle) mapping table.
V. Server responds to the TKEY query V. Server responds to the TKEY query
Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
call to GSS_Accept_sec_context, the server responds to the TKEY query call to GSS_Accept_sec_context, the server responds to the TKEY query
placing in the answer section a TKEY record containing output_token in placing in the answer section a TKEY record containing output_token in
the Key Data RDATA field. The error field in the TKEY record is set to the Key Data RDATA field. The error field in the TKEY record is set
0. The RCODE in the query response is set to NOERROR. to 0. The RCODE in the query response is set to NOERROR.
VI. Client processes token returned by server
VI. Client processes token returned by server
When the client receives the TKEY query response from the server, the When the client receives the TKEY query response from the server, the
client calls GSS_Init_sec_context with the following parameters (Note client calls GSS_Init_sec_context with the following parameters.
that some INPUT and OUTPUT parameters not critical for this algorithm (Note that some INPUT and OUTPUT parameters not critical for this
are not described in this example) algorithm are not described in this example.)
CONTEXT HANDLE input_context_handle = the context_handle stored CONTEXT HANDLE input_context_handle = the context_handle stored
in the client's mapping table entry (DNS@server.example.com., in the client's mapping table entry (DNS@server.example.com.,
789.client.example.com.server.example.com., context_handle) 789.client.example.com.server.example.com., context_handle)
INTERNAL NAME targ_name = "DNS@server.example.com" INTERNAL NAME targ_name = "DNS@server.example.com"
OCTET STRING input_token = token from Key field of TKEY OCTET STRING input_token = token from Key field of TKEY
record from the Answer section of the server's response record from the Answer section of the server's response
BOOLEAN replay_det_req_flag = TRUE BOOLEAN replay_det_req_flag = TRUE
BOOLEAN mutual_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE
The OUTPUTS parameters returned by GSS_Init_sec_context include The OUTPUTS parameters returned by GSS_Init_sec_context include
INTEGER major_status = GSS_S_COMPLETE INTEGER major_status = GSS_S_COMPLETE
CONTEXT HANDLE output_context_handle = context_handle CONTEXT HANDLE output_context_handle = context_handle
OCTET STRING output_token = output_token OCTET STRING output_token = output_token
BOOLEAN replay_det_state = TRUE BOOLEAN replay_det_state = TRUE
BOOLEAN mutual_state = TRUE BOOLEAN mutual_state = TRUE
Since the major_status is set to GSS_S_COMPLETE the client side Since the major_status is set to GSS_S_COMPLETE the client side
security context is established, but since the output_token is not security context is established, but since the output_token is not
NULL client MUST send a TKEY query to the server as described below. NULL client MUST send a TKEY query to the server as described below.
VII. Client sends a query with QTYPE = TKEY to server VII. Client sends a query with QTYPE = TKEY to server
Client sends to the server a TKEY query for the Client sends to the server a TKEY query for the
789.client.example.com.server.example.com. name. Query contains a TKEY 789.client.example.com.server.example.com. name. Query contains a
record in its Additional records section with the following fields TKEY record in its Additional records section with the following
(Note that some INPUT and OUTPUT parameters not critical to this fields. (Note that some INPUT and OUTPUT parameters not critical to
algorithm are not described in this example) this algorithm are not described in this example.)
NAME = 789.client.example.com.server.example.com. NAME = 789.client.example.com.server.example.com.
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
VIII. Server receives a TKEY query VIII. Server receives a TKEY query
When the server receives a TKEY query, the server verifies that Mode When the server receives a TKEY query, the server verifies that Mode
and Algorithm fields in the TKEY record in the Additional records and Algorithm fields in the TKEY record in the Additional records
section of the query are set to 3 and gss-tsig, repectively. It section of the query are set to 3 and gss-tsig, respectively. It
finds that the key_name 789.client.example.com.server.example.com. is finds that the key_name 789.client.example.com.server.example.com. is
listed in its (key_name, context_handle) mapping table. listed in its (key_name, context_handle) mapping table.
IX. Server calls GSS_Accept_sec_context IX. Server calls GSS_Accept_sec_context
To continue security context negotiation server calls To continue security context negotiation server calls
GSS_Accept_sec_context with the following parameters (Note that some GSS_Accept_sec_context with the following parameters (Note that some
INPUT and OUTPUT parameters not critical for this algorithm are not INPUT and OUTPUT parameters not critical for this algorithm are not
described in this example) described in this example)
INPUTS INPUTS
CONTEXT HANDLE input_context_handle = context_handle from the CONTEXT HANDLE input_context_handle = context_handle from the
(789.client.example.com.server.example.com., context_handle) (789.client.example.com.server.example.com., context_handle)
entry in the server's mapping table entry in the server's mapping table
OCTET STRING input_token = token specified in the Key OCTET STRING input_token = token specified in the Key
field of TKEY RR (from Additional records Section of field of TKEY RR (from Additional records Section of
the client's query) the client's query)
The OUTPUTS parameters returned by GSS_Accept_sec_context include The OUTPUTS parameters returned by GSS_Accept_sec_context include
INTEGER major_status = GSS_S_COMPLETE INTEGER major_status = GSS_S_COMPLETE
skipping to change at page 19, line 7 skipping to change at page 21, line 27
field of TKEY RR (from Additional records Section of field of TKEY RR (from Additional records Section of
the client's query) the client's query)
The OUTPUTS parameters returned by GSS_Accept_sec_context include The OUTPUTS parameters returned by GSS_Accept_sec_context include
INTEGER major_status = GSS_S_COMPLETE INTEGER major_status = GSS_S_COMPLETE
CONTEXT_HANDLE output_context_handle = context_handle CONTEXT_HANDLE output_context_handle = context_handle
OCTET STRING output_token = NULL OCTET STRING output_token = NULL
Since major_status = GSS_S_COMPLETE, the security context on the Since major_status = GSS_S_COMPLETE, the security context on the
server side is established, but the server still needs to respond to server side is established, but the server still needs to respond to
the client's TKEY query, as described below. The security context the client's TKEY query, as described below. The security context
state is advanced to Context Established. state is advanced to Context Established.
X. Server responds to the TKEY query X. Server responds to the TKEY query
Since the major_status = GSS_S_COMPLETE in the last server's call to Since the major_status = GSS_S_COMPLETE in the last server's call to
GSS_Accept_sec_context and the output_token is NULL, the server GSS_Accept_sec_context and the output_token is NULL, the server
responds to the TKEY query placing in the answer section a TKEY record responds to the TKEY query placing in the answer section a TKEY record
that was sent by the client in the Additional records section of the that was sent by the client in the Additional records section of the
client's latest TKEY query. In addition to this server places a client's latest TKEY query. In addition, this server places a
TSIG record in additional records section of its response. Server TSIG record in additional records section of its response. Server
calls GSS_GetMIC to generate a signature to include it in the TSIG calls GSS_GetMIC to generate a signature to include it in the TSIG
record. The server specifies the following GSS_GetMIC INPUT record. The server specifies the following GSS_GetMIC INPUT
parameters: parameters:
CONTEXT HANDLE context_handle = context_handle from the CONTEXT HANDLE context_handle = context_handle from the
(789.client.example.com.server.example.com., context_handle) (789.client.example.com.server.example.com., context_handle)
entry in the server's mapping table entry in the server's mapping table
OCTET STRING message = outgoing message plus TSIG OCTET STRING message = outgoing message plus TSIG
variables (as described in [RFC2845]) variables (as described in [RFC2845])
The OUTPUTS parameters returned by GSS_GetMIC include The OUTPUTS parameters returned by GSS_GetMIC include
INTEGER major_status = GSS_S_COMPLETE INTEGER major_status = GSS_S_COMPLETE
OCTET STRING per_msg_token OCTET STRING per_msg_token
skipping to change at page 19, line 32 skipping to change at page 22, line 5
entry in the server's mapping table entry in the server's mapping table
OCTET STRING message = outgoing message plus TSIG OCTET STRING message = outgoing message plus TSIG
variables (as described in [RFC2845]) variables (as described in [RFC2845])
The OUTPUTS parameters returned by GSS_GetMIC include The OUTPUTS parameters returned by GSS_GetMIC include
INTEGER major_status = GSS_S_COMPLETE INTEGER major_status = GSS_S_COMPLETE
OCTET STRING per_msg_token OCTET STRING per_msg_token
Signature field in the TSIG record is set to per_msg_token. Signature field in the TSIG record is set to per_msg_token.
XI. Client processes token returned by server XI. Client processes token returned by server
Client receives the TKEY query response from the server. Since the
Client receives the TKEY query response from the server. Since the
major_status was GSS_S_COMPLETE in the last client's call to major_status was GSS_S_COMPLETE in the last client's call to
GSS_Init_sec_context, the client verifies that the server's response GSS_Init_sec_context, the client verifies that the server's response
is signed. To validate the signature client calls GSS_VerifyMIC with is signed. To validate the signature, the client calls
the following parameters: GSS_VerifyMIC with the following parameters:
INPUTS INPUTS
CONTEXT HANDLE context_handle = context_handle for CONTEXT HANDLE context_handle = context_handle for
789.client.example.com.server.example.com. key_name 789.client.example.com.server.example.com. key_name
OCTET STRING message = incoming message plus TSIG OCTET STRING message = incoming message plus TSIG
variables (as described in [RFC2845]) variables (as described in [RFC2845])
OCTET STRING per_msg_token = Signature field from TSIG RR OCTET STRING per_msg_token = Signature field from TSIG RR
included in the server's query response included in the server's query response
Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
signature is validated, security negotiation is complete and the signature is validated, security negotiation is complete and the
security context state is advanced to Context Established. These security context state is advanced to Context Established. These
client and server will use the established security context to sign client and server will use the established security context to sign
and validate the signatures when they exchange packets with each and validate the signatures when they exchange packets with each
other until the context expires. other until the context expires.
7. Security Considerations 7. Security Considerations
This document describes a protocol for DNS security using GSS-API. This document describes a protocol for DNS security using GSS-API.
The security provided by this protocol is only as effective as the The security provided by this protocol is only as effective as the
security provided by the underlying GSS mechanisms. security provided by the underlying GSS mechanisms.
All the security considerations from RFC2845, RFC2930 and RFC 2743 All the security considerations from RFC 2845, RFC 2930 and RFC 2743
apply to the protocol described in this document. apply to the protocol described in this document.
8. IANA Considerations 8. IANA Considerations
The authors request that the IANA reserve the TSIG Algorithm name The IANA has reserved the TSIG Algorithm name gss-tsig for the use in
gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource the Algorithm fields of TKEY and TSIG resource records. This
records. This Algorithm name refers to the algorithm described in this Algorithm name refers to the algorithm described in this document.
document. The requirement to have this name registered with IANA is The requirement to have this name registered with IANA is specified
specified in RFC 2845. in RFC 2845.
9. Conformance 9. Conformance
The GSS API using SPNEGO [RFC2478] provides maximum flexibility to The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
choose the underlying security mechanisms that enables security context choose the underlying security mechanisms that enables security
negotiation. GSS API using SPNEGO [RFC2478] enables client and server to context negotiation. GSS API using SPNEGO [RFC2478] enables client
negotiate and choose such underlying security mechanisms on the fly. To and server to negotiate and choose such underlying security
support such flexibility, DNS clients and servers SHOULD specify SPNEGO mechanisms on the fly. To support such flexibility, DNS clients and
mech_type in their GSS API calls. At the same time, in order to servers SHOULD specify SPNEGO mech_type in their GSS API calls. At
guarantee interoperability between DNS clients and servers that support the same time, in order to guarantee interoperability between DNS
GSS-TSIG it is required that clients and servers that support GSS-TSIG it is required that
- DNS servers specify SPNEGO mech_type
- GSS APIs called by DNS client support Kerberos v5
- GSS APIs called by DNS server support SPNEGO [RFC2478] and
Kerberos v5.
In addition to these, GSS APIs used by DNS client and server MAY also - DNS servers specify SPNEGO mech_type
support other underlying security mechanisms. - GSS APIs called by DNS client support Kerberos v5
- GSS APIs called by DNS server support SPNEGO [RFC2478] and
Kerberos v5.
10. Acknowledgements In addition to these, GSS APIs used by DNS client and server MAY also
support other underlying security mechanisms.
The authors of this document would like to thank the following people 10. Intellectual Property Statement
for their contribution to this specification: Chuck Chan, Mike Swift,
Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake 3rd and Erik
Nordmark.
11. References The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
[RFC2743] J. Linn, "Generic Security Service Application Program The IETF invites any interested party to bring to its attention any
Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories, copyrights, patents or patent applications, or other proprietary
January 2000. rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, 11. Acknowledgements
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, ISC, NAI Labs, Motorola, Nominum, May, 2000,
[RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)", The authors of this document would like to thank the following people
RFC 2930, Motorola, September 2000. for their contribution to this specification: Chuck Chan, Mike
Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd
and Erik Nordmark.
[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions," 12. References
RFC 2535, IBM, March 1999.
[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update," 12.1. Normative References
RFC 2137, CyberCash, April 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
STD 13, RFC 1034, November 1987. Negotiation Mechanism", RFC 2478, December 1998.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC2743] Linn, J., "Generic Security Service Application Program
Specification", STD 13, RFC 1034, November 1987. Interface, Version 2 , Update 1", RFC 2743, January 2000.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
RFC 1964, OpenVision Technologies, June 1996. Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RFC 2025, Bell-Northern Research, October 1996. RR)", RFC 2930, September 2000.
[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API 12.2. Informative References
Negotiation Mechanism", RFC 2478, Bull, December 1998.
[ISO11578]"Information technology", "Open Systems [ISO11578] "Information technology", "Open Systems Interconnection",
Interconnection", "Remote Procedure Call", "Remote Procedure Call", ISO/IEC 11578:1996,
ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html. http://www.iso.ch/cate/d2229.html.
12. Author's Addresses [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
Stuart Kwan Praerit Garg [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Microsoft Corporation Microsoft Corporation Specification", STD 13, RFC 1034, November 1987.
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
skwan@microsoft.com praeritg@microsoft.com
James Gilroy Levon Esibov [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
Microsoft Corporation Microsoft Corporation 1964, June 1996.
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
USA USA (SPKM)", RFC 2025, October 1996.
jamesg@microsoft.com levone@microsoft.com
Randy Hall Jeff Westhead [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
Lucent Technologies Microsoft Corporation Update", RFC 2137, April 1997.
400 Lapp Road One Microsoft Way
Malvern PA 19355 Redmond, WA 98052 [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
USA USA RFC 2535, March 1999.
randyhall@lucent.com jwesth@microsoft.com
13. Authors' Addresses
Stuart Kwan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: skwan@microsoft.com
Praerit Garg
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: praeritg@microsoft.com
James Gilroy
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: jamesg@microsoft.com
Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: levone@microsoft.com
Randy Hall
Lucent Technologies
400 Lapp Road
Malvern PA 19355
USA
EMail: randyhall@lucent.com
Jeff Westhead
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: jwesth@microsoft.com
14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 180 change blocks. 
623 lines changed or deleted 669 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/