draft-ietf-dnsext-tkey-01.txt   draft-ietf-dnsext-tkey-02.txt 
DNSEXT Working Group Donald E. Eastlake, 3rd DNSEXT Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT Motorola INTERNET-DRAFT Motorola
Expires: September 2000 March 2000 Expires: October 2000 April 2000
Secret Key Establishment for DNS (TKEY RR) Secret Key Establishment for DNS (TKEY RR)
------ --- ------------- --- --- ----- --- ------ --- ------------- --- --- ----- ---
draft-ietf-dnsext-tkey-01.txt <draft-ietf-dnsext-tkey-02.txt>
Donald E. Eastlake 3rd
Status of This Document Status of This Document
This draft, file name draft-ietf-dnsext-tkey-01.txt, is intended to This draft is intended to be become a Proposed Standard RFC.
be become a Proposed Standard RFC. Distribution of this document is Distribution of this document is unlimited. Comments should be sent
unlimited. Comments should be sent to the DNS working group mailing to the DNS working group mailing list <namedroppers@ops.ietf.org> or
list <namedroppers@ops.ietf.org> or to the author. to the author.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months. Internet-Drafts may be updated, replaced, or obsoleted by
time. It is inappropriate to use Internet- Drafts as reference other documents at any time. It is not appropriate to use Internet-
material or to cite them other than as "work in progress." Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of [draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating
authenticating Domain Name System (DNS) queries and responses using Domain Name System (DNS) queries and responses using shared secret
shared secret keys via the TSIG resource record (RR). However, it keys via the TSIG resource record (RR). However, it provides no
provides no mechanism for setting up such keys other than manual mechanism for setting up such keys other than manual exchange. This
exchange. This document describes a TKEY RR that can be used in a document describes a TKEY RR that can be used in a number of
number of different modes to establish shared secret keys between a different modes to establish shared secret keys between a DNS
DNS resolver and server. 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)
skipping to change at page 3, line 34 skipping to change at page 3, line 34
2.8 The Other Size and Data Fields.........................8 2.8 The Other Size and Data Fields.........................8
3. General TKEY Considerations.............................8 3. General TKEY Considerations.............................8
4. Exchange via Resolver Query.............................9 4. Exchange via Resolver Query.............................9
4.1 Query for Diffie-Hellman Exchanged Keying..............9 4.1 Query for Diffie-Hellman Exchanged Keying..............9
4.2 Query for TKEY Deletion...............................10 4.2 Query for TKEY Deletion...............................10
4.3 Query for GSS-API Establishment.......................11 4.3 Query for GSS-API Establishment.......................11
4.4 Query for Server Assigned Keying......................11 4.4 Query for Server Assigned Keying......................11
4.5 Query for Resolver Assigned Keying....................12 4.5 Query for Resolver Assigned Keying....................12
5. Spontaneous Server Inclusion...........................13 5. Spontaneous Server Inclusion...........................13
5.1 Spontaneous Server Key Deletion.......................13 5.1 Spontaneous Server Key Deletion.......................13
5.2 Spontaneous GSS-API Exchange..........................14
6. Methods of Encryption..................................14 6. Methods of Encryption..................................14
7. IANA Considerations....................................14 7. IANA Considerations....................................14
8. Security Considerations................................15 8. Security Considerations................................15
References................................................16 References................................................16
Author's Address..........................................17 Author's Address..........................................17
Expiration and File Name..................................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-{dnsind|dnsext}-tsig-*.txt] provides a means of [draft-ietf-dnsext-tsig-*.txt] provides a means of efficiently
efficiently authenticating DNS messages using shared secret keys via authenticating DNS messages using shared secret keys via the TSIG
the TSIG resource record (RR) but provides no mechanism for setting resource record (RR) but provides no mechanism for setting up such
up such keys other than manual exchange. This document specifies a keys other than manual exchange. This document specifies a TKEY RR
TKEY RR that can be used in a number of different modes to establish that can be used in a number of different modes to establish and
and delete such shared secret keys between a DNS resolver and server. delete such shared secret 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 4 skipping to change at page 5, line 4
and considerations for its constituent fields. and considerations for its constituent fields.
Section 3 describes general principles of operations with TKEY. Section 3 describes general principles of operations with TKEY.
Section 4 discusses key agreement and deletion via DNS requests with Section 4 discusses key agreement and deletion via DNS requests with
the Query opcode for RR type TKEY. This method is applicable to all 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 currently defined TKEY modes, although in some cases it is not what
would intuitively be called a "query". would intuitively be called a "query".
Section 5 discusses spontaneous inclusion of TKEY RRs in responses by Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
servers. servers which is currently used only for key deletion.
Section 6 describes encryption methods for transmitting secret key Section 6 describes encryption methods for transmitting secret key
information. In this document these are used only for the server information. In this document these are used only for the server
assigned mode and the resolver assigned mode. assigned mode and the resolver assigned mode.
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.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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 owner name, then the server SHOULD create a globally unique its owner name, then the server SHOULD create a globally unique
domain name, to be the key name, by suffixing a pseudo-random domain name, to be the key name, by suffixing a pseudo-random
[RFC 1750] label with a domain name of the server. For example [RFC 1750] label with a domain name of the server. For example
89n3mDgX072pp.server.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.server.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 that with a name of the server. For example of that with a name of the server. For example
789.resolver.example.net.server.example.com. 789.resolver.example.net.server1.example.com.
2.2 The TTL Field 2.2 The TTL Field
The TTL field is meaningless. It SHOULD always be zero to be sure The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
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-{dnsind|dnsext}-tsig-*.txt]. The algorithm meaning as in [draft-ietf-dnsext-tsig-*.txt]. The algorithm
determines how the secret keying material agreed to using the TKEY RR determines how the secret keying material agreed to using the TKEY RR
is actually used to derive the algorithm specific key. is actually used to 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
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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
order which specifies the size of the key exchange data field in order which specifies the size of the key exchange data field in
octets. The meaning of the key data depends on the mode. octets. The meaning of this data depends on the mode.
2.8 The Other Size and Data Fields 2.8 The Other Size and Data Fields
The Other Size and Other Data fields are not used in this The Other Size and Other Data fields are not used in this
specification but may be used in future extensions. The RDLEN field specification but may be used in future extensions. The RDLEN field
MUST equal the length of the RDATA section through the end of Other MUST equal the length of the RDATA section through the end of Other
Data or the RR is to be considered malformed and rejected. Data or the RR is to be considered malformed and rejected.
3. General TKEY Considerations 3. General TKEY Considerations
skipping to change at page 9, line 16 skipping to change at page 9, line 16
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
query is itself providing. query is itself providing.
In the absence of required TKEY authentication, a NOTAUTH error MUST
be returned.
To avoid replay attacks, it is necessary that a TKEY response or 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 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 136 years), or a multiple thereof, later. To accomplish this, the
keying material used in any TSIG or SIG(0) RR that authenticates a 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 TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
(about 68 years). Thus, on attempted replay, the authenticating TSIG (about 68 years). Thus, on attempted replay, the authenticating TSIG
or SIG(0) RR will not be verifiable due to key expiration and the or SIG(0) RR will not be verifiable due to key expiration and the
replay will fail. replay will fail.
4. Exchange via Resolver Query 4. Exchange via Resolver Query
skipping to change at page 11, line 24 skipping to change at page 11, line 27
assigned keys, the server MAY simply mark the key as no longer 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 retained by the client and may re-send it in response to a future
query for server assigned keying material. query for server assigned keying material.
4.3 Query for GSS-API Establishment 4.3 Query for GSS-API Establishment
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. See also and a GSS-API token in the key data portion of the TKEY RR.
section 5.2.
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.
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
skipping to change at page 12, line 4 skipping to change at page 12, line 6
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- authenticated by the resolver with a TSIG RR [draft-ietf-dnsext-
{dnsind|dnsext}-tsig-*.txt] or SIG(0) RR and that authentication is tsig-*.txt] or SIG(0) RR and that authentication is verified, then
verified, then any SIG(KEY) provided in the query SHOULD be ignored. any SIG(KEY) provided in the query SHOULD be ignored. The KEY RR in
The KEY RR in such a query SHOULD have a name that corresponds to the such a query SHOULD have a name that corresponds to the resolver but
resolver but it is only essential that it be a public key for which it is only essential that it be a public key for which the resolver
the resolver has the corresponding private key so it can decrypt the has the corresponding private key so it can decrypt the response
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 reponse 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.
skipping to change at page 12, line 51 skipping to change at page 13, line 5
material must be encrypted under a server key for protection in material must be encrypted under a server key for protection in
transmission as described in Section 6. transmission as described in Section 6.
The resolver sends a TKEY query with a TKEY RR that specifies the The resolver sends a TKEY query with a TKEY RR that specifies the
encrypted keying material and a KEY RR specifying the server public encrypted keying material and a KEY RR specifying the server public
key used to encrypt the data, both in the additional information key used to encrypt the data, both in the additional information
section. The name of the key and the keying data are completely section. The name of the key and the keying data are completely
controlled by the sending resolver so a globally unique key name 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 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 the corresponding private key, or it will not be able to decrypt the
keying material and will return a FORMERR, and no untrusted party keying material and will return a FORMERR, and for which no untrusted
(preferably no other party than the server) has the private key, or party (preferably no other party than the server) has the private
the untrusted private key holder can capture the messages to the key, or the untrusted private key holder can capture the messages to
server, learn the shared secret, and spoof valid TSIGs. the server, learn the shared secret, and spoof valid TSIGs.
The query TKEY RR inception and expiry give the time period the The query TKEY RR inception and expiry give the time period the
querier intends to consider the keying material valid. The server querier intends to consider the keying material valid. The server
can return a lesser time interval to advise that it will not maintain 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. 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). This mode of query MUST be authenticated with a TSIG or SIG(0).
Otherwise, an attacker can forge a resolver assigned TKEY query, and Otherwise, an attacker can forge a resolver assigned TKEY query, and
thereby the attacker could specify a shared secret key that would be thereby the attacker could specify a shared secret key that would be
accepted, used, and honored by the server. accepted, used, and honored by the server.
5. Spontaneous Server Inclusion 5. Spontaneous Server Inclusion
A DNS server may include a TKEY RR spontaneously as additional A DNS server may include a TKEY RR spontaneously as additional
information in responses. This SHOULD only be done if the server information in responses. This SHOULD only be done if the server
knows the querier understands TKEY and has this option implemented. knows the querier understands TKEY and has this option implemented.
This technique can be used for GSS-API exchange, and to delete a key. This technique can be used to delete a key and may be specified for
A disadvantage of this technique is that there is no way for the modes defined in the future. A disadvantage of this technique is
server to get any error or success indication back and, in the case that there is no way for the server to get any error or success
of UDP, no way to even know if the DNS response reached the resolver. 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 5.1 Spontaneous Server Key Deletion
A server can optionally tell a client that it has deleted a symmetric A server can optionally tell a client that it has deleted a secret
key by spontaneously including a TKEY RR in the additional key by spontaneously including a TKEY RR in the additional
information section of a response with the key's name and specifying information section of a response with the key's name and specifying
the key deletion mode. Such a response SHOULD be authenticated. If the key deletion mode. Such a response SHOULD be authenticated. If
authenticated, it "deletes" the key with the given name. The authenticated, it "deletes" the key with the given name. The
inception and expiry times of the delete TKEY RR are ignored. Failure inception and expiry times of the delete TKEY RR are ignored. Failure
by a client to receive or properly process such additional by a client to receive or properly process such additional
information in a response would mean that the client might use a key 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. that the server had discarded and would then get an error indication.
For server assigned and Diffie-Hellman keys, the client must truly For server assigned and Diffie-Hellman keys, the client must truly
"discard" all active state associated with the key. For querier "discard" all active state associated with the key. For querier
assigned keys, the querier MAY simply mark the key as no longer 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 retained by the server and may re-send it in a future query
specifying querier assigned keying material. specifying querier assigned keying material.
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 6. Methods of Encryption
For the server assigned and resolver assigned key agreement modes, For the server assigned and resolver assigned key agreement modes,
the keying material is sent within the key data field of a TKEY RR 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]. 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 This KEY RR MUST be for a public key algorithm where the public and
private keys can be used for encryption and the corresponding private keys can be used for encryption and the corresponding
decryption which recovers the originally encrypted data. The KEY RR decryption which recovers the originally encrypted data. The KEY RR
SHOULD correspond to a name for the decrypting resolver/server such SHOULD correspond to a name for the decrypting resolver/server such
that the decrypting process has access to the corresponding private that the decrypting process has access to the corresponding private
key to decrypt the data. The secret keying material being sent will key to decrypt the data. The secret keying material being sent will
generally be fairly short, usually less than 256 bits, because that generally be fairly short, usually less than 256 bits, because that
is adequate for very strong protection with modern keyed hash or is adequate for very strong protection with modern keyed hash or
symmetric algorithms. symmetric algorithms.
If the KEY RR specifies the RSA algorithm, then the keying material 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 is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
2437]. (Note, the secret keying material being sent is directly RSA PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is
encrypted in PKCS#1 format, It is not "enveloped" under some other directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
symmetric algorithm.) In the unlikely event that the keying material some other symmetric algorithm.) In the unlikely event that the
will not fit within one RSA modulus of the chosen public key, keying material will not fit within one RSA modulus of the chosen
additional RSA encryption blocks are included. The length of each public key, additional RSA encryption blocks are included. The
block is clear from the public RSA key specified and the PKCS#1 length of each block is clear from the public RSA key specified and
padding makes it clear what part of the encrypted data is actually the RSAES-PKCS1-v1_5 padding makes it clear what part of the
keying material and what part is formatting or the required at least encrypted data is actually keying material and what part is
eight bytes of random [RFC 1750] padding. formatting or the required at least eight bytes of random [RFC 1750]
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 through 0x00FF, and 0XFF00 through 0XFFFF
can only be assigned by an IETF standards action. Special can only be assigned by an IETF standards action. Special
consideration should be given before the allocation of meaning for consideration should be given before the allocation of meaning for
Mode field values 0x0000 and 0xFFFF. Mode field values 0x0000 and 0xFFFF.
skipping to change at page 15, line 31 skipping to change at page 15, line 18
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 2.6. section 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. support of TSIG [draft-ietf-dnsext-tsig-*.txt].
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 - P. Mockapetris, "Domain Names - Concepts and Facilities",
skipping to change at page 16, line 49 skipping to change at page 16, line 49
RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", October 1998. Specifications Version 2.0", October 1998.
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999. March 1999.
RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", March 1999. Name System (DNS)", March 1999.
draft-ietf-{dnsind|dnsext}-tsig-*.txt - P. Vixie, O. Gudmundsson, D. draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Motorola
65 Shindegan Hill Road, RR #1 65 Shindegan Hill Road, RR #1
Carmel, NY 10512 USA Carmel, NY 10512 USA
Telephone: +1 914-276-2668 (h) Telephone: +1 914-276-2668 (h)
+1 508-261-5434 (w) +1 508-261-5434 (w)
FAX: +1 914-276-2947 (h) FAX: +1 508-261-4447 (w)
email: Donald.Eastlake@motorola.com email: Donald.Eastlake@motorola.com
Expiration and File Name Expiration and File Name
This draft expires August 2000. This draft expires October 2000.
Its file name is draft-ietf-dnsext-tkey-01.txt. Its file name is draft-ietf-dnsext-tkey-02.txt.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/