DNSEXT Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT Motorola
Expires: September 2000 March 2000
Secret Key Establishment for DNS (TKEY RR)
------ --- ------------- --- --- ----- ---
draft-ietf-dnsext-tkey-01.txt
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsext-tkey-01.txt, is intended to
be become a Proposed Standard RFC. 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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT The DNS TKEY RR March 2000
Abstract
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of
authenticating Domain Name System (DNS) queries and responses using
shared secret keys via the TSIG resource record (RR). However, it
provides no mechanism for setting up such keys other than manual
exchange. This document describes a TKEY RR that can be used in a
number of different modes to establish shared secret keys between a
DNS resolver and server.
Acknowledgments
The comments and ideas of the following persons (listed in alphabetic
order) have been incorporated herein and are gratefully acknowledged:
Olafur Gudmundsson (TIS)
Stuart Kwan (Microsoft)
Ed Lewis (TIS)
Brian Wellington (TIS)
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT The DNS TKEY RR March 2000
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgments............................................2
Table of Contents..........................................3
1. Introduction............................................4
1.1 Overview of Contents...................................4
2. The TKEY Resource Record................................5
2.1 The Name Field.........................................5
2.2 The TTL Field..........................................6
2.3 The Algorithm Field....................................6
2.4 The Inception and Expiration Fields....................6
2.5 The Mode Field.........................................7
2.6 The Error Field........................................7
2.7 The Key Size and Data Fields...........................8
2.8 The Other Size and Data Fields.........................8
3. General TKEY Considerations.............................8
4. Exchange via Resolver Query.............................9
4.1 Query for Diffie-Hellman Exchanged Keying..............9
4.2 Query for TKEY Deletion...............................10
4.3 Query for GSS-API Establishment.......................11
4.4 Query for Server Assigned Keying......................11
4.5 Query for Resolver Assigned Keying....................12
5. Spontaneous Server Inclusion...........................13
5.1 Spontaneous Server Key Deletion.......................13
5.2 Spontaneous GSS-API Exchange..........................14
6. Methods of Encryption..................................14
7. IANA Considerations....................................14
8. Security Considerations................................15
References................................................16
Author's Address..........................................17
Expiration and File Name..................................17
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT The DNS TKEY RR March 2000
1. Introduction
The Domain Name System (DNS) is a hierarchical, distributed, highly
available database used for bi-directional mapping between domain
names and addresses, for email routing, and for other information
[RFC 1034, 1035]. It has been extended to provide for public key
security and dynamic update [RFC 2535, RFC 2136]. Familiarity with
these RFCs is assumed.
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of
efficiently authenticating DNS messages using shared secret keys via
the TSIG resource record (RR) but provides no mechanism for setting
up such keys other than manual exchange. This document specifies a
TKEY RR that can be used in a number of different modes to establish
and delete such shared secret keys between a DNS resolver and server.
Note that TKEY established keying material and TSIGs that use it are
associated with DNS servers or resolvers. They are not associated
with zones. They may be used to authenticate queries and responses
but they do not provide zone based DNS data origin or denial
authentication [RFC 2535].
Certain modes of TKEY perform encryption which may affect their
export or import status for some countries. The affected modes
specified in this document are the server assigned mode and the
resolver assigned mode.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
In all cases herein, the term "resolver" includes that part of a
server which may make full and incremental [RFC 1995] zone transfer
queries, forwards recursive queries, etc.
1.1 Overview of Contents
Section 2 below specifies the TKEY RR and provides a description of
and considerations for its constituent fields.
Section 3 describes general principles of operations with TKEY.
Section 4 discusses key agreement and deletion via DNS requests with
the Query opcode for RR type TKEY. This method is applicable to all
currently defined TKEY modes, although in some cases it is not what
would intuitively be called a "query".
Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT The DNS TKEY RR March 2000
servers.
Section 6 describes encryption methods for transmitting secret key
information. In this document these are used only for the server
assigned mode and the resolver assigned mode.
Section 7 covers IANA considerations in assignment of TKEY modes.
Finally, Section 8 provides the required security considerations
section.
2. The TKEY Resource Record
The TKEY resource record (RR) has the structure given below. Its RR
type code is 249.
Field Type Comment
----- ---- -------
NAME domain see description below
TTYPE u_int16_t TKEY = 249
CLASS u_int16_t ignored, SHOULD be 255 (ANY)
TTL u_int32_t ignored, SHOULD be zero
RDLEN u_int16_t size of RDATA
RDATA:
Algorithm: domain
Inception: u_int32_t
Expiration: u_int32_t
Mode: u_int16_t
Error: u_int16_t
Key Size: u_int16_t
Key Data: octet-stream
Other Size: u_int16_t
Other Data: octet-stream undefined by this specification
2.1 The Name Field
The Name field relates to naming keys. Its meaning differs somewhat
with mode and context as explained in subsequent sections.
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
establish another set of keying material at a server for an existing
name returns a BADNAME error.
For a TKEY with a non-root name appearing in a query, the TKEY RR
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT The DNS TKEY RR March 2000
name SHOULD be a domain locally unique at the resolver, less than 128
octets long in wire encoding, and meaningful to the resolver to
assist in distinguishing keys and/or key agreement sessions. For
TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
be a globally unique server assigned domain.
A reasonable key naming strategy is as follows:
If the key is generated as the result of a query with root as
its owner name, then the server SHOULD create a globally unique
domain name, to be the key name, by suffixing a pseudo-random
[RFC 1750] label with a domain name of the server. For example
89n3mDgX072pp.server.example.com. If generation of a new
pseudo-random name in each case is an excessive computation load
or entropy drain, a serial number prefix can be added to a fixed
pseudo-random name generated an DNS server start time, such as
1001.89n3mDgX072pp.server.example.com.
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
of that with a name of the server. For example
789.resolver.example.net.server.example.com.
2.2 The TTL Field
The TTL field is meaningless. It SHOULD always be zero to be sure
that older DNS implementations do not cache TKEY RRs.
2.3 The Algorithm Field
The algorithm name is in the form of a domain name with the same
meaning as in [draft-ietf-{dnsind|dnsext}-tsig-*.txt]. The algorithm
determines how the secret keying material agreed to using the TKEY RR
is actually used to derive the algorithm specific key.
2.4 The Inception and Expiration Fields
The inception time and expiration times are in number of seconds
since the beginning of 1 January 1970 GMT ignoring leap seconds
treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
between a DNS resolver and a DNS server where these fields are
meaningful, they are either the requested validity interval for the
keying material asked for or specify the validity interval of keying
material provided.
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT The DNS TKEY RR March 2000
To avoid different interpretations of the inception and expiration
times in TKEY RRs, resolvers and servers exchanging them must have
the same idea of what time it is. One way of doing this is with the
NTP protocol [RFC 2030] but that or any other time synchronization
used for this purpose MUST be done securely.
2.5 The Mode Field
The mode field specifies the general scheme for key agreement or the
purpose of the TKEY DNS message. Servers and resolvers supporting
this specification MUST implement the Diffie-Hellman key agreement
mode and the key deletion mode for queries. All other modes are
OPTIONAL. A server supporting TKEY that receives a TKEY request with
a mode it does not support returns the BADMODE error. The following
values of the Mode octet are defined, available, or reserved:
Value Description
----- -----------
0 - reserved, see section 7
1 server assignment
2 Diffie-Hellman exchange
3 GSS-API negotiation
4 resolver assignment
5 key deletion
6-65534 - available, see section 7
65535 - reserved, see section 7
2.6 The Error Field
The error code field is an extended RCODE. The following values are
defined:
Value Description
----- -----------
0 - no error
1-15 a non-extended RCODE
16 BADSIG (tsig)
17 BADKEY (tsig)
18 BADTIME (tsig)
19 BADMODE
20 BADNAME
21 BADALG
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
possible if a TKEY is spontaneously included in a response the TKEY
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT The DNS TKEY RR March 2000
RR and DNS header error field could have unrelated non-zero error
codes.
2.7 The Key Size and Data Fields
The key data size field is an unsigned 16 bit integer in network
order which specifies the size of the key exchange data field in
octets. The meaning of the key data depends on the mode.
2.8 The Other Size and Data Fields
The Other Size and Other Data fields are not used in this
specification but may be used in future extensions. The RDLEN field
MUST equal the length of the RDATA section through the end of Other
Data or the RR is to be considered malformed and rejected.
3. General TKEY Considerations
TKEY is a meta-RR that is not stored or cached in the DNS and does
not appear in zone files. It supports a variety of modes for the
establishment and deletion of shared secret keys information between
DNS resolvers and servers. The establishment of such a shared key
requires that state be maintained at both ends and the allocation of
the resources to maintain such state may require mutual agreement. In
the absence of willingness to provide such state, servers MUST return
errors such as NOTIMP or REFUSED for an attempt to use TKEY and
resolvers are free to ignore any TKEY RRs they receive.
The shared secret keying material developed by using TKEY is a plain
octet sequence. The means by which this shared secret keying
material, exchanged via TKEY, is actually used in any particular TSIG
algorithm is algorithm dependent and is defined in connection with
that algorithm. For example, see [RFC 2104] for how TKEY agreed
shared secret keying material is used in the HMAC-MD5 algorithm or
other HMAC algorithms.
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
transaction authentication to protect the integrity of any keying
data, error codes, etc. This authentication MUST use a previously
established secret (TSIG) or public (SIG(0)) key and MUST NOT use any
key that the response to be verified is itself providing.
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT The DNS TKEY RR March 2000
TKEY queries MUST be authenticated for all modes except GSS-API and,
under some circumstances, server assignment mode. In particular, if
the query for a server assigned key is for a key to assert some
privilege, such as update authority, then the query must be
authenticated to avoid spoofing. However, if the key is just to be
used for transaction security, then spoofing will lead at worst to
denial of service. Query authentication SHOULD use an established
secret (TSIG) key authenticator if available. Otherwise, it must use
a public (SIG(0)) key signature. It MUST NOT use any key that the
query is itself providing.
To avoid replay attacks, it is necessary that a TKEY response or
query not be valid if replayed on the order of 2**32 second (about
136 years), or a multiple thereof, later. To accomplish this, the
keying material used in any TSIG or SIG(0) RR that authenticates a
TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
(about 68 years). Thus, on attempted replay, the authenticating TSIG
or SIG(0) RR will not be verifiable due to key expiration and the
replay will fail.
4. Exchange via Resolver Query
One method for a resolver and a server to agree about shared secret
keying material for use in TSIG is through DNS requests from the
resolver which are syntactically DNS queries for type TKEY. Such
queries MUST be accompanied by a TKEY RR in the additional
information section to indicate the mode in use and accompanied by
other information where required.
Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
ignore the recursive header bit in TKEY queries they receive.
4.1 Query for Diffie-Hellman Exchanged Keying
Diffie-Hellman (DH) key exchange is means whereby two parties can
derive some shared secret information without requiring any secrecy
of the messages they exchange [Schneier]. Provisions have been made
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
the additional information section specifying the Diffie-Hellman mode
and accompanied by a KEY RR also in the additional information
section specifying a resolver Diffie-Hellman key. The TKEY RR
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
[RFC 1750] nonce to avoid always deriving the same keying material
Donald E. Eastlake 3rd [Page 9]
INTERNET-DRAFT The DNS TKEY RR March 2000
for the same pair of DH KEYs.
The server response contains a TKEY in its answer section with the
Diffie-Hellman mode. The "key data" provided in this TKEY is used as
an additional nonce to avoid always deriving the same keying material
for the same pair of DH KEYs. If the TKEY error field is non-zero,
the query failed for the reason given. FORMERR is given if the query
included no DH KEY and BADKEY is given if the query included an
incompatible DH KEY.
If the TKEY error field is zero, the resolver supplied Diffie-Hellman
KEY RR SHOULD be echoed in the additional information section and a
server Diffie-Hellman KEY RR will also be present in the answer
section of the response. Both parties can then calculate the same
shared secret quantity from the pair of Diffie-Hellman (DH) keys used
[Schneier] (provided these DH keys use the same generator and
modulus) and the data in the TKEY RRs. The TKEY RR data is mixed
with the DH result as follows:
keying material =
XOR ( DH value, MD5 ( query data | DH value ) |
MD5 ( server data | DH value ) )
Where XOR is an exclusive-OR operation and "|" is byte-stream
concatenation. The shorter of the two operands to XOR is byte-wise
left justified and padded with zero-valued bytes to match the length
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
the TKEY RR data fields. These "query data" and "server data" nonces
are suffixed by the DH value, digested by MD5, the results
concatenated, and then XORed with the DH value.
The inception and expiry times in the query TKEY RR are those
requested for the keying material. The inception and expiry times in
the response TKEY RR are the maximum period the server will consider
the keying material valid. Servers may pre-expire keys so this is
not a guarantee.
4.2 Query for TKEY Deletion
Keys established via TKEY can be treated as soft state. Since DNS
transactions are originated by the resolver, the resolver can simply
toss keys, although it may have to go through another key exchange if
it later needs one. Similarly, the server can discard keys although
that will result in an error on receiving a query with a TSIG using
the discarded key.
To avoid attempted reliance in requests on keys no longer in effect,
Donald E. Eastlake 3rd [Page 10]
INTERNET-DRAFT The DNS TKEY RR March 2000
servers MUST implement key deletion whereby the server "discards" a
key on receipt from a resolver of an authenticated delete request for
a TKEY RR with the key's name. If the server has no record of a key
with that name, it returns BADNAME.
Key deletion TKEY queries MUST be authenticated. This authentication
MAY be a TSIG RR using the key to be deleted.
For querier assigned and Diffie-Hellman keys, the server MUST truly
"discard" all active state associated with the key. For server
assigned keys, the server MAY simply mark the key as no longer
retained by the client and may re-send it in response to a future
query for server assigned keying material.
4.3 Query for GSS-API Establishment
This mode is described in a separate document under preparation which
should be seen for the full description. Basically the resolver and
server can exchange queries and responses for type TKEY with a TKEY
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. See also
section 5.2.
Any issues of possible encryption of parts the GSS-API token data
being transmitted are handled by the GSS-API level. In addition, the
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
with TSIG RR or SIG(0) RR.
The inception and expiry times in a GSS-API mode TKEY RR are ignored.
4.4 Query for Server Assigned Keying
Optionally, the server can assign keying for the resolver. It is
sent to the resolver encrypted under a resolver public key. See
section 6 for description of encryption methods.
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
used in encrypting the response, both in the additional information
section. The TKEY algorithm field is set to the authentication
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
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
need not be accompanied by a SIG(KEY) RR. If the query is
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT The DNS TKEY RR March 2000
authenticated by the resolver with a TSIG RR [draft-ietf-
{dnsind|dnsext}-tsig-*.txt] or SIG(0) RR and that authentication is
verified, then any SIG(KEY) provided in the query SHOULD be ignored.
The KEY RR in such a query SHOULD have a name that corresponds to the
resolver but it is only essential that it be a public key for which
the resolver has the corresponding private key so it can decrypt the
response data.
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
its additional information section.
If the reponse TKEY error field is zero, the key data portion of the
response TKEY RR will be the server assigned keying data encrypted
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
of the key.
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
encryption key.
The inception and expiry times in the query TKEY RR are those
requested for the keying material. The inception and expiry times in
the response TKEY are the maximum period the server will consider the
keying material valid. Servers may pre-expire keys so this is not a
guarantee.
The resolver KEY RR MUST be authenticated, through the authentication
of this query with a TSIG or SIG(0) or the signing of the resolver
KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY
for which they know the private key, and thereby the attacker could
obtain a valid shared secret key from the server.
4.5 Query for Resolver Assigned Keying
Optionally, a server can accept resolver assigned keys. The keying
material must be encrypted under a server key for protection in
transmission as described in Section 6.
The resolver sends a TKEY query with a TKEY RR that specifies the
encrypted keying material and a KEY RR specifying the server public
key used to encrypt the data, both in the additional information
section. The name of the key and the keying data are completely
controlled by the sending resolver so a globally unique key name
SHOULD be used. The KEY RR used MUST be one for which the server has
the corresponding private key, or it will not be able to decrypt the
keying material and will return a FORMERR, and no untrusted party
Donald E. Eastlake 3rd [Page 12]
INTERNET-DRAFT The DNS TKEY RR March 2000
(preferably no other party than the server) has the private key, or
the untrusted private key holder can capture the messages to the
server, learn the shared secret, and spoof valid TSIGs.
The query TKEY RR inception and expiry give the time period the
querier intends to consider the keying material valid. The server
can return a lesser time interval to advise that it will not maintain
state for that long and can pre-expire keys in any case.
This mode of query MUST be authenticated with a TSIG or SIG(0).
Otherwise, an attacker can forge a resolver assigned TKEY query, and
thereby the attacker could specify a shared secret key that would be
accepted, used, and honored by the server.
5. Spontaneous Server Inclusion
A DNS server may include a TKEY RR spontaneously as additional
information in responses. This SHOULD only be done if the server
knows the querier understands TKEY and has this option implemented.
This technique can be used for GSS-API exchange, and to delete a key.
A disadvantage of this technique is that there is no way for the
server to get any error or success indication back and, in the case
of UDP, no way to even know if the DNS response reached the resolver.
5.1 Spontaneous Server Key Deletion
A server can optionally tell a client that it has deleted a symmetric
key by spontaneously including a TKEY RR in the additional
information section of a response with the key's name and specifying
the key deletion mode. Such a response SHOULD be authenticated. If
authenticated, it "deletes" the key with the given name. The
inception and expiry times of the delete TKEY RR are ignored. Failure
by a client to receive or properly process such additional
information in a response would mean that the client might use a key
that the server had discarded and would then get an error indication.
For server assigned and Diffie-Hellman keys, the client must truly
"discard" all active state associated with the key. For querier
assigned keys, the querier MAY simply mark the key as no longer
retained by the server and may re-send it in a future query
specifying querier assigned keying material.
Donald E. Eastlake 3rd [Page 13]
INTERNET-DRAFT The DNS TKEY RR March 2000
5.2 Spontaneous GSS-API Exchange
A server can spontaneously include in the additional information
section of a response, a GSS-API mode TKEY RR. The information in
the key data section of such a TKEY is a GSS-API token which SHOULD
be fed by the resolver to its local GSS-API implementation. If such
a response is authenticated, the authentication MAY be verify before
processing the data. To the extent that GSS-API provides its own
security, such a response need not be authenticated. To the extent
that GSS-API handles duplicated messages, such a spontaneous TKEY
could be sent repeatedly, until, for example, a response via a GSS-
API mode TKEY query is received. See also section 4.3.
6. Methods of Encryption
For the server assigned and resolver assigned key agreement modes,
the keying material is sent within the key data field of a TKEY RR
encrypted under the public key in an accompanying KEY RR [RFC 2535].
This KEY RR MUST be for a public key algorithm where the public and
private keys can be used for encryption and the corresponding
decryption which recovers the originally encrypted data. The KEY RR
SHOULD correspond to a name for the decrypting resolver/server such
that the decrypting process has access to the corresponding private
key to decrypt the data. The secret keying material being sent will
generally be fairly short, usually less than 256 bits, because that
is adequate for very strong protection with modern keyed hash or
symmetric algorithms.
If the KEY RR specifies the RSA algorithm, then the keying material
is encrypted as per the description of RSA encryption in PKCS#1 [RFC
2437]. (Note, the secret keying material being sent is directly RSA
encrypted in PKCS#1 format, It is not "enveloped" under some other
symmetric algorithm.) In the unlikely event that the keying material
will not fit within one RSA modulus of the chosen public key,
additional RSA encryption blocks are included. The length of each
block is clear from the public RSA key specified and the PKCS#1
padding makes it clear what part of the encrypted data is actually
keying material and what part is formatting or the required at least
eight bytes of random [RFC 1750] padding.
7. IANA Considerations
This section is to be interpreted as provided in [RFC 2434].
Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF
can only be assigned by an IETF standards action. Special
Donald E. Eastlake 3rd [Page 14]
INTERNET-DRAFT The DNS TKEY RR March 2000
consideration should be given before the allocation of meaning for
Mode field values 0x0000 and 0xFFFF.
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
are allocated by IESG approval or IETF consensus.
Mode field values 0x1000 through 0xEFFF are allocated based on
Specification Required as defined in [RFC 2434].
Mode values should not be changed when the status of their use
changes. For example, a mode value assigned for an Experimental
Standard should not be changed later just because that standard's
status is changed to Proposed.
The following assignments are documented herein:
RR Type 249 for TKEY.
TKEY Modes 1 through 5 as listed in section 2.5.
Extended RCODE Error values of 19, 20, and 21 as listed in
section 2.6.
8. Security Considerations
The entirety of this specification is concerned with the secure
establishment of a shared secret between DNS clients and servers in
support of TSIG.
Protection against denial of service via the use of TKEY is not
provided.
Donald E. Eastlake 3rd [Page 15]
INTERNET-DRAFT The DNS TKEY RR March 2000
References
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
STD 13, November 1987.
RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness
Recommendations for Security", December 1994.
RFC 1982 - Robert Elz, Randy Bush, "Serial Number Arithmetic",
09/03/1996.
RFC 1995 - Masataka Ohta, "Incremental Zone Transfer in DNS", August
1996.
RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", October 1996.
RFC 2104 - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", February 1997.
RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs, October 1998.
RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", October 1998.
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", March 1999.
draft-ietf-{dnsind|dnsext}-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
Donald E. Eastlake 3rd [Page 16]
INTERNET-DRAFT The DNS TKEY RR March 2000
Author's Address
Donald E. Eastlake 3rd
Motorola
65 Shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1 914-276-2668 (h)
+1 508-261-5434 (w)
FAX: +1 914-276-2947 (h)
email: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires August 2000.
Its file name is draft-ietf-dnsext-tkey-01.txt.
Donald E. Eastlake 3rd [Page 17]