A Method for Storing IPsec Keying Material in DNS
Extracted elements (24)
IPSECKEY RRs are looked up primarily via reverse DNS (IN-ADDR.ARPA / IP6.ARPA) because security gateways often have only the IP address of the target and not a forward name. Forward-name lookup is supported but not required.
Multiple IPSECKEY records at the same owner name are expected—to represent multiple gateways and to support key rollover. The precedence field provides ordering among them.
RSA public keys in IPSECKEY have no length limit beyond the 65535-octet two-octet encoding ceiling, unlike the KEY RR limit of 4096 bits. This extension is intentionally scoped to IPSECKEY only, not KEY RRs, to allow for future larger key sizes in IPsec contexts.
The IPSECKEY RR replaces the functionality of KEY RR sub-type #4, which was obsoleted by RFC 3445. Public key encodings are inherited from the KEY RR format (algorithm-specific portion after the first four octets), ensuring consistency with existing DNSSEC algorithm definitions.
An IPSECKEY resource record SHOULD be used in combination with DNSSEC unless some other means of authenticating the IPSECKEY RR is available.
Any derivative specification that uses the IPSECKEY RR MUST carefully document its trust model and why DNSSEC's trust model is appropriate if DNSSEC is the secure channel used.
If the end-to-end integrity of the IPSECKEY RR is suspect, the end client MUST restrict use to cases where the RR owner name matches the content of the gateway field; records with a non-null gateway field obtained under unverified conditions MUST be ignored.
In the presentation format, if no gateway is to be indicated, the gateway type field MUST be zero and the gateway field MUST be '.'.
In the presentation format, the base64-encoded public key block is OPTIONAL; if absent, the public key field of the RR MUST be construed to be zero octets in length.
The gateway field domain name MUST NOT be compressed (gateway type 3). This applies in both wire format (Section 2.3) and gateway field encoding (Section 2.5).
When looking up IPSECKEY RRs via reverse DNS (IN-ADDR.ARPA or IP6.ARPA), any CNAMEs or DNAMEs encountered MUST be followed.
When the gateway type field is 3 (domain name) and the integrity of the subsequent address query is suspect, the IPSECKEY RR MUST be ignored whenever the resulting gateway does not match the QNAME of the original IPSECKEY RR query.
The IPSECKEY resource record (RR) is assigned DNS type number 45. It is used to publish a public key associated with a DNS name for use with IPsec, and may also indicate a gateway through which an IPsec tunnel should be established.
This document creates an IANA registry for the IPSECKEY gateway type field. Values 0, 1, 2, and 3 are defined; values 4–255 are assignable by Standards Action.
This document updates the IANA DNS Resource Record Types registry by assigning type number 45 to the IPSECKEY record.
An active attack replacing the gateway field to point to an attacker-controlled node is easier than replacing keying material because the attacker need not be on the forwarding path—only able to modify DNS replies (via packet modification, race attacks, or cache poisoning). This can enable a man-in-the-middle attack against both IKE and IPsec.
An active attack replacing the keying material requires a simultaneous man-in-the-middle attack on IKE/IPsec; without that, the result is denial of service (IKE negotiation failure) rather than session compromise.
The IPSECKEY RR contains keying material that SHOULD be delivered with integrity protection (e.g., DNSSEC, TSIG, SIG(0), or a secure local channel). The keying material itself is not sensitive to passive attacks and may be freely disclosed without compromising IPsec session security.
The algorithm type field is 8 bits: value 0 indicates no key present; value 1 indicates a DSA key in RFC 2536 format; value 2 indicates an RSA key in RFC 3110 format.
The gateway field encodes the IPsec tunnel endpoint: 32-bit IPv4 (network byte order) for type 1, 128-bit IPv6 (network byte order) for type 2, or wire-encoded domain name (compression MUST NOT be used) for type 3.
The gateway type field is 8 bits with defined values: 0 = no gateway present, 1 = 4-byte IPv4 address, 2 = 16-byte IPv6 address, 3 = wire-encoded domain name (self-describing length, MUST NOT be compressed).
The IPSECKEY RDATA consists of four fields in order: an 8-bit precedence, an 8-bit gateway type, an 8-bit algorithm type, a variable-length gateway field (0, 4, 16, or domain-name bytes depending on gateway type), followed by a variable-length public key field.
The precedence field is 8 bits and interpreted like the MX PREFERENCE field: lower values are attempted first, with ties broken non-deterministically.
The public key field contains the algorithm-specific portion of the KEY RR RDATA (everything after the first four octets). RSA keys have no length limit beyond the 65535-octet two-octet-length-encoding ceiling; this extension applies only to IPSECKEY, not KEY RRs.