Secret Key Establishment for DNS (TKEY RR)
updated by
- rfc-6895 — Domain Name System (DNS) IANA Considerations
Extracted elements (28)
Certain TKEY modes (server assigned and resolver assigned) perform encryption of keying material, which may affect export or import status for some countries. This is why these modes are OPTIONAL while DH exchange, which does not encrypt transmitted data, is mandatory.
TKEY is a meta-RR that is not stored or cached in the DNS and does not appear in zone files. TKEY-established keys are associated with DNS servers or resolvers, not zones, so they cannot provide zone-based DNS data origin or denial authentication.
For querier-assigned and Diffie-Hellman keys, the server MUST truly discard all active state on deletion. For server-assigned keys, the server MAY simply mark the key as no longer retained and may re-send it in response to a future query.
The CLASS field in a TKEY RR is ignored and SHOULD be set to 255 (ANY) to maximize compatibility. The TTL field is also ignored. Older DNS implementations must not cache TKEY RRs, hence the requirement for TTL=0.
Type TKEY queries SHOULD NOT be flagged as recursive, and servers MAY ignore the recursive header bit in TKEY queries they receive.
A resolver query for DH-mode TKEY MUST include a KEY RR with the resolver's DH public key in the additional information section; the server response includes a server DH KEY RR so both sides can compute the shared secret.
At any DNS server or resolver, only one octet string of keying material may be in place for any particular key name. An attempt to establish another set of keying material for an existing name returns a BADNAME error.
Except for GSS-API mode, TKEY responses MUST always have DNS transaction authentication (TSIG or SIG(0)) to protect keying data and error codes. This authentication MUST NOT use any key that the response itself is providing.
For resolver-assigned keying, the keying material MUST be encrypted under a server public key (KEY RR) for protection in transmission. The KEY RR used MUST be one for which the server has the corresponding private key.
In server-assigned keying mode, the resolver KEY RR MUST be authenticated via TSIG, SIG(0), or a SIG(KEY); otherwise an attacker can forge a resolver KEY and obtain a valid shared secret from the server.
Resolver-assigned keying mode queries MUST be authenticated with a TSIG or SIG(0); without this, an attacker could forge a resolver-assigned TKEY query and install a shared secret key of their choosing.
Servers and resolvers MUST implement the Diffie-Hellman key agreement mode and the key deletion mode. A server supporting TKEY that receives a TKEY request with an unsupported mode MUST return the BADMODE error.
Servers MUST implement key deletion: upon receiving an authenticated delete request for a TKEY RR by name, the server discards the key. If no key with that name exists, the server returns BADNAME. Key deletion queries MUST be authenticated.
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.
The TTL field is meaningless in TKEY RRs and SHOULD always be zero to prevent older DNS implementations from caching TKEY RRs.
There MUST NOT be more than one TKEY RR in a DNS query or response.
Time synchronization used to align resolver and server interpretations of TKEY inception and expiration fields MUST be done securely; NTP (RFC 2030) is one acceptable method.
TKEY queries MUST be authenticated for all modes except GSS-API and certain server assignment cases. In the absence of required authentication, a NOTAUTH error MUST be returned.
For server-assigned and resolver-assigned modes, keying material is transmitted encrypted within the TKEY key data field using RSA (RSAES-PKCS1-v1_5 per PKCS#1 / RFC 2437). If keying material exceeds one RSA modulus, additional RSA encryption blocks are appended.
In Diffie-Hellman mode, the shared keying material is derived as: XOR(DH_value, MD5(query_data | DH_value) | MD5(server_data | DH_value)), where query_data and server_data are nonces from the respective TKEY RR key data fields, preventing two DH key pairs from always producing the same keying material.
In GSS-API mode, resolver and server exchange TKEY queries and responses with GSS-API tokens in the key data field. GSS-API handles its own encryption and authentication, so TSIG/SIG(0) authentication of the TKEY exchange is optional. Inception and expiry times in GSS-API TKEY RRs are ignored.
Spontaneous server inclusion allows a DNS server to include a TKEY RR in the additional information section of a response (e.g., to notify key deletion). This SHOULD only be done if the server knows the querier understands TKEY; there is no way to receive an acknowledgment, especially over UDP.
The Error field is an extended RCODE. Values 1-15 are non-extended RCODEs; 16=BADSIG, 17=BADKEY, 18=BADTIME (all TSIG), 19=BADMODE, 20=BADNAME, 21=BADALG. When non-zero in a TKEY response, the DNS header RCODE field indicates no error.
The Mode field specifies the key agreement scheme. Defined values are: 0 (reserved), 1 (server assignment), 2 (Diffie-Hellman exchange), 3 (GSS-API negotiation), 4 (resolver assignment), 5 (key deletion), 6-65534 (available), 65535 (reserved). Servers and resolvers MUST implement DH exchange (mode 2) and key deletion (mode 5); all others are OPTIONAL.
RFC 2930 registers RR type 249 for TKEY, TKEY Mode values 1-5 (server assignment, DH exchange, GSS-API, resolver assignment, key deletion), and extended RCODE error values 19 (BADMODE), 20 (BADNAME), and 21 (BADALG). Mode 0 and 65535 are reserved; modes 1-255 and 65280-65534 require IETF Standards Action.
The entirety of the TKEY specification is concerned with the secure establishment of a shared secret between DNS clients and servers in support of TSIG. Protection against denial of service via the use of TKEY is not provided.
To avoid replay attacks, keying material used in any TSIG or SIG(0) authenticating a TKEY message MUST NOT have a lifetime of more than 2**31 - 1 seconds (~68 years), ensuring replays fail due to key expiration.
The TKEY RR (type code 249) contains: NAME (domain), TTYPE (u_int16_t = 249), CLASS (u_int16_t, ignored), TTL (u_int32_t, ignored), RDLEN (u_int16_t), then RDATA comprising 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).