draft-ietf-dnsext-tkey-03.txt   rfc2930.txt 
DNSEXT Working Group Donald E. Eastlake, 3rd Network Working Group D. Eastlake, 3rd
INTERNET-DRAFT Motorola Request for Comments: 2930 Motorola
Expires: December 2000 June 2000 Category: Standards Track September 2000
Secret Key Establishment for DNS (TKEY RR) Secret Key Establishment for DNS (TKEY RR)
------ --- ------------- --- --- ----- ---
<draft-ietf-dnsext-tkey-03.txt>
Status of This Document
This draft is intended to be become a Proposed Standard RFC. Status of this Memo
Distribution of this document is unlimited. Comments should be sent
to the DNS working group mailing list <namedroppers@ops.ietf.org> or
to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet- Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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 (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
[draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating [RFC 2845] provides a means of authenticating Domain Name System
Domain Name System (DNS) queries and responses using shared secret (DNS) queries and responses using shared secret keys via the
keys via the TSIG resource record (RR). However, it provides no Transaction Signature (TSIG) resource record (RR). However, it
mechanism for setting up such keys other than manual exchange. This provides no mechanism for setting up such keys other than manual
document describes a TKEY RR that can be used in a number of exchange. This document describes a Transaction Key (TKEY) RR that
different modes to establish shared secret keys between a DNS can be used in a number of different modes to establish shared secret
resolver and server. keys between a DNS resolver and server.
Acknowledgments Acknowledgments
The comments and ideas of the following persons (listed in alphabetic The comments and ideas of the following persons (listed in alphabetic
order) have been incorporated herein and are gratefully acknowledged: order) have been incorporated herein and are gratefully acknowledged:
Olafur Gudmundsson (TIS) Olafur Gudmundsson (TIS)
Stuart Kwan (Microsoft) Stuart Kwan (Microsoft)
Ed Lewis (TIS) Ed Lewis (TIS)
Erik Nordmark (SUN) Erik Nordmark (SUN)
Brian Wellington (Nominum) Brian Wellington (Nominum)
Table of Contents Table of Contents
Status of This Document....................................1 1. Introduction............................................... 2
1.1 Overview of Contents...................................... 3
Abstract...................................................2 2. The TKEY Resource Record................................... 4
Acknowledgments............................................2 2.1 The Name Field............................................ 4
2.2 The TTL Field............................................. 5
Table of Contents..........................................3 2.3 The Algorithm Field....................................... 5
2.4 The Inception and Expiration Fields....................... 5
1. Introduction............................................4 2.5 The Mode Field............................................ 5
1.1 Overview of Contents...................................4 2.6 The Error Field........................................... 6
2. The TKEY Resource Record................................5 2.7 The Key Size and Data Fields.............................. 6
2.1 The Name Field.........................................5 2.8 The Other Size and Data Fields............................ 6
2.2 The TTL Field..........................................6 3. General TKEY Considerations................................ 7
2.3 The Algorithm Field....................................6 4. Exchange via Resolver Query................................ 8
2.4 The Inception and Expiration Fields....................6 4.1 Query for Diffie-Hellman Exchanged Keying................. 8
2.5 The Mode Field.........................................7 4.2 Query for TKEY Deletion................................... 9
2.6 The Error Field........................................7 4.3 Query for GSS-API Establishment........................... 10
2.7 The Key Size and Data Fields...........................8 4.4 Query for Server Assigned Keying.......................... 10
2.8 The Other Size and Data Fields.........................8 4.5 Query for Resolver Assigned Keying........................ 11
3. General TKEY Considerations.............................8 5. Spontaneous Server Inclusion............................... 12
4. Exchange via Resolver Query.............................9 5.1 Spontaneous Server Key Deletion........................... 12
4.1 Query for Diffie-Hellman Exchanged Keying..............9 6. Methods of Encryption...................................... 12
4.2 Query for TKEY Deletion...............................10 7. IANA Considerations........................................ 13
4.3 Query for GSS-API Establishment.......................11 8. Security Considerations.................................... 13
4.4 Query for Server Assigned Keying......................11 References.................................................... 14
4.5 Query for Resolver Assigned Keying....................12 Author's Address.............................................. 15
5. Spontaneous Server Inclusion...........................13 Full Copyright Statement...................................... 16
5.1 Spontaneous Server Key Deletion.......................13
6. Methods of Encryption..................................14
7. IANA Considerations....................................14
8. Security Considerations................................15
References................................................16
Author's Address..........................................17
Expiration and File Name..................................17
1. Introduction 1. Introduction
The Domain Name System (DNS) is a hierarchical, distributed, highly The Domain Name System (DNS) is a hierarchical, distributed, highly
available database used for bi-directional mapping between domain available database used for bi-directional mapping between domain
names and addresses, for email routing, and for other information names and addresses, for email routing, and for other information
[RFC 1034, 1035]. It has been extended to provide for public key [RFC 1034, 1035]. It has been extended to provide for public key
security and dynamic update [RFC 2535, RFC 2136]. Familiarity with security and dynamic update [RFC 2535, RFC 2136]. Familiarity with
these RFCs is assumed. these RFCs is assumed.
[draft-ietf-dnsext-tsig-*.txt] provides a means of efficiently [RFC 2845] provides a means of efficiently authenticating DNS
authenticating DNS messages using shared secret keys via the TSIG messages using shared secret keys via the TSIG resource record (RR)
resource record (RR) but provides no mechanism for setting up such but provides no mechanism for setting up such keys other than manual
keys other than manual exchange. This document specifies a TKEY RR exchange. This document specifies a TKEY RR that can be used in a
that can be used in a number of different modes to establish and number of different modes to establish and delete such shared secret
delete such shared secret keys between a DNS resolver and server. keys between a DNS resolver and server.
Note that TKEY established keying material and TSIGs that use it are Note that TKEY established keying material and TSIGs that use it are
associated with DNS servers or resolvers. They are not associated associated with DNS servers or resolvers. They are not associated
with zones. They may be used to authenticate queries and responses with zones. They may be used to authenticate queries and responses
but they do not provide zone based DNS data origin or denial but they do not provide zone based DNS data origin or denial
authentication [RFC 2535]. authentication [RFC 2535].
Certain modes of TKEY perform encryption which may affect their Certain modes of TKEY perform encryption which may affect their
export or import status for some countries. The affected modes export or import status for some countries. The affected modes
specified in this document are the server assigned mode and the specified in this document are the server assigned mode and the
skipping to change at page 5, line 20 skipping to change at page 4, line 10
Section 7 covers IANA considerations in assignment of TKEY modes. Section 7 covers IANA considerations in assignment of TKEY modes.
Finally, Section 8 provides the required security considerations Finally, Section 8 provides the required security considerations
section. section.
2. The TKEY Resource Record 2. The TKEY Resource Record
The TKEY resource record (RR) has the structure given below. Its RR The TKEY resource record (RR) has the structure given below. Its RR
type code is 249. type code is 249.
Field Type Comment Field Type Comment
----- ---- ------- ----- ---- -------
NAME domain see description below NAME domain see description below
TTYPE u_int16_t TKEY = 249 TTYPE u_int16_t TKEY = 249
CLASS u_int16_t ignored, SHOULD be 255 (ANY) CLASS u_int16_t ignored, SHOULD be 255 (ANY)
TTL u_int32_t ignored, SHOULD be zero TTL u_int32_t ignored, SHOULD be zero
RDLEN u_int16_t size of RDATA RDLEN u_int16_t size of RDATA
RDATA: RDATA:
Algorithm: domain Algorithm: domain
Inception: u_int32_t Inception: u_int32_t
Expiration: u_int32_t Expiration: u_int32_t
Mode: u_int16_t Mode: u_int16_t
Error: u_int16_t Error: u_int16_t
Key Size: u_int16_t Key Size: u_int16_t
Key Data: octet-stream Key Data: octet-stream
Other Size: u_int16_t Other Size: u_int16_t
Other Data: octet-stream undefined by this specification Other Data: octet-stream undefined by this specification
2.1 The Name Field 2.1 The Name Field
The Name field relates to naming keys. Its meaning differs somewhat The Name field relates to naming keys. Its meaning differs somewhat
with mode and context as explained in subsequent sections. with mode and context as explained in subsequent sections.
At any DNS server or resolver only one octet string of keying At any DNS server or resolver only one octet string of keying
material may be in place for any particular key name. An attempt to material may be in place for any particular key name. An attempt to
establish another set of keying material at a server for an existing establish another set of keying material at a server for an existing
name returns a BADNAME error. name returns a BADNAME error.
For a TKEY with a non-root name appearing in a query, the TKEY RR For a TKEY with a non-root name appearing in a query, the TKEY RR
name SHOULD be a domain locally unique at the resolver, less than 128 name SHOULD be a domain locally unique at the resolver, less than 128
octets long in wire encoding, and meaningful to the resolver to octets long in wire encoding, and meaningful to the resolver to
assist in distinguishing keys and/or key agreement sessions. For assist in distinguishing keys and/or key agreement sessions. For
TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
be a globally unique server assigned domain. be a globally unique server assigned domain.
A reasonable key naming strategy is as follows: A reasonable key naming strategy is as follows:
If the key is generated as the result of a query with root as If the key is generated as the result of a query with root as its
its owner name, then the server SHOULD create a globally unique owner name, then the server SHOULD create a globally unique domain
domain name, to be the key name, by suffixing a pseudo-random name, to be the key name, by suffixing a pseudo-random [RFC 1750]
[RFC 1750] label with a domain name of the server. For example label with a domain name of the server. For example
89n3mDgX072pp.server1.example.com. If generation of a new 89n3mDgX072pp.server1.example.com. If generation of a new
pseudo-random name in each case is an excessive computation load pseudo-random name in each case is an excessive computation load
or entropy drain, a serial number prefix can be added to a fixed or entropy drain, a serial number prefix can be added to a fixed
pseudo-random name generated an DNS server start time, such as pseudo-random name generated an DNS server start time, such as
1001.89n3mDgX072pp.server1.example.com. 1001.89n3mDgX072pp.server1.example.com.
If the key is generated as the result of a query with a non-root If the key is generated as the result of a query with a non-root
name, say 789.resolver.example.net, then use the concatenation name, say 789.resolver.example.net, then use the concatenation of
of that with a name of the server. For example that with a name of the server. For example
789.resolver.example.net.server1.example.com. 789.resolver.example.net.server1.example.com.
2.2 The TTL Field 2.2 The TTL Field
The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
be sure that older DNS implementations do not cache TKEY RRs. be sure that older DNS implementations do not cache TKEY RRs.
2.3 The Algorithm Field 2.3 The Algorithm Field
The algorithm name is in the form of a domain name with the same The algorithm name is in the form of a domain name with the same
meaning as in [draft-ietf-dnsext-tsig-*.txt]. The algorithm meaning as in [RFC 2845]. The algorithm determines how the secret
determines how the secret keying material agreed to using the TKEY RR keying material agreed to using the TKEY RR is actually used to
is actually used to derive the algorithm specific key. derive the algorithm specific key.
2.4 The Inception and Expiration Fields 2.4 The Inception and Expiration Fields
The inception time and expiration times are in number of seconds The inception time and expiration times are in number of seconds
since the beginning of 1 January 1970 GMT ignoring leap seconds since the beginning of 1 January 1970 GMT ignoring leap seconds
treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
between a DNS resolver and a DNS server where these fields are between a DNS resolver and a DNS server where these fields are
meaningful, they are either the requested validity interval for the meaningful, they are either the requested validity interval for the
keying material asked for or specify the validity interval of keying keying material asked for or specify the validity interval of keying
material provided. material provided.
skipping to change at page 7, line 21 skipping to change at page 6, line 5
2.5 The Mode Field 2.5 The Mode Field
The mode field specifies the general scheme for key agreement or the The mode field specifies the general scheme for key agreement or the
purpose of the TKEY DNS message. Servers and resolvers supporting purpose of the TKEY DNS message. Servers and resolvers supporting
this specification MUST implement the Diffie-Hellman key agreement this specification MUST implement the Diffie-Hellman key agreement
mode and the key deletion mode for queries. All other modes are mode and the key deletion mode for queries. All other modes are
OPTIONAL. A server supporting TKEY that receives a TKEY request with OPTIONAL. A server supporting TKEY that receives a TKEY request with
a mode it does not support returns the BADMODE error. The following a mode it does not support returns the BADMODE error. The following
values of the Mode octet are defined, available, or reserved: values of the Mode octet are defined, available, or reserved:
Value Description Value Description
----- ----------- ----- -----------
0 - reserved, see section 7 0 - reserved, see section 7
1 server assignment 1 server assignment
2 Diffie-Hellman exchange 2 Diffie-Hellman exchange
3 GSS-API negotiation 3 GSS-API negotiation
4 resolver assignment 4 resolver assignment
5 key deletion 5 key deletion
6-65534 - available, see section 7 6-65534 - available, see section 7
65535 - reserved, see section 7 65535 - reserved, see section 7
2.6 The Error Field 2.6 The Error Field
The error code field is an extended RCODE. The following values are The error code field is an extended RCODE. The following values are
defined: defined:
Value Description Value Description
----- ----------- ----- -----------
0 - no error 0 - no error
1-15 a non-extended RCODE 1-15 a non-extended RCODE
16 BADSIG (tsig) 16 BADSIG (TSIG)
17 BADKEY (tsig) 17 BADKEY (TSIG)
18 BADTIME (tsig) 18 BADTIME (TSIG)
19 BADMODE 19 BADMODE
20 BADNAME 20 BADNAME
21 BADALG 21 BADALG
When the TKEY Error Field is non-zero in a response to a TKEY query, When the TKEY Error Field is non-zero in a response to a TKEY query,
the DNS header RCODE field indicates no error. However, it is the DNS header RCODE field indicates no error. However, it is
possible if a TKEY is spontaneously included in a response the TKEY possible if a TKEY is spontaneously included in a response the TKEY
RR and DNS header error field could have unrelated non-zero error RR and DNS header error field could have unrelated non-zero error
codes. codes.
2.7 The Key Size and Data Fields 2.7 The Key Size and Data Fields
The key data size field is an unsigned 16 bit integer in network The key data size field is an unsigned 16 bit integer in network
skipping to change at page 8, line 45 skipping to change at page 7, line 30
algorithm is algorithm dependent and is defined in connection with algorithm is algorithm dependent and is defined in connection with
that algorithm. For example, see [RFC 2104] for how TKEY agreed that algorithm. For example, see [RFC 2104] for how TKEY agreed
shared secret keying material is used in the HMAC-MD5 algorithm or shared secret keying material is used in the HMAC-MD5 algorithm or
other HMAC algorithms. other HMAC algorithms.
There MUST NOT be more than one TKEY RR in a DNS query or response. There MUST NOT be more than one TKEY RR in a DNS query or response.
Except for GSS-API mode, TKEY responses MUST always have DNS Except for GSS-API mode, TKEY responses MUST always have DNS
transaction authentication to protect the integrity of any keying transaction authentication to protect the integrity of any keying
data, error codes, etc. This authentication MUST use a previously data, error codes, etc. This authentication MUST use a previously
established secret (TSIG) or public (SIG(0)) key and MUST NOT use any established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
key that the response to be verified is itself providing. NOT use any key that the response to be verified is itself providing.
TKEY queries MUST be authenticated for all modes except GSS-API and, TKEY queries MUST be authenticated for all modes except GSS-API and,
under some circumstances, server assignment mode. In particular, if under some circumstances, server assignment mode. In particular, if
the query for a server assigned key is for a key to assert some the query for a server assigned key is for a key to assert some
privilege, such as update authority, then the query must be privilege, such as update authority, then the query must be
authenticated to avoid spoofing. However, if the key is just to be authenticated to avoid spoofing. However, if the key is just to be
used for transaction security, then spoofing will lead at worst to used for transaction security, then spoofing will lead at worst to
denial of service. Query authentication SHOULD use an established denial of service. Query authentication SHOULD use an established
secret (TSIG) key authenticator if available. Otherwise, it must use secret (TSIG) key authenticator if available. Otherwise, it must use
a public (SIG(0)) key signature. It MUST NOT use any key that the a public (SIG(0)) key signature. It MUST NOT use any key that the
skipping to change at page 9, line 42 skipping to change at page 8, line 22
resolver which are syntactically DNS queries for type TKEY. Such resolver which are syntactically DNS queries for type TKEY. Such
queries MUST be accompanied by a TKEY RR in the additional queries MUST be accompanied by a TKEY RR in the additional
information section to indicate the mode in use and accompanied by information section to indicate the mode in use and accompanied by
other information where required. other information where required.
Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
ignore the recursive header bit in TKEY queries they receive. ignore the recursive header bit in TKEY queries they receive.
4.1 Query for Diffie-Hellman Exchanged Keying 4.1 Query for Diffie-Hellman Exchanged Keying
Diffie-Hellman (DH) key exchange is means whereby two parties can Diffie-Hellman (DH) key exchange is a means whereby two parties can
derive some shared secret information without requiring any secrecy derive some shared secret information without requiring any secrecy
of the messages they exchange [Schneier]. Provisions have been made of the messages they exchange [Schneier]. Provisions have been made
for the storage of DH public keys in the DNS [RFC 2539]. for the storage of DH public keys in the DNS [RFC 2539].
A resolver sends a query for type TKEY accompanied by a TKEY RR in A resolver sends a query for type TKEY accompanied by a TKEY RR in
the additional information section specifying the Diffie-Hellman mode the additional information section specifying the Diffie-Hellman mode
and accompanied by a KEY RR also in the additional information and accompanied by a KEY RR also in the additional information
section specifying a resolver Diffie-Hellman key. The TKEY RR section specifying a resolver Diffie-Hellman key. The TKEY RR
algorithm field is set to the authentication algorithm the resolver algorithm field is set to the authentication algorithm the resolver
plans to use. The "key data" provided in the TKEY is used as a random plans to use. The "key data" provided in the TKEY is used as a random
skipping to change at page 10, line 26 skipping to change at page 9, line 5
If the TKEY error field is zero, the resolver supplied Diffie-Hellman If the TKEY error field is zero, the resolver supplied Diffie-Hellman
KEY RR SHOULD be echoed in the additional information section and a KEY RR SHOULD be echoed in the additional information section and a
server Diffie-Hellman KEY RR will also be present in the answer server Diffie-Hellman KEY RR will also be present in the answer
section of the response. Both parties can then calculate the same section of the response. Both parties can then calculate the same
shared secret quantity from the pair of Diffie-Hellman (DH) keys used shared secret quantity from the pair of Diffie-Hellman (DH) keys used
[Schneier] (provided these DH keys use the same generator and [Schneier] (provided these DH keys use the same generator and
modulus) and the data in the TKEY RRs. The TKEY RR data is mixed modulus) and the data in the TKEY RRs. The TKEY RR data is mixed
with the DH result as follows: with the DH result as follows:
keying material = keying material =
XOR ( DH value, MD5 ( query data | DH value ) | XOR ( DH value, MD5 ( query data | DH value ) |
MD5 ( server data | DH value ) ) MD5 ( server data | DH value ) )
Where XOR is an exclusive-OR operation and "|" is byte-stream Where XOR is an exclusive-OR operation and "|" is byte-stream
concatenation. The shorter of the two operands to XOR is byte-wise concatenation. The shorter of the two operands to XOR is byte-wise
left justified and padded with zero-valued bytes to match the length left justified and padded with zero-valued bytes to match the length
of the other operand. "DH value" is the Diffie-Hellman value derived of the other operand. "DH value" is the Diffie-Hellman value derived
from the KEY RRs. Query data and server data are the values sent in from the KEY RRs. Query data and server data are the values sent in
the TKEY RR data fields. These "query data" and "server data" nonces the TKEY RR data fields. These "query data" and "server data" nonces
are suffixed by the DH value, digested by MD5, the results are suffixed by the DH value, digested by MD5, the results
concatenated, and then XORed with the DH value. concatenated, and then XORed with the DH value.
skipping to change at page 11, line 33 skipping to change at page 10, line 17
This mode is described in a separate document under preparation which This mode is described in a separate document under preparation which
should be seen for the full description. Basically the resolver and should be seen for the full description. Basically the resolver and
server can exchange queries and responses for type TKEY with a TKEY server can exchange queries and responses for type TKEY with a TKEY
RR specifying the GSS-API mode in the additional information section RR specifying the GSS-API mode in the additional information section
and a GSS-API token in the key data portion of the TKEY RR. and a GSS-API token in the key data portion of the TKEY RR.
Any issues of possible encryption of parts the GSS-API token data Any issues of possible encryption of parts the GSS-API token data
being transmitted are handled by the GSS-API level. In addition, the being transmitted are handled by the GSS-API level. In addition, the
GSS-API level provides its own authentication so that this mode of GSS-API level provides its own authentication so that this mode of
TKEY query and response MAY be, but do not need to be, authenticated TKEY query and response MAY be, but do not need to be, authenticated
with TSIG RR or SIG(0) RR. with TSIG RR or SIG(0) RR [RFC 2931].
The inception and expiry times in a GSS-API mode TKEY RR are ignored. The inception and expiry times in a GSS-API mode TKEY RR are ignored.
4.4 Query for Server Assigned Keying 4.4 Query for Server Assigned Keying
Optionally, the server can assign keying for the resolver. It is Optionally, the server can assign keying for the resolver. It is
sent to the resolver encrypted under a resolver public key. See sent to the resolver encrypted under a resolver public key. See
section 6 for description of encryption methods. section 6 for description of encryption methods.
A resolver sends a query for type TKEY accompanied by a TKEY RR A resolver sends a query for type TKEY accompanied by a TKEY RR
specifying the "server assignment" mode and a resolver KEY RR to be specifying the "server assignment" mode and a resolver KEY RR to be
used in encrypting the response, both in the additional information used in encrypting the response, both in the additional information
section. The TKEY algorithm field is set to the authentication section. The TKEY algorithm field is set to the authentication
algorithm the resolver plans to use. It is RECOMMENDED that any "key algorithm the resolver plans to use. It is RECOMMENDED that any "key
data" provided in the query TKEY RR by the resolver be strongly mixed data" provided in the query TKEY RR by the resolver be strongly mixed
by the server with server generated randomness [RFC 1750] to derive by the server with server generated randomness [RFC 1750] to derive
the keying material to be used. The KEY RR that appears in the query the keying material to be used. The KEY RR that appears in the query
need not be accompanied by a SIG(KEY) RR. If the query is need not be accompanied by a SIG(KEY) RR. If the query is
authenticated by the resolver with a TSIG RR [draft-ietf-dnsext- authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
tsig-*.txt] or SIG(0) RR and that authentication is verified, then and that authentication is verified, then any SIG(KEY) provided in
any SIG(KEY) provided in the query SHOULD be ignored. The KEY RR in the query SHOULD be ignored. The KEY RR in such a query SHOULD have
such a query SHOULD have a name that corresponds to the resolver but a name that corresponds to the resolver but it is only essential that
it is only essential that it be a public key for which the resolver it be a public key for which the resolver has the corresponding
has the corresponding private key so it can decrypt the response private key so it can decrypt the response data.
data.
The server response contains a TKEY RR in its answer section with the The server response contains a TKEY RR in its answer section with the
server assigned mode and echoes the KEY RR provided in the query in server assigned mode and echoes the KEY RR provided in the query in
its additional information section. its additional information section.
If the reponse TKEY error field is zero, the key data portion of the If the response TKEY error field is zero, the key data portion of the
response TKEY RR will be the server assigned keying data encrypted response TKEY RR will be the server assigned keying data encrypted
under the public key in the resolver provided KEY RR. In this case, under the public key in the resolver provided KEY RR. In this case,
the owner name of the answer TKEY RR will be the server assigned name the owner name of the answer TKEY RR will be the server assigned name
of the key. of the key.
If the error field of the response TKEY is non-zero, the query failed If the error field of the response TKEY is non-zero, the query failed
for the reason given. FORMERR is given if the query specified no for the reason given. FORMERR is given if the query specified no
encryption key. encryption key.
The inception and expiry times in the query TKEY RR are those The inception and expiry times in the query TKEY RR are those
skipping to change at page 14, line 37 skipping to change at page 13, line 17
length of each block is clear from the public RSA key specified and length of each block is clear from the public RSA key specified and
the RSAES-PKCS1-v1_5 padding makes it clear what part of the the RSAES-PKCS1-v1_5 padding makes it clear what part of the
encrypted data is actually keying material and what part is encrypted data is actually keying material and what part is
formatting or the required at least eight bytes of random [RFC 1750] formatting or the required at least eight bytes of random [RFC 1750]
padding. padding.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted as provided in [RFC 2434]. This section is to be interpreted as provided in [RFC 2434].
Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF Mode field values 0x0000 and 0xFFFF are reserved.
can only be assigned by an IETF standards action. Special
consideration should be given before the allocation of meaning for Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
Mode field values 0x0000 and 0xFFFF. can only be assigned by an IETF Standards Action.
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
are allocated by IESG approval or IETF consensus. are allocated by IESG approval or IETF consensus.
Mode field values 0x1000 through 0xEFFF are allocated based on Mode field values 0x1000 through 0xEFFF are allocated based on
Specification Required as defined in [RFC 2434]. Specification Required as defined in [RFC 2434].
Mode values should not be changed when the status of their use Mode values should not be changed when the status of their use
changes. For example, a mode value assigned based just on providing changes. For example, a mode value assigned based just on providing
a specification should not be changed later just because that use's a specification should not be changed later just because that use's
status is changed to standards track. status is changed to standards track.
The following assignments are documented herein: The following assignments are documented herein:
RR Type 249 for TKEY. RR Type 249 for TKEY.
TKEY Modes 1 through 5 as listed in section 2.5. TKEY Modes 1 through 5 as listed in section 2.5.
Extended RCODE Error values of 19, 20, and 21 as listed in Extended RCODE Error values of 19, 20, and 21 as listed in section
section 2.6. 2.6.
8. Security Considerations 8. Security Considerations
The entirety of this specification is concerned with the secure The entirety of this specification is concerned with the secure
establishment of a shared secret between DNS clients and servers in establishment of a shared secret between DNS clients and servers in
support of TSIG [draft-ietf-dnsext-tsig-*.txt]. support of TSIG [RFC 2845].
Protection against denial of service via the use of TKEY is not Protection against denial of service via the use of TKEY is not
provided. provided.
References References
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons Algorithms, and Source Code in C", 1996, John Wiley and
Sons
RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, November 1987. STD 13, RFC 1034, November 1987.
RFC 1035 - P. Mockapetris, "Domain Names - Implementation and [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, November 1987. Specifications", STD 13, RFC 1035, November 1987.
RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", December 1994. Recommendations for Security", RFC 1750, December 1994.
RFC 1982 - Robert Elz, Randy Bush, "Serial Number Arithmetic", [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
09/03/1996. September 1996.
RFC 1995 - Masataka Ohta, "Incremental Zone Transfer in DNS", August [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
1996. August 1996.
RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", October 1996. for IPv4, IPv6 and OSI", RFC 2030, October 1996.
RFC 2104 - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
for Message Authentication", February 1997. Hashing for Message Authentication", RFC 2104, February
1997.
RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs, October 1998. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", October 1998. Specifications Version 2.0", RFC 2437, October 1998.
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
March 1999. RFC 2535, March 1999.
RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Name System (DNS)", March 1999. Domain Name System (DNS)", RFC 2539, March 1999.
draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D. [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s )", RFC 2931, September 2000.
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Motorola
140 Forest Avenue 140 Forest Avenue
Hudson, MA 01749 USA Hudson, MA 01749 USA
Telephone: +1 978-562-2827 (h) Phone: +1 978-562-2827 (h)
+1 508-261-5434 (w) +1 508-261-5434 (w)
FAX: +1 978-567-7941 (h) Fax: +1 508-261-4447 (w)
+1 508-261-4447 (w) EMail: Donald.Eastlake@motorola.com
email: Donald.Eastlake@motorola.com
Expiration and File Name Full Copyright Statement
This draft expires December 2000. Copyright (C) The Internet Society (2000). All Rights Reserved.
Its file name is draft-ietf-dnsext-tkey-03.txt. 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 assigns.
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. 51 change blocks. 
192 lines changed or deleted 175 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/