mirror of
https://github.com/isc-projects/bind9.git
synced 2026-06-11 14:19:59 -04:00
new draft
This commit is contained in:
Mark Andrews
parent
4cb69e7c91
commit
eab1b7cb5a
2 changed files with 194 additions and 163 deletions
|
|
@ -1,8 +1,8 @@
|
|||
|
||||
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
|
||||
|
|
@ -41,7 +41,8 @@ Abstract
|
|||
The TSIG protocol provides transaction level authentication for DNS.
|
||||
TSIG is extensible through the definition of new algorithms. This
|
||||
document specifies an algorithm based on the Generic Security Service
|
||||
Application Program Interface (GSS-API) (RFC2743).
|
||||
Application Program Interface (GSS-API) (RFC2743). This document updates
|
||||
RFC 2845.
|
||||
|
||||
|
||||
|
||||
|
|
@ -53,41 +54,40 @@ Application Program Interface (GSS-API) (RFC2743).
|
|||
|
||||
|
||||
|
||||
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]
|
||||
|
|
@ -112,9 +112,9 @@ 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.
|
||||
|
||||
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
|
||||
|
|
@ -170,9 +170,9 @@ states of a context associated with a connection:
|
|||
| |
|
||||
+----------+
|
||||
|
||||
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.
|
||||
|
|
@ -198,6 +198,28 @@ records exchanged in DNS messages sent between the Client and Server,
|
|||
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
|
||||
|
|
@ -206,6 +228,11 @@ client maintains a mapping of servers to handles,
|
|||
|
||||
(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
|
||||
|
|
@ -227,11 +254,6 @@ initial token and sends it to the server. The server processes the
|
|||
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.
|
||||
|
||||
|
|
@ -263,6 +285,11 @@ indicated with the output values below. Consult Sections 2.2.1
|
|||
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
|
||||
|
|
@ -285,11 +312,6 @@ indicated with the output values below. Consult Sections 2.2.1
|
|||
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
|
||||
|
|
@ -322,6 +344,11 @@ Success values of major_status are GSS_S_CONTINUE_NEEDED and
|
|||
GSS_S_COMPLETE. The exact success code is important during later
|
||||
processing.
|
||||
|
||||
Expires August 28, 2003 [Page 6]
|
||||
|
||||
INTERNET-DRAFT GSS-TSIG February 28, 2003
|
||||
|
||||
|
||||
The values of replay_det_state and mutual_state indicate if the
|
||||
security package provides replay detection and mutual authentication,
|
||||
respectively. If returned major_status is GSS_S_COMPLETE AND one or both
|
||||
|
|
@ -343,11 +370,6 @@ to the server in a query request with QTYPE=TKEY. The token itself
|
|||
will be placed in a Key Data field of the RDATA field in the TKEY
|
||||
resource record in the additional records section of the query. The
|
||||
owner name of the TKEY resource record set queried for and the owner
|
||||
|
||||
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
|
||||
|
|
@ -380,12 +402,15 @@ Upon the reception of the TKEY query DNS server MUST respond according
|
|||
to the description in Section 4. This Section specifies the behavior
|
||||
of the client after it receives the matching response to its query.
|
||||
|
||||
Expires August 28, 2003 [Page 7]
|
||||
|
||||
INTERNET-DRAFT GSS-TSIG February 28, 2003
|
||||
|
||||
The next processing step depends on the value of major_status from the
|
||||
most recent call that client performed to GSS_Init_sec_context: either
|
||||
GSS_S_COMPLETE or GSS_S_CONTINUE.
|
||||
|
||||
|
||||
|
||||
3.1.3.1 Value of major_status == GSS_S_COMPLETE
|
||||
|
||||
If the last call to GSS_Init_sec_context yielded a major_status value
|
||||
|
|
@ -395,18 +420,14 @@ client is awaiting confirmation from the server.
|
|||
|
||||
Confirmation is in the form of a query response with RCODE=NOERROR
|
||||
and with the last client supplied TKEY record in the answer section
|
||||
of the query. The response MUST be signed with a TSIG record. 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
|
||||
|
|
@ -439,6 +460,11 @@ using the same parameters values as in previous call except values for
|
|||
CONTEXT HANDLE input_context_handle and OCTET STRING input_token as
|
||||
described below:
|
||||
|
||||
Expires August 28, 2003 [Page 8]
|
||||
|
||||
INTERNET-DRAFT GSS-TSIG February 28, 2003
|
||||
|
||||
|
||||
INPUTS
|
||||
CONTEXT HANDLE input_context_handle = context_handle (this is the
|
||||
context_handle corresponding to the key_name which is the
|
||||
|
|
@ -459,11 +485,6 @@ If OUTPUT major_status is set to one of the following values
|
|||
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
|
||||
|
|
@ -496,6 +517,12 @@ MUST be limited to ten or less.
|
|||
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
|
||||
finished. The token output_token MUST be passed to the server in a TKEY
|
||||
record by repeating the negotiation sequence beginning with section
|
||||
|
||||
Expires August 28, 2003 [Page 9]
|
||||
|
||||
INTERNET-DRAFT GSS-TSIG February 28, 2003
|
||||
|
||||
|
||||
3.1.2. The client MUST place a limit on the number of continuations in
|
||||
a context negotiation to prevent endless looping. Such limit SHOULD NOT
|
||||
exceed value of 10.
|
||||
|
|
@ -518,10 +545,6 @@ used for the generation and verification of transaction signatures.
|
|||
The procedures for sending and receiving signed messages are described
|
||||
in section 5, Sending and Verifying Signed Messages.
|
||||
|
||||
Expires July 30, 2002 [Page 9]
|
||||
|
||||
INTERNET-DRAFT GSS-TSIG January 30, 2002
|
||||
|
||||
|
||||
3.2.1 Terminating a Context
|
||||
|
||||
|
|
@ -553,6 +576,10 @@ request. The server maintains a mapping of key names to handles:
|
|||
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
|
||||
|
||||
|
|
@ -576,10 +603,6 @@ context negotiation and performs operations described in Section 4.1.2
|
|||
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
|
||||
|
||||
|
|
@ -610,6 +633,12 @@ for syntax definitions.
|
|||
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
|
||||
|
|
@ -632,12 +661,6 @@ TKEY record.
|
|||
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.
|
||||
|
||||
|
|
@ -661,13 +684,24 @@ negotiation is finished. If output_token is non-NULL, then it MUST be
|
|||
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.
|
||||
|
||||
|
|
@ -692,12 +726,6 @@ Error, Other Size and Data Fields, MUST be set according to [RFC2930].
|
|||
|
||||
|
||||
|
||||
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
|
||||
|
|
@ -722,6 +750,9 @@ including a TKEY RR in a response with the Mode field set to 5, i.e.
|
|||
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
|
||||
|
||||
|
|
@ -746,14 +777,6 @@ 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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
|
@ -785,6 +808,10 @@ 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
|
||||
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
|
||||
|
||||
|
|
@ -808,10 +835,6 @@ For the GSS algorithm, a signature is verified by using 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
|
||||
|
|
@ -839,6 +862,15 @@ is processing a client request, the appropriate error response MUST 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,
|
||||
|
|
@ -864,12 +896,6 @@ to the algorithm described above.
|
|||
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
|
||||
|
|
@ -895,6 +921,13 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002
|
|||
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
|
||||
|
|
@ -923,11 +956,6 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002
|
|||
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
|
||||
|
|
@ -953,6 +981,12 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002
|
|||
|
||||
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
|
||||
|
|
@ -977,15 +1011,6 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002
|
|||
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
|
||||
|
|
@ -1012,6 +1037,14 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002
|
|||
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
|
||||
|
|
@ -1040,10 +1073,6 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002
|
|||
|
||||
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
|
||||
|
|
@ -1068,6 +1097,11 @@ INTERNET-DRAFT GSS-TSIG January 30, 2002
|
|||
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.
|
||||
|
|
@ -1097,11 +1131,6 @@ support such flexibility, DNS clients and servers SHOULD specify SPNEGO
|
|||
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
|
||||
|
|
@ -1125,6 +1154,12 @@ Nordmark.
|
|||
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,
|
||||
|
|
@ -1156,18 +1191,11 @@ Nordmark.
|
|||
[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
|
||||
|
|
@ -1185,6 +1213,12 @@ USA USA
|
|||
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
|
||||
|
|
@ -1194,4 +1228,4 @@ randyhall@lucent.com jwesth@microsoft.com
|
|||
|
||||
|
||||
|
||||
Expires July 30, 2002 [Page 21]
|
||||
Expires August 28, 2003 [Page 22]
|
||||
|
|
@ -1,14 +1,14 @@
|
|||
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
|
||||
|
|
@ -21,6 +21,7 @@ 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
|
||||
|
|
@ -29,7 +30,7 @@ Status of this Memo
|
|||
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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -53,10 +54,9 @@ Abstract
|
|||
|
||||
|
||||
|
||||
|
||||
draft-ietf-dnsext-rfc1886bis-01.txt [Page 1]
|
||||
draft-ietf-dnsext-rfc1886bis-02.txt [Page 1]
|
||||
|
||||
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
|
||||
|
|
@ -109,9 +109,9 @@ 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]
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -165,20 +165,20 @@ INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
|
|||
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]
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -200,6 +200,8 @@ APPENDIX A: Changes from RFC 1886
|
|||
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
|
||||
|
|
@ -217,14 +219,9 @@ APPENDIX A: Changes from RFC 1886
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
draft-ietf-dnsext-rfc1886bis-01.txt [Page 4]
|
||||
draft-ietf-dnsext-rfc1886bis-02.txt [Page 4]
|
||||
|
||||
INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
|
||||
INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
|
||||
|
||||
Acknowledgements
|
||||
|
||||
|
|
@ -236,6 +233,8 @@ Acknowledgements
|
|||
|
||||
Many thanks to Alain Durand and Olafur Gudmundsson for their support.
|
||||
|
||||
|
||||
|
||||
Normative References
|
||||
|
||||
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
|
||||
|
|
@ -251,12 +250,16 @@ Normative References
|
|||
"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.
|
||||
|
|
@ -272,15 +275,9 @@ Normative References
|
|||
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]
|
||||
|
||||
INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
|
||||
INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
|
@ -332,9 +329,9 @@ Authors' Addresses
|
|||
|
||||
|
||||
|
||||
draft-ietf-dnsext-rfc1886bis-01.txt [Page 6]
|
||||
draft-ietf-dnsext-rfc1886bis-02.txt [Page 6]
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -390,4 +387,4 @@ 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]
|
||||
Loading…
Reference in a new issue