]> Independent

2386 Panoramic Circle Apopka Florida 32703 USA +1-508-333-2270 d3e3e3@gmail.com

Internet Systems Consortium

marka@isc.org

Operations DNSOP RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930.

Introduction [[[ NOTE: This draft contains occasional meta comments inside triple square brackets like this. These are intended to aid in the development of the document and would not appear in any resulting RFC. ]]] The Domain Name System (DNS) is a hierarchical, distributed, highly available database used for bi-directional mapping between domain names and IP addresses, for email routing, service access, and for other information . It has been extended to provide for public key-based data authentication and dynamic update . Familiarity with these RFCs is assumed. provides efficient authentication of DNS messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR) but provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used to establish and delete such shared secret keys between a DNS resolver and server. This document obsoletes and the significant changes from that RFC are list in . TKEY established keying materials and TSIGs that use them are associated with DNS servers and resolvers. They are not associated with DNS zones. They may be used to authenticate requests and transactions but they do not provide zone-based DNS RR data origin or denial of existence authentication .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. General familiarity with DNS terminology is assumed in this document. In all cases herein, the term "resolver" or "requester" includes that part of a server which may initiate requests including full and incremental zone transfer queries, forwarded recursive queries, and the like. For a message to be "silently ignored" means that is has no protocol effect but it might still be logged or reported.

General TKEY Considerations TKEY is a meta-RR that is not stored or cached and does not appear in zone master files. It supports a variety of modes for the establishment and deletion of shared secret keying information between DNS resolvers and servers. The shared secret keying material agreed to by using TKEY is an opaque octet sequence. The establishment of such a shared secret requires that state be maintained at both ends and the allocation of the resources to maintain such state generally requires prior mutual agreement. In the absence of willingness to provide such state, servers MUST return error NotImp or Refused for an attempt to use TKEY and resolvers are free to silently ignore any TKEY RRs they receive. TKEY RRs are sent in the additional information section of DNS queries for type TKEY and the corresponding returned TKEY appears in the answer section of responses to such queries. Some TKEY RRs may also be spontaneously included in other responses (see ). Type TKEY queries SHOULD NOT be flagged as recursive, and servers MUST ignore the recursion desired header bit (RD) in TKEY queries they receive. Type TKEY responses SHOULD be flagged as authoritative, and resolvers MUST ignore the authoritative answer (AA) bit in TKEY responses they receive. TKEY queries contain 1 question section entry with QTYPE TKEY, QCLASS 255 (ANY), and QNAME the same as the name of the TKEY RR. [[[ Comment: Although current practice is to have the query QNAME be the same as the name field of the TKEY RR, this does not appear to be logically necessary. Space could be saved by using root as the QNAME. ]]] TKEY messages (DNS queries and responses) MUST be authenticated (see ) for all modes except GSS-API mode, which provides its own security. In the absence of required TKEY authentication, a NotAuth error MUST be returned for a query and a reply MUST be silently ignored. Keys established via TKEY can be treated as soft state and need not be preserved over crashes or reboots. 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 TKEY Resource Record The TKEY resource record (RR) is a meta-RR that has the structure shown in Table 1. Its RR type code is 249. TKEY Resource Record

Field	Format	Comment
NAME	domain	See description below.
TTYPE	u_int16_t	TKEY, MUST be 249 (0x00F9).
CLASS	u_int16_t	MUST be 255 (ANY, 0x00FF).
TTL	u_int32_t	MUST be zero.
RDLEN	u_int16_t	Size of RDATA.
RDATA:
Algorithm:	domain name
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

Further information on these fields is provided in the subsections below. There MUST NOT be more than one TKEY RR in a DNS message. If more than one appears in a request, a server implementing TKEY MUST return FormErr. If more than one appears in a response, they MUST all be ignored. [[[ Comment: Actually, it could be meaningful to have multiple TKEY RRs in a DNS message as long as no pair conflicted. For example, a reply could contain a key agreement TKEY RR in the answer section along with one or more key deletion TKEY RRs for other keys in the additional information section. But it seems simpler to prohibit such messages. ]]]

Name Field The Name field is a DNS domain name in wire encoding format. It relates to naming keys and does not normally appear as a node in the DNS name hierarchy. It MUST NOT be compressed. Its meaning differs somewhat with mode and context as explained in . In some cases where the Name field has a key name, it would be the same name as used in a TSIG RR using that key. [[[ Comment: The only reason the above specifies that Name not be compressed is that there was a DNS implementation where such compression would activate a bug. This was not required in and can probably be changed to allow compression of the TKEY RR Name since RR QNAMEs are normally compressible. It is domain names appearing within the TKEY RDATA, such as the Algorithm field, that are not generally compressible. ]]] Although the DNS protocol is binary clean so that any octet value should be usable in a label that is part of a domain name, to avoid possible implementation bugs and to ease user interface and debugging issues, it is RECOMMENDED that Name be composed of labels consisting of letters, digits, underscore, and hyphen and that these labels begin with a letter or digit. To indicate that no Name is present, the Name field is set to the wire encoding of the domain name of the root node, that is, the octet string consisting of a single zero value octet. For more information on Key Names, see .

The TTL Field The TTL field is not used in TKEY RRs. It MUST be zero to minimize the chance that a DNS implementation might not recognizing a TKEY RR as a meta-RR and would erroneously cache it. Receipt of a TKEY RR with a non-zero TTL field in a query results in a FormErr error response.

The RDLEN Field The RDLEN field MUST equal the length of the RDATA section through the end of Other Data. Otherwise, the RR is to be considered malformed and FormErr returned if in a request or the message ignored if it is a reply.

The Algorithm Field The Algorithm name is a domain name with the same values and meaning as the Algorithm Name field in TSIG RRs (see ). It MUST NOT be compressed. The algorithm determines how keying material agreed to by using the TKEY RR is actually used to derive the algorithm specific secret key or keys. For example, it might need to be truncated or extended or split into multiple keys or otherwise processed.

The Inception and Expiration Fields The Expiration and Inception field values specify a date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC ignoring leap seconds, in network byte order, modulo 2**32 using ring arithmetic , similar to the fields with these names in the RRSIG RR . In TKEY DNS messages where these fields are meaningful, their meaning depends on the mode. Where the Inception and Expiration fields indicate a time interval, if the expiration time is before the inception time in a request, the BADTTIME error is returned in the Error field of the response. 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 Network Time Protocol . That or other time synchronization used for this purpose MUST be done securely.

The Mode Field The mode field specifies the general purpose of the TKEY RR, such as a key agreement method. See for more information on the modes specified in this document.

The Error Field The error code field is an extended RCODE . In queries, it MUST be sent as zero and ignored on receipt. The following values, which may appear in replies, are used and/or specified in this document or : Error Codes

Value	Description	Reference
0	- no error
1	FormErr
4	NotImp
5	Refused
9	NotAuth
16	BADSIG
17	BADKEY
18	BADTIME
19	BADMODE	[this document]
20	BADNAME	[this document]

When the TKEY RR Error Field is non-zero in a response to a TKEY query, the DNS header RCODE field normally indicates no error. However, it is possible, if a TKEY RR is spontaneously included in a response (see ), the TKEY RR and DNS header error fields could have unrelated non-zero error codes.

The Key Size and Data Fields The Key Size Field is an unsigned 16-bit integer in network octet order. It specifies the size of the Key Data Field in octets. The meaning of the contents of the Key Data field depends on the mode and context.

The Other Size and Data Fields The Other Size field is an unsigned 16-bit integer in network order which specifies the size of the Other Data field in octets. The Other Data field is intended for future expansion of the TKEY RR.

Key Naming and Key Table DNS resolvers and servers that implement TSIG maintain a table of (1) keying material shared with other DNS servers and resolvers with which they have either been configured or successfully exchanged TKEY RRs to establish such keys and (2) information about on going attempts to establish such shared keys using TKEY. Each local table entry logically contains the information listed below. The actual structure and management of this table is a local matter as long as the behavior is consistent this document. For example, it might be accessed through one or more hash tables for rapid retrieval or have additional information such as when a key was established or be broken up into more than one table that are linked together. Some fields in this table are further described in the subsections below the table. Key Table Entry

Field	Format	Explanation
Key Name	domain name	Key name.
Remote Address	IPv4/IPv6 address	Address of remote DNS server/resolver.
Inception	u_int32_t	Keying information inception time.
Expiration	u_int32_t	Keying information expiration time.
Key	octet-string	The opaque shared secret keying information.
State	unspecified	See below.
Algorithm	domain name	Key use algorithm.
Last Used	u_int32_t	The time at which a TSIG using this key was most recently sent or received and validated.

Key Name At any DNS server or resolver only one octet string of keying material and TSIG algorithm may be in place for any particular key name. An attempt to establish agreement for a different set of keying material for an existing name returns a BADNAME error. Since a DNS TKEY reply message could be lost, it is a normal case and not an error for a server to receive a TKEY request message to establish a key that is the same as a key that the server state indicates is already established. To avoid confusion while managing or debugging a network, it is RECOMMENDED that key names be globally unique. A key name generation strategy for resolvers and servers is described below.

A Resolver Key Name Generation Strategy For a TKEY RR with a non-root Name appearing in a query, the TKEY Name field SHOULD be a domain name locally unique at the querier, less than 128 octets long in wire encoding, and meaningful to the resolver to assist in distinguishing keys and/or key agreement sessions. This length limit is suggested so that, when a resolver provided name portion is concatenated with a server provided name portion, the result will fit within the DNS protocol wire encoding name length limit of 255 octets.

A Server Key Name Generation Strategy For a TKEY RR appearing in a response to a query, the TKEY RR Name field SHOULD be a globally unique server assigned name unless the response indicates a TKEY error in which case the name from the query SHOULD be copied in the response. A reasonable server key name generation strategy is as follows:

• If the key is generated by a server 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. A suggested method is prefixing a domain name of the server with a pseudo-random label having at least 128 bits of entropy using the "file name safe" Base 64 encoding (Section 5 of ). For example, a8s9ZW_n3mDgokX072pp3.serv1.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 at DNS server start time, such as 1234.a8s9ZW_n3mDgokX072pp3.serv1.example.com, with a new pseudo-random portion being generated periodically and on reboot.
• If the key is generated as the result of a query with a non-root name, say 789.resolv.example, then use the concatenation of that name, after deletion of its terminal root label, with a name of the server. For example, 789.resolv.example.serv1.example.com.

In the unlikely event that the unique TKEY NAME produced by whatever strategy is in use exceeds the wire encoding size limit of 255 octets, it may be shortened to fit within that limit with only an insignificant probability of losing uniqueness by replacing an initial portion of the excessively long name with the shorter encoding of a strong hash of that initial portion. For example, cut the excessively long name between labels so that the right part is no longer than 206 octets in wire encoding. Then take the prefix label or labels constituting the left part, apply SHA-256 to them treated as a name in wire encoding, truncate the resulting hash to 30 octets, base32 encode the result of that truncation yielding 48 octets, and add the output of the base32 encoding as a new single prefix label.

Remote Address This is the address of the remote DNS server or resolver with which the key is shared or is to be shared. It MUST be possible to have table entries for more than one key for such a remote server or resolver so that, for example, a new key can be established before a key in use expires or is disabled.

State This field is intended to encode an indication of the mode used in setting the key, whether the local DNS processor was filling the role of a resolver or server in the TKEY message exchange, and the status of any in progress key negotiation. The details of this field's value are implementation dependent.

Last Used This is the time signed from the most recent DNS message TSIG received and validated or sent using this Key using the same encoding as the inception and expiration TKEY fields. This field might be used to discard keys based on the least recently used or the like.

TKEY Modes The following subsections describe the TKEY modes that are specified in this document and the messages used for each mode. Servers and resolvers supporting this specification MUST implement the ECDH (6) mode (see ), Key Deletion (5) mode (see ), and TKEY Ping (8) (see ) mode. Diffie-Hellman (2) mode is NOT RECOMMENDED. Resolver Assignment (4) and Server Assignment (1) modes SHOULD NOT be implemented and by definition Documentation (7) mode MUST NOT be implemented. A server supporting TKEY that receives a TKEY request with a mode it does not support MUST return the BADMODE error.

Key Agreement Modes A resolver and a server can agree on shared secret keying material for use in TSIG through DNS requests from the resolver which are syntactically DNS queries for type TKEY and answering responses from the server. Such queries MUST have a TKEY RR in the additional information section and the response MUST have a TKEY RR in the answer section to indicate the mode in use and containing other information where required by that mode. The query and response MUST be authenticated (see ) except when GSS-API mode () is used. The inception and expiration time in TKEY RRs with a mode intended to result in key agreement refer to a secret key validity interval, except in the case of GSS-API mode (see ). The inception and expiration times in the query TKEY RR are those requested for the keying material. The inception and expiration times in the key agreement response TKEY RRs are the period the server intends to consider the keying material valid which may be a sub-interval or overlapping interval of the query specified time interval. Servers may expire keys early, so this is not a guarantee. If the expiration time in the resolver query is in the past or if it is before the inception time, a BADTIME error MUST be returned. If the inception time in the resolver query is in the future, indicating an attempt to agree on a future key, a BADTIME error MAY be returned by the server.

ECDH Exchanged Keying (Mode 6) Elliptic Curve Diffie-Hellman (ECDH) key exchange is a means whereby two parties can derive shared secret information without requiring secrecy of the messages they exchange . To use this mode, there need to be compatible elliptic curve public keys for the resolver and server involved . However, there could be multiple keys available for each of them. The purpose of the TKEY message exchange is to select the elliptic key to be used for the resolver and the elliptic key to be used for the server, to provide nonce information, and to establish the key name and associated key value and TSIG algorithm for the resulting shared key. A resolver sends a query for type TKEY accompanied by a TKEY RR in the additional information section specifying the ECDH exchange mode and accompanied by a KEY RR also in the additional information section specifying a resolver elliptic curve key. The TKEY RR algorithm field is set to the authentication algorithm the resolver plans to use in any TSIG RRs using the resulting key. Any "key data" provided in the TKEY in the query is used as a random nonce to avoid always deriving the same keying material for the same pair of KEY RRs. The server response contains a TKEY in its answer section with the ECDH assignment mode and echoes back the algorithm field from the query. If there is "key data" provided in this server TKEY, it is used as an additional nonce to avoid always deriving the same keying material for the same pair of KEY RRs but an anycast group of servers is only supported if such data is the same for all servers in that group. If the TKEY error field is non-zero, the query failed for the reason given. FORMERR is given if the query included no elliptic curve KEY. BADKEY is given if the query included an incompatible elliptic curve KEY. If the response TKEY error field is zero, a server elliptic KEY RR MUST be present in the answer section of the response. The resolver supplied elliptic curve KEY RR SHOULD be echoed in the additional information section. Both parties then calculate the same shared secret quantity from the pair of elliptic curve KEY RRs used (provided they are compatible) and the data in the TKEY RRs using HKDF as follows where "|" indicates concatenation and the string in double quotes indicates the octet string of the ASCII for that character string without any terminating zero octet or leading length octet or surrounding quotes: IKM = shared secret from ECDH with resolver and server keys salt = resolver-TKEY-data | server-TKEY-data info = "IETF-TKEY-ECDH" OKM = HKDF-Expand(HMAC-Hash(salt, IKM), info, L) SHA-256 is used in the HMAC-Hash . L is the length of the keying material needed for use in the Algorithm specified. and OKM is the output keying material to use with TSIG.

Server Assigned Keying (Mode 1, Deprecated) A mode was specified in the previous to this document whereby a server can assign keying to be shared with the resolver. So far as is known, this mode was never implemented and SHOULD NOT be implemented now. It is not specified in this document.

Resolver Assigned Keying (Mode 4, Deprecated) A mode was specified in the previous to this document whereby a server can accept a resolver assigned key. So far as is known, this mode was never implemented and SHOULD NOT be implemented now. It is not specified in this document.

GSS-API Establishment (Mode 3) This mode is described in "Generic Security Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)" which should be consulted 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. 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 does not need to be, authenticated with a TSIG RR or SIG(0) RR . The inception and expiration times in a GSS-API mode TKEY RR are ignored.

Diffie-Hellman Exchanged Keying (Mode 2, Deprecated) The use of Diffie-Hellman Exchanged Keying mode is NOT RECOMMENDED for the reasons given in Appendix A which also contains the specification for that mode for compatibility with old TKEY implementations. Use of ECDH Exchanged Keying is RECOMMENDED as an alternative (see ).

Other Modes The TKEY modes specified in the subsections below do not provide for agreement on a key but provide other functions.

TKEY Deletion (Mode 5) To avoid attempted reliance in requests on keys no longer in effect, servers MUST implement TKEY Deletion mode whereby the server "discards" a key on receipt from a resolver of an authenticated TKEY Deletion mode TKEY RR with that key's name. To be effective, the TKEY MUST also have an inception time no later than the inception of the key to be deleted and an expiration time no earlier than the expiration time of the key to be deleted. This time restriction is intended to minimize potential insecurities due to replaying deletion mode TKEY RRs. If the server has no record of a key with that name, it returns BADNAME in the TKEY Error field in the reply. This error condition may be due to the server having discarded the key. If it has a key with that name but with a validity period extending outside that in the deletion request, it returns a BADTIME error. Key deletion TKEY queries MUST be authenticated (see ). This authentication MAY be a TSIG RR using the key to be deleted. For ECDH or Diffie-Hellman keys, the server SHOULD discard all active state associated with the key name in its key table. Keys may also be deleted through spontaneous inclusion of a deletion mode TKEY RR in a response as specified in .

TKEY Ping (Mode 8) The TKEY Ping Mode is intended for use as a test of basic TKEY plumbing and to check the synchronization of the resolver and server clocks. It also provides a means for a resolver to determine if TKEY is implemented at a server without changing the key storage state. In a TKEY Ping mode query, the Name and Algorithm fields SHOULD be set to root to save space and are ignored by the server. The Inception field MUST be set to the time the query is constructed according to the resolver's clock. The Expiration field MUST be set to zero in a query and is ignored on receipt. A resolver MAY include a sequence number or identification information or whatever else it might find useful in the Key field. And the Other Data field SHOULD be sent empty and ignored by the server. A server implementing TKEY responds with a Ping Mode TKEY RR in the answer section of its response copied from the query except that it MUST set the Expiration field to the value of the server's clock when the reply is constructed even if the response also indicated an error such as BADTIME.

Documentation Mode (Mode 7) This mode is assigned as a TKEY Mode to use in examples or documentation. A server responds with BADMODE as the TKEY error if it receives a TKEY RR indicating this mode. Mode 7 will never be assigned any other use.

Spontaneous Server Inclusion A DNS server MAY include a deletion mode (mode 5) TKEY RR spontaneously in the additional information portion of any DNS query response. To avoid confusion, this SHOULD NOT be done unless the server has reason to believe that the resolver supports TKEY and SHOULD only be done if the server has deleted the corresponding secret key. This technique may be specified or allowed for modes other than deletion 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 transport, no way to even know if the DNS response reached the resolver. Such a response MUST be authenticated for the TKEY to be effective. If it is not authenticated, the resolver should ignore any included TKEY RR. 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 in a TSIG and would then get an error indication.

TKEY Message Authentication Unless otherwise specified, all TKEY queries and responses MUST be authenticated. A server receiving a TKEY query that is not authenticated but needs to be authenticated returns a NotAuth error in the returned TKEY Error field. A resolver receiving a TKEY reply that needs to be authenticated but is not authenticated silently ignores the TKEY RR. 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 than 2**31 - 1 seconds (about 68 years). Thus, on attempted replay, the authenticating TSIG or SIG(0) RR would not be verifiable due to key expiration and a replay would fail. There are two methods of authentication as specified below.

Secret Key Authentication If a shared secret key is in place between the resolver and server, then TKEY queries and response can be authenticated with TSIG . So, for example, an existing shared secret key could be used to authenticate a TKEY exchange that sets up a new key before rolling over to that new key.

Public Key Authentication As an alternative to secret key authentication, public key authentication can be used with the SIG(0) RR as specified in .

IANA Considerations This section is to be interpreted as provided in .

Reference Update IANA is requested to update all reference to in the DNS Parameters Registry Group to reference [this document].

Existing Assignments The following assignments have already been made:

• RR Type 249 for TKEY.
• Extended RCODE Error values of 19, 20, and 21 as listed in .

TSIG/TKEY Registry Group IANA is requested to rename the existing "Secret Key Transaction Authentication for DNS (TSIG) Algorithm Names" registry to be the "DNS TSIG and TKEY Parameters" registry group and include within it the existing "TSIG Algorithm Names" registry and the new registry created below.

TKEY Modes Registry IANA is requested to create a "TKEY Modes" Registry as follows: Name: TKEY Modes Reference: [this document] Registration Procedures: 0x0000 - reserved 0x0001-0x0FFF - standards action 0x1000-0xFFEF - specification required 0xFFF0-0xFFFE - experimental use 0xFFFF - reserved Initial contents as follows:

Value	Description	Implementation	Reference
0x0000	- reserved	-
0x0001	Server Assignment	SHOULD NOT	, [this document]
0x0002	Diffie-Hellman exchange	SHOULD NOT	Appendix A, [this document]
0x0003	GSS-API Negotiation	MAY	, [this document]
0x0004	Resolver Assignment	SHOULD NOT	, [this document]
0x0005	Key Deletion	MUST	, [this document]
0x0006	ECDH Agreement	MUST	[this document]
0x0007	Documentation/example	N/A	, [this document]
0x0008	TKEY Ping	MUST	, [this document]
0x0009-0x0FFF	- unassigned	-
0x1000-0xFFEF	- unassigned	-
0xFFF0-0xFFFE	- experimental use	-
0xFFFF	- reserved	-

Security Considerations This specification is concerned with the secure establishment of shared secret keys between DNS clients and servers in support of TSIG . Secret keys agreed to using TKEY and the private keys corresponding to the public key belonging to DNS resolvers and servers are very sensitive information. All practical steps should be taken to protect them on every host on which they are stored. Generally, such hosts need to be physically protected. If they are shared machines, great care should be taken so that unprivileged processes have no access to keying material. Resolvers sometimes run unprivileged, which means all users of a host might be able to see whatever configuration data are used by the resolver unless appropriate steps are taken to prevent this. Protection against denial of service via the use of TKEY is not provided. DNS servers and resolve should implement appropriate rate limiting. More TBD

Normative References Swedish Internet Foundation

johan.stenstam@internetstiftelsen.se

Informative References

Diffie-Hellman Exchanged Keying Details TKEY Mode 2, Diffie-Hellman Exchanged Keying, is deprecated for the reasons given below. It SHOULD NOT be used unless needed for compatibility with old TKEY implementations.

1. The mixing function used does not meet current cryptographic standards because it uses MD5 .
2. The ad hoc method of combining the DH derived shared value with various nonces is inferior to the HKDF method used with the ECDH TKEY mode specified in this document.

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 . When this mode was originally specified, it was assumed that RSA public/private keys would be used. Provisions have been made for the storage of "DH" (RSA) public keys in the DNS . 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 public 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 nonce to avoid always deriving the same keying material 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 response TKEY error field is zero, the resolver supplied KEY RR SHOULD be echoed in the additional information section and a server Diffie-Hellman KEY RR MUST be present in the answer section of the response. Both parties can then calculate the same shared secret quantity from the pair of public keys used (provided these keys are compatible) 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 the bitwise exclusive-OR operation and "|" is octet-string concatenation. The shorter of the two operands to XOR is octet-wise left justified and padded with zero-valued octets 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 expiration times in the query TKEY RR are those requested for the keying material. The inception and expiration 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.

Changes from This document incorporates the following significant changes from :

• Addition of the ECDH Key Agreement mode (#6), the Documentation mode (#7), and the TKEY Ping mode (#8).
• Deprecation of Diffie-Hellman Exchanged Keying (mode #2).
• Deprecation of and dropping of the specifications for Server Assignment mode (#1) and Resolver Assignment (#4) node.
• Additional material including that concerned with authentication of TKEY RRs.
• Editorial changes including some re-organization.

Acknowledgements The comments and suggestions of the following are gratefully acknowledged: tbd The comments and suggestions of the following persons were incorporated into RFC 2930, which was the previous version of this document, and are gratefully acknowledged: Olafur Gudmundsson, Stuart Kwan, Ed Lewis, Erik Nordmark, and Brian Wellington.