INTERNET-DRAFT Stuart Kwan
-<draft-ietf-dnsext-gss-tsig-05.txt> Praerit Garg
-January 30, 2002 James Gilroy
-Expires July 30, 2002 Levon Esibov
+<draft-ietf-dnsext-gss-tsig-06.txt> Praerit Garg
+February 28, 2003 James Gilroy
+Expires August 28, 2003 Levon Esibov
Jeff Westhead
Microsoft Corp.
Randy Hall
The TSIG protocol provides transaction level authentication for DNS.
TSIG is extensible through the definition of new algorithms. This
document specifies an algorithm based on the Generic Security Service
-Application Program Interface (GSS-API) (RFC2743).
+Application Program Interface (GSS-API) (RFC2743). This document updates
+RFC 2845.
+Expires August 28, 2003 [Page 1]
-Expires July 30, 2002 [Page 1]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
+INTERNET-DRAFT GSS-TSIG February 28, 2003
Table of Contents
1: Introduction......................................................2
2: Algorithm Overview................................................3
2.1: GSS Details...................................................4
+ 2.2: Modifications to the TSIG protocol (RFC 2845).................4
3: Client Protocol Details...........................................4
- 3.1: Negotiating Context...........................................4
+ 3.1: Negotiating 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.................................7
3.1.3: Receive TKEY Query-Response from Server...................7
- 3.2: Context Established...........................................9
+ 3.2: Context Established..........................................10
3.2.1: Terminating a Context....................................10
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...........................11
4.1.2: Call GSS_Accept_sec_context..............................11
- 4.1.3: Send TKEY Query-Response to Client.......................11
+ 4.1.3: Send TKEY Query-Response to Client.......................12
4.2: Context Established..........................................13
4.2.1: Terminating a Context....................................13
-5: Sending and Verifying Signed Messages............................13
- 5.1: Sending a Signed Message - Call GSS_GetMIC...................13
- 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............14
-6: Example usage of GSS-TSIG algorithm..............................15
-7: Security Considerations..........................................19
-8: IANA Considerations..............................................19
-9: Conformance......................................................19
+5: Sending and Verifying Signed Messages............................14
+ 5.1: Sending a Signed Message - Call GSS_GetMIC...................14
+ 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............15
+6: Example usage of GSS-TSIG algorithm..............................16
+7: Security Considerations..........................................20
+8: IANA Considerations..............................................20
+9: Conformance......................................................20
10:Acknowledgements.................................................20
11:References.......................................................20
-
1. Introduction
The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
for one transaction, whereas that same server MAY use SPKM [RFC2025]
with a different client.
-Expires July 30, 2002 [Page 2]
+Expires August 28, 2003 [Page 2]
-INTERNET-DRAFT GSS-TSIG January 30, 2002
+INTERNET-DRAFT GSS-TSIG February 28, 2003
* The protocol developer is removed from the responsibility of
creating and managing a security infrastructure. For example, the
| |
+----------+
-Expires July 30, 2002 [Page 3]
+Expires August 28, 2003 [Page 3]
-INTERNET-DRAFT GSS-TSIG January 30, 2002
+INTERNET-DRAFT GSS-TSIG February 28, 2003
Every connection begins in the uninitialized state.
as described in [RFC2845].
+2.2 Modifications to the TSIG protocol (RFC 2845)
+
+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.
+
+Specifically Section 4.2 of RFC 2845 MUST be modified as follows.
+
+Replace:
+"The server MUST not generate a signed response to an unsigned
+request."
+
+With:
+"The server MUST not generate a signed response to an unsigned 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
A unique context is required for each server to which the client sends
(target_name, key_name, context_handle)
+Expires August 28, 2003 [Page 4]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
+
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
server to indicate to each other which context MUST be used to process
token and if necessary, returns a subsequent token to the client. The
client processes this token, and so on, until the negotiation is
complete. The number of times the client and server exchange tokens
-
-Expires July 30, 2002 [Page 4]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
depends on the underlying security mechanism. A completed negotiation
results in a context handle.
more information).
OCTET STRING input_token = NULL
BOOLEAN replay_det_req_flag = TRUE
+
+Expires August 28, 2003 [Page 5]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
BOOLEAN mutual_req_flag = TRUE
BOOLEAN deleg_req_flag = TRUE
BOOLEAN sequence_req_flag = TRUE
BOOLEAN deleg_state
BOOLEAN sequence_state
BOOLEAN anon_state
-
-Expires July 30, 2002 [Page 5]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
BOOLEAN trans_state
BOOLEAN prot_ready_state
BOOLEAN conf_avail
GSS_S_COMPLETE. The exact success code is important during later
processing.
+Expires August 28, 2003 [Page 6]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
+
The values of replay_det_state and mutual_state indicate if the
security package provides replay detection and mutual authentication,
respectively. If returned major_status is GSS_S_COMPLETE AND one or both
will be placed in a Key Data field of the RDATA field in the TKEY
resource record in the additional records section of the query. The
owner name of the TKEY resource record set queried for and the owner
-
-Expires July 30, 2002 [Page 6]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
name of the supplied TKEY resource record in the additional records
section MUST be the same. This name uniquely identifies the security
context to both the client and server, and thus the client SHOULD use
to the description in Section 4. This Section specifies the behavior
of the client after it receives the matching response to its query.
+Expires August 28, 2003 [Page 7]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
The next processing step depends on the value of major_status from the
most recent call that client performed to GSS_Init_sec_context: either
GSS_S_COMPLETE or GSS_S_CONTINUE.
-
3.1.3.1 Value of major_status == GSS_S_COMPLETE
If the last call to GSS_Init_sec_context yielded a major_status value
Confirmation is in the form of a query response with RCODE=NOERROR
and with the last client supplied TKEY record in the answer section
-of the query. The response MUST be signed with a TSIG record. The
-signature in the TSIG record MUST be verified using the procedure
+of the query. The response MUST be signed with a TSIG record. Note
+that server is allowed to sign a response to unsigned client's query
+due to modification to the RFC 2845 specified in Section 2.2 above.
+The signature in the TSIG record MUST be verified using the procedure
detailed in section 5, Sending and Verifying Signed Messages. If the
response is not signed, OR if the response is signed but signature is
invalid, then an attacker has tampered with the message in transit or
has attempted to send the client a false response. In this case the
-
-Expires July 30, 2002 [Page 7]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
-
client MAY continue waiting for a response to its last TKEY query until
the time period since the client sent last TKEY query expires. Such a
time period is specified by the policy local to the client. This is a
CONTEXT HANDLE input_context_handle and OCTET STRING input_token as
described below:
+Expires August 28, 2003 [Page 8]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
+
INPUTS
CONTEXT HANDLE input_context_handle = context_handle (this is the
context_handle corresponding to the key_name which is the
GSS_S_NO_CRED
GSS_S_CREDENTIALS_EXPIRED
GSS_S_BAD_BINDINGS
-
-Expires July 30, 2002 [Page 8]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
GSS_S_OLD_TOKEN
GSS_S_DUPLICATE_TOKEN
GSS_S_NO_CONTEXT
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
finished. The token output_token MUST be passed to the server in a TKEY
record by repeating the negotiation sequence beginning with section
+
+Expires August 28, 2003 [Page 9]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
+
3.1.2. The client MUST place a limit on the number of continuations in
a context negotiation to prevent endless looping. Such limit SHOULD NOT
exceed value of 10.
The procedures for sending and receiving signed messages are described
in section 5, Sending and Verifying Signed Messages.
-Expires July 30, 2002 [Page 9]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
3.2.1 Terminating a Context
A server MUST recognize TKEY queries as security context negotiation
messages.
+Expires August 28, 2003 [Page 10]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
4.1.1 Receive TKEY Query from Client
and 4.1.3.
-Expires July 30, 2002 [Page 10]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
4.1.2 Call GSS_Accept_sec_context
INTERNAL NAME src_name
OBJECT IDENTIFIER mech_type
BOOLEAN deleg_state
+
+Expires August 28, 2003 [Page 11]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
+
BOOLEAN mutual_state
BOOLEAN replay_det_state
BOOLEAN sequence_state
The server MUST respond to the client with a TKEY query response with
RCODE = NOERROR, that contains a TKEY record in the answer section.
-
-
-Expires July 30, 2002 [Page 11]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
If OUTPUT major_status is one of the following errors the error field
in the TKEY record set to BADKEY.
returned to the client in a Key Data field of the RDATA in TKEY. The
error field in the TKEY record is set to NOERROR. The message MUST be
signed with a TSIG record as described in section 5, Sending and
-Verifying Signed Messages. The context state is advanced to Context
-Established. Section 4.2 discusses the usage of the security context.
+Verifying Signed Messages. Note that server is allowed to sign a
+response to unsigned client's query due to modification to the RFC
+2845 specified in Section 2.2 above. The context state is advanced to
+Context Established. Section 4.2 discusses the usage of the security
+context.
+
+
+
+Expires August 28, 2003 [Page 12]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
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
section of the response. The message MUST be signed with a TSIG record
-as described in section 5, Sending and Verifying Signed Messages. The
+as described in section 5, Sending and Verifying Signed Messages. Note
+that server is allowed to sign a response to unsigned client's query
+due to modification to the RFC 2845 specified in section 2.2 above. The
context state is advanced to Context Established. Section 4.2 discusses
the usage of the security context.
-Expires July 30, 2002 [Page 12]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
-
-
4.2 Context Established
When context negotiation is complete, the handle context_handle
An active context is deleted by calling GSS_Delete_sec_context
providing the associated context_handle.
+Expires August 28, 2003 [Page 13]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
5. Sending and Verifying Signed Messages
output values specified below. Consult Sections 2.3.1 "GSS_GetMIC
call" of the RFC 2743[RFC2743] for syntax definitions.
-
-
-
-
-Expires July 30, 2002 [Page 13]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name
OCTET STRING message = outgoing message plus TSIG
GSS_GetMIC call with allowed QOP value. The number of such repetitions
MUST be limited to prevent infinite loops.
+Expires August 28, 2003 [Page 14]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
5.2 Verifying a Signed Message - Call GSS_VerifyMIC
INTEGER minor_status
INTEGER qop_state
-Expires July 30, 2002 [Page 14]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
If major_status is GSS_S_COMPLETE, the signature is authentic and the
message was delivered intact. Per [RFC2845], the timer values of the
TSIG record MUST also be valid before considering the message to be
sent to the client according to [RFC2845].
+
+
+
+
+Expires August 28, 2003 [Page 15]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
+
6. Example usage of GSS-TSIG algorithm
This Section describes an example where a Client, client.example.com,
BOOLEAN replay_det_state = TRUE
BOOLEAN mutual_state = TRUE
-
-
-Expires July 30, 2002 [Page 15]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
Client verifies that replay_det_state and mutual_state values are
TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
success OUTPUT major_status value, client stores context_handle that
context_handle) mapping table.
+
+
+
+Expires August 28, 2003 [Page 16]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
III. Server receives a query with QTYPE = TKEY
When server receives a query with QTYPE = TKEY, the server verifies
that Mode and Algorithm fields in the TKEY record in the Additional
in its (key_name, context_handle) mapping table.
-
-Expires July 30, 2002 [Page 16]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
V. Server responds to the TKEY query
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
The OUTPUTS parameters returned by GSS_Init_sec_context include
INTEGER major_status = GSS_S_COMPLETE
+
+Expires August 28, 2003 [Page 17]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
+
CONTEXT HANDLE output_context_handle = context_handle
OCTET STRING output_token = output_token
BOOLEAN replay_det_state = TRUE
Key Data = output_token
-
-
-
-
-
-Expires July 30, 2002 [Page 17]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
VIII. Server receives a TKEY query
When the server receives a TKEY query, the server verifies that Mode
and Algorithm fields in the TKEY record in the Additional records
CONTEXT_HANDLE output_context_handle = context_handle
OCTET STRING output_token = NULL
+
+
+
+Expires August 28, 2003 [Page 18]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
+
Since major_status = GSS_S_COMPLETE, the security context on the
server side is established, but the server still needs to respond to
the client's TKEY query, as described below. The security context
Signature field in the TSIG record is set to per_msg_token.
-Expires July 30, 2002 [Page 18]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
XI. Client processes token returned by server
Client receives the TKEY query response from the server. Since the
other until the context expires.
+
+Expires August 28, 2003 [Page 19]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
7. Security Considerations
This document describes a protocol for DNS security using GSS-API.
mech_type in their GSS API calls. At the same time, in order to
guarantee interoperability between DNS clients and servers that support
GSS-TSIG it is required that
-
-Expires July 30, 2002 [Page 19]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
- 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
Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories,
January 2000.
+
+
+Expires August 28, 2003 [Page 20]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, ISC, NAI Labs, Motorola, Nominum, May, 2000,
[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, Bull, December 1998.
-Expires July 30, 2002 [Page 20]
-
-INTERNET-DRAFT GSS-TSIG January 30, 2002
-
-
[ISO11578]"Information technology", "Open Systems
Interconnection", "Remote Procedure Call",
ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html.
-
-
12. Author's Addresses
Stuart Kwan Praerit Garg
jamesg@microsoft.com levone@microsoft.com
+
+Expires August 28, 2003 [Page 21]
+
+INTERNET-DRAFT GSS-TSIG February 28, 2003
+
+
Randy Hall Jeff Westhead
Lucent Technologies Microsoft Corporation
400 Lapp Road One Microsoft Way
-Expires July 30, 2002 [Page 21]
+Expires August 28, 2003 [Page 22]
Internet Engineering Task Force S. Thomson, Cisco
INTERNET-DRAFT C. Huitema, Microsoft
-October 29, 2002 V. Ksinant, 6WIND
-Expires April 29, 2003 M. Souissi, AFNIC
+February 28, 2003 V. Ksinant, 6WIND
+Expires August 28, 2003 M. Souissi, AFNIC
DNS Extensions to support IP version 6
- <draft-ietf-dnsext-rfc1886bis-01.txt>
+ <draft-ietf-dnsext-rfc1886bis-02.txt>
Status of this Memo
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
- This Internet Draft expires April 29, 2003.
+ This Internet Draft expires August 28, 2003.
-
-draft-ietf-dnsext-rfc1886bis-01.txt [Page 1]
+draft-ietf-dnsext-rfc1886bis-02.txt [Page 1]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
Table of Contents
that has more than one IPv6 address must have more than one such
record.
-draft-ietf-dnsext-rfc1886bis-01.txt [Page 2]
+draft-ietf-dnsext-rfc1886bis-02.txt [Page 2]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
2.1 AAAA record type
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
ARPA.
-draft-ietf-dnsext-rfc1886bis-01.txt [Page 3]
+draft-ietf-dnsext-rfc1886bis-02.txt [Page 3]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
3. MODIFICATIONS TO EXISTING QUERY TYPES
All existing query types that perform type A additional section
- processing, i.e. name server (NS) and mail exchange (MX) query
- types, must be redefined to perform both type A and type AAAA
- additional section processing. These definitions mean that a name
- server must add any relevant IPv4 addresses and any relevant IPv6
- addresses available locally to the additional section of a response
- when processing any one of the above queries.
-
+ processing, i.e. name server (NS), location of services (SRV) and
+ mail exchange (MX) query types, must be redefined to perform both
+ type A and type AAAA additional section processing. These definitions
+ mean that a name server must add any relevant IPv4 addresses and any
+ relevant IPv6 addresses available locally to the additional section
+ of a response when processing any one of the above queries.
+
4. SECURITY CONSIDERATIONS
support IP version 6":
- Replaced the "IP6.INT" domain by "IP6.ARPA".
+ - Mentioned SRV query types in section 3 "MODIFICATIONS TO
+ EXISTING QUERY TYPES"
- Added security considerations.
- Updated references :
* From RFC 1884 to RFC 2373 (IP Version 6 Addressing
-
-
-
-
-
-draft-ietf-dnsext-rfc1886bis-01.txt [Page 4]
+draft-ietf-dnsext-rfc1886bis-02.txt [Page 4]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
Acknowledgements
Many thanks to Alain Durand and Olafur Gudmundsson for their support.
+
+
Normative References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
"draft-ietf-ipngwg-addr-arch-v3-11.txt", Hinden, R., and
S. Deering, October 25, 2002
+
+
+Informative References
+
[4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems
Inc., August 2000.
This RFC is being updated. The current draft is
- "draft-ietf-ngtrans-mech-v2-00.txt", Gilligan, R., and
- E. Nordmark, July 17, 2002
+ "draft-ietf-v6ops-mech-v2-00.txt", Gilligan, R., and
+ E. Nordmark, February 24, 2003
[5] Thomson, S., and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, Bellcore, INRIA, December 1995.
RFC 2845, ISC, NAI Labs, Motorola, Nominum, May 2000.
-
-
-
-
-
-
-draft-ietf-dnsext-rfc1886bis-01.txt [Page 5]
+draft-ietf-dnsext-rfc1886bis-02.txt [Page 5]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
Authors' Addresses
-draft-ietf-dnsext-rfc1886bis-01.txt [Page 6]
+draft-ietf-dnsext-rfc1886bis-02.txt [Page 6]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
Full Copyright Statement
information to the IETF Executive Director.
-draft-ietf-dnsext-rfc1886bis-01.txt [Page 7]
+draft-ietf-dnsext-rfc1886bis-02.txt [Page 7]
projects / thirdparty / bind9.git / commitdiff
