--- 1/draft-ietf-dnsext-tkey-01.txt 2006-02-04 23:12:39.000000000 +0100 +++ 2/draft-ietf-dnsext-tkey-02.txt 2006-02-04 23:12:39.000000000 +0100 @@ -1,54 +1,53 @@ DNSEXT Working Group Donald E. Eastlake, 3rd INTERNET-DRAFT Motorola -Expires: September 2000 March 2000 +Expires: October 2000 April 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 or to the author. + This draft 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 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." + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + 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 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. 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. + [draft-ietf-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) @@ -78,45 +77,44 @@ 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 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. + [draft-ietf-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 @@ -136,21 +134,21 @@ 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 - servers. + servers which is currently used only for key deletion. 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. @@ -194,40 +192,40 @@ 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 + 89n3mDgX072pp.server1.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. + 1001.89n3mDgX072pp.server1.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. + 789.resolver.example.net.server1.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. + 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. 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 + meaning as in [draft-ietf-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 @@ -280,21 +278,21 @@ 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 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. + octets. The meaning of this 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 @@ -328,20 +326,23 @@ 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. + 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 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 @@ -431,22 +432,21 @@ 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. + 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 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 @@ -457,27 +457,27 @@ 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 - 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. + authenticated by the resolver with a TSIG RR [draft-ietf-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. @@ -504,102 +504,91 @@ 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 - (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. + keying material and will return a FORMERR, and for which no untrusted + party (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. + This technique can be used to delete a key and may be specified for + modes defined in the future. 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 + A server can optionally tell a client that it has deleted a secret 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. -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. + is encrypted as per the description of RSAES-PKCS1-v1_5 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 RSAES-PKCS1-v1_5 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 consideration should be given before the allocation of meaning for Mode field values 0x0000 and 0xFFFF. @@ -620,21 +609,21 @@ 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. + support of TSIG [draft-ietf-dnsext-tsig-*.txt]. Protection against denial of service via the use of TKEY is not provided. 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", @@ -669,30 +658,30 @@ 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. + draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". 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) + FAX: +1 508-261-4447 (w) email: Donald.Eastlake@motorola.com 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.