DNS Working Group Donald E. Eastlake, 3rd INTERNET-DRAFT IBM Expires: April 2000 October 1999 draft-ietf-dnsind-tkey-01.txt Secret Key Establishment for DNS (TKEY RR) ------ --- ------------- --- --- ----- --- Donald E. Eastlake 3rd Status of This Document This draft, file name draft-ietf-dnsind-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 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. 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. Donald E. Eastlake, 3rd [Page 1] INTERNET-DRAFT The DNS TKEY RR October 19999 Abstract [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and securing 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 substantial comments and ideas of the following persons (listed in alphabetic order) have been incorporated herein and are gratefully acknowledged: Olafur Gudmundsson Stuart Kwan Brian Wellington Donald E. Eastlake, 3rd [Page 2] INTERNET-DRAFT The DNS TKEY RR October 19999 Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgments............................................2 Table of Contents..........................................3 1. Introduction............................................4 1.1 General Principles.....................................4 1.2 Overview of Contents...................................5 2. The TKEY Resource Record................................6 3. Exchange via Resolver Query.............................7 3.1 Query for Server Assigned Keying.......................8 3.2 Query for Diffie-Hellman Exchanged Keying..............9 3.3 Query for GSS-API Established.........................10 3.4 Query for Querier Assigned Keying.....................10 3.5 Query for TKEY Deletion...............................11 4. Spontaneous Server Inclusion...........................11 4.1 Spontaneous GSS-API Exchange..........................11 4.2 Spontaneous Key Deletion..............................12 5. Methods of Encryption..................................12 6. IANA Considerations....................................12 7. Security Considerations................................13 Changes from Previous Draft...............................14 References................................................15 Author's Address..........................................16 Expiration and File Name..................................16 Donald E. Eastlake, 3rd [Page 3] INTERNET-DRAFT The DNS TKEY RR October 19999 1. Introduction The Domain Name System (DNS) is a hierarchical, distributed, highly available database used for 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 2136, RFC 2535]. Familiarity with these RFCs is assumed. [draft-ietf-dnsind-tsig-*.txt] provides a means of more efficiently authenticating and securing 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 describes a TKEY RR that can be used in a number of different modes to establish such shared secret keys between a DNS resolver and server. 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]. 1.1 General Principles 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 between DNS entities such as resolvers and servers. The establishment of such a key requires that state be maintained at both the resolver and the server and the allocation of the resources to maintain such state may require mutual agreement. In the absence of such agreement, servers are free to return errors such as NotImp or Refused for any attempt to use TKEY and resolvers are free to ignore any TKEY RRs they receive. In all cases herein, the term "resolver" includes that part of a server which makes full and incremental [RFC 1995] zone transfer queries as well as other queries. Servers are not required to implement any particular mode or modes of the defined modes of TKEY shared secret key establishment or deletion and may return errors such as NotImp for any they do not support. In the future, based on experience, more modes may be added or some modes described herein may be made mandatory or deprecated. The means by which the 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. Note that TKEY established keying material and TSIGs that use it are Donald E. Eastlake, 3rd [Page 4] INTERNET-DRAFT The DNS TKEY RR October 19999 associated with DNS hosts. They are not necessairly associated with zones. They may be used to authenticate queries and responses but they do not provide zone stored DNS data origin or denial authentication [RFC 2535]. Two modes of TKEY, the server assigned and resolver assigned modes, perform encryption which may effect their export or import status for some countries. All other aspects of DNS security, including the SIG, KEY, NXT, and TSIG RRs and all other currently defined modes of TKEY perform authentication (signatures and signature verification) only. General protection against denial of service via the use of TKEY is not provided. Only one TKEY RR may occur in a queryr or response. Between any pair of hosts, only one set of keying material may be in place at the same time for any particulary key name. An attempt to establish another set of keying material at a server for an existing name should return a BADNAME error. 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, they the server can create a name consisting of a hash of the key plus the server host name. For example 89n3mdg072pp.host.example.com. If the key is generated as the result of a query with a non-root name, say foo.example.net, the use the concatenation of that with the server host name. For example foo.example.net.host.example.com. 1.2 Overview of Contents Section 2 below specifies the TKEY resource record (RR) and provides a high level description of its constituent fields. Section 3 discusses key exchange via requests with the Query opcode for type TKEY. This is applicable to all currently defined TKEY modes and in some cases in not what would intuitively be called a "query". Section 4 discusses spontaneous inclusion of TKEY RRs in responses by servers. This is applicable to key deletion and to server assigned modes. Section 5 describes encryption methods for transmitting secret key information. Donald E. Eastlake, 3rd [Page 5] INTERNET-DRAFT The DNS TKEY RR October 19999 Section 6 covers IANA considerations in assignment of TKEY modes. Finally, Section 7 touches on some security considerations. 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 CLASS u_int16_t ignored, should be zero TTL u_int32_t 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 protocol The Name field's meaning differs somewhat with mode and context as explained in subsequent sections. The TTL field SHOULD always be zero to be sure that older DNS implementations do not cache TKEY RRs. The algorithm name is a domain name with the same meaning as in [draft-ietf-dnsind-tsig-*.txt]. The algorithm determines how the secret keying material exchanged using the TKEY RR is actually used to derive the algorithm specific key that is used. The inception time and expiration time 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 to 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. See Security Considerations section in reference to replay attacks. The mode field specifies the general scheme for key agreement or Donald E. Eastlake, 3rd [Page 6] INTERNET-DRAFT The DNS TKEY RR October 19999 purpose of the TKEY DNS message. Note that implementation of TKEY as a whole and of any particular mode is optional. The following values of the Mode octet are defined, available, or reserved: Value Description ----- ----------- 0 - reserved 1 server/responder assignment 2 Diffie-Hellman exchange 3 GSS-API negotiation 4 resolver/querier assignment 5 key deletion 6-65534 - available, see IANA considerations section 65535 -reserved The error code field is an extended RCODE. The following values are defined: Value Description ----- ----------- 0 - no error 1-15 a DNS RCODE 16 BADSIG 17 BADKEY 18 BADTIME 19 BADMODE 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. The Other Size and Other Data fields are not used. 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. Exchange via Resolver Query One method for a resolver and a server to negotiate about shared secret key for use in TSIG is through DNS requests from the resolver which are syntactically 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 other information where required or the resolver and server must have a prior agreement that supplies any information that would otherwise have had to be conveyed by a TKEY RR in the query. For TKEY(s) appearing in a query, the TKEY RR name SHOULD be a domain locally unique at the resolver (or globally unique), less than 128 octets long, and meaningful to the resolver to distinguish keys Donald E. Eastlake, 3rd [Page 7] INTERNET-DRAFT The DNS TKEY RR October 19999 and/or key agreement sessions. (For resolvers not wishing to make this use of the name, it may be specified as root to minimize length.) For TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD be a globally unique server assigned domain. If the TKEY in a response is the result of a query containing a TKEY with a non- root name, that query TKEY name SHOULD be incorporated in the response TKEY name. Specific suggestions are given under some modes below. Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY ignore the recursive header bit in TKEY queries they receive. 3.1 Query for Server Assigned Keying In server assigned keying, the DNS server host generates the keying material and it is sent to the resolver encrypted under a resolver host key. See section 5 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 host KEY RR to be used in encrypting the response, both in the additional information section. The TKEY algorithm field is set to the signature algorithm the resolver plans to use. It is recommended that any "key data" optionally provided in the query TKEY by the resolver be strongly mixed with server generated randomness [RFC 1750] to derive the keying material to be used. The KEY that appears in the query SHOULD have a zero TTL. It need not be accompanied by a SIG(KEY) and if the query is signed by the resolver host and that signature is verified, then any SIG(KEY) provided MAY be ignored for key exchange purposes. The KEY RR in such a query SHOULD have a name that corresponds to the resolver host 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. Accepting and responding to an unsigned query of this sort may drain some entropy from an entropy pool being maintained by the server and used for secret key generation and so might enable an entropy exhaustion attack. In addition, some significant amount of computational resources may be used in the public key encryption of response data. To protect against these effects, a server SHOULD require such a query to be signed and MAY rate limit responses. The server response contains a TKEY in its answer section with the server assigned mode and echoes back the KEY RR provided in the query in its additional information section 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 Donald E. Eastlake, 3rd [Page 8] INTERNET-DRAFT The DNS TKEY RR October 19999 encryption key. If the 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 name of the answer TKEY RR will be the server assigned name of the key and SHOULD be globally unique. The inception and expiry times in the query TKEY 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. 3.2 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 client 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 specifying a client host Diffie-Hellman key. The TKEY algorithm field is set to the signature algorithm the resolver plans to use. Any "key data" provided in the TKEY is ignored by the server. Accepting and responding to an unsigned query of this sort may use significant computation at the server; however, if the server requires that the request be signed, then if no shared secret is in place to permit a TSIG to be used on the request, it would be necessary to use a SIG(0) the verification of which would impose its own computational load. The server response contains a TKEY in its answer section with the Diffie-Hellman mode. If the 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 error field is zero, the client host supplied Diffie-Hellman KEY should be echoed back and a server host Diffie-Hellman KEY RR will also be present in the response. Both parties can then calculate the same shared secret quantity from the pair of Diffie-Hellman keys used [Schneier], provided they use the same modulus, and the data in the TKEY. The TKEY data is strongly mixed with the DH result by TBD. Donald E. Eastlake, 3rd [Page 9] INTERNET-DRAFT The DNS TKEY RR October 19999 The inception and expiry times in the query TKEY 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. 3.3 Query for GSS-API Established This is described in a separate document [draft-skwan-gss-tsig-*.txt] which should be seen for the full description. Basically, when an acceptable symmetric key is not yet in place, the resolver can send a query for type TKEY with a TKEY specifying the GSS-API mode in the additional information section and a GSS-API token in the key data portion. The server responds with a TKEY specifying the GSS-API mode and a GSS-API token in the key data portion. The resolver and server feed these tokens to their local GSS implementation and iterate until an error is encountered or a key (GSS-API session) is established. A similar exchange can be used to delete a GSS-API session. Any issues of possible encryption of 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, signed with TSIG or SIG(0). The inception and expiry time in a GSS-API mode TKEY are ignored. 3.4 Query for Querier Assigned Keying Optionally, a server can accept resolver assigned keys. The keying material must be encrypted under a server host key for protection in transmission as described in Section 5. The resolver sends an update request to add a TKEY RR that specifies the keying data with a KEY RR in the additional information section specifying the server host public key used to encrypt the data. 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 server SHOULD require that this request be signed with a TSIG, if there already exists an appropriate shared secret, or a SIG(0) by the resolver host. 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. The query TKEY inception and expiry give the time period the querier intends to consider the keying material valid. The server can return Donald E. Eastlake, 3rd [Page 10] INTERNET-DRAFT The DNS TKEY RR October 19999 a lesser time interval to advise that it will not maintain state for that long. 3.5 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. The key expiration provided in the TKEY and the ability of each party to discard keys may be adequate but servers may implement key deletion whereby the server discards a key on receipt from a resolver of a delete request for a TKEY with the key's name. If the server has no record of a key with that name, it returns BADNAME. 4. 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 immediate error or success indication back and, in the case of UDP, no way to even know if the DNS response reached the resolver. 4.1 Spontaneous GSS-API Exchange A server can spontaneously include in the additional information section of a response, a GSS-API mode TKEY. 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 signed, the signature must verify before processing the data. To the extent that GSS-API provides its own security, such a response may not need to be signed. To the extent that GSS-API handles duplicated messages, such a spontaneous TKEY can be sent repeatedly, until, perhaps, a response via a GSS-API mode TKEY query is received. Donald E. Eastlake, 3rd [Page 11] INTERNET-DRAFT The DNS TKEY RR October 19999 4.2 Spontaneous Key Deletion A server can hint to 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 signed. If authenticated, it deletes the key with the given name. The inception and expiry times of the delete TKEY are ignored. Failure by a client to receive or properly process such additional information in a response would simply mean that the client might use a key that the server had discarded and then get an error indication. 5. Methods of Encryption For the server assigned and resolver assigned key exchange, 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]. The KEY RR MUST correspond to a name for the destination host such that the destination host has the corresponding private key to decrypt the data. The secret keying material being send 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. 6. 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 (and 1 through 5 are assigned by this Proposed Standard). Special consideration should be given before the allocation of meaning for Mode field values 0x0000 and 0xFFFF. Donald E. Eastlake, 3rd [Page 12] INTERNET-DRAFT The DNS TKEY RR October 19999 Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF are allocated by an IETF consensus. Mode field values 0x1000 through 0xEFFF are allocated based on RFC documentation of their use. Mode values should not be changed when the status of their use changes. I.E. a mode value assigned for an Experimental Standard should not be changed later just because that standard's status is changed to Proposed. 7. Security Considerations 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 MUST be done securely. TKEY queries SHOULD be signed and those using the querier establishment mode MUST be signed to authenticate their origin. However, for currently defined modes, relatively little damage will be done if an unsigned query of this sort is accepted and processed, as described above, for each mode. In addition, requiring that a TKEY query be signed by a TSIG (if there exists an acceptable exchanged key between the parties) or a SIG(0) may itself impose significant computational requirements on the server, particularly in verifying SIG(0) public key signatures. Responses to TKEY queries MUST always have DNS transaction signatures to protect the integrity of any keying data, error codes, etc. This signature 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. To avoid replay attacks, it is necessary that a response or querier establishment mode query involving TKEY not be valid if replayed on the order of 2**32 second (about 136 years) later. To acomplish 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. Thus, on attempted replay, the authenticating TSIG or SIG(0) RR will not be verifyable due to key expiration and the replay will fail. Donald E. Eastlake, 3rd [Page 13] INTERNET-DRAFT The DNS TKEY RR October 19999 Changes from Previous Draft Prohibit more than one TKEY in a request or response. Prohibit more than one key with the same name (even if they have non-overlapping validity periods). Spontaneous server inclusion of Diffi-Hellman TKEYs and server assigned key have been eliminated. "Update" opcode TKEY operations have all been moved to the "Query" opcode even if they are not something you would naturally think of as a query. Error codes for more error conditions listed explicitly. More explicit TKEY key naming suggestions. Donald E. Eastlake, 3rd [Page 14] INTERNET-DRAFT The DNS TKEY RR October 19999 References 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 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. [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996, John Wiley and Sons draft-ietf-dnssec-update2-*.txt - Donald E. Eastlake 3rd, "Secure Domain Name System Dynamic Update". draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". draft-skwan-gss-tsig-*.txt - S. Kwan, P. Garg, R. Viswanathan, "GSS Algorithm for TSIG (GSS-TSIG)" Donald E. Eastlake, 3rd [Page 15] INTERNET-DRAFT The DNS TKEY RR October 19999 Author's Address Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road, RR #1 Carmel, NY 10512 USA Telephone: +1 914-276-2668 (h) +1 914-784-7913 (w) FAX: +1 914-784-3833 (w) email: dee3@us.ibm.com Expiration and File Name This draft expires October 1999. Its file name is draft-ietf-dnsind-tkey-01.txt. Donald E. Eastlake, 3rd [Page 16]