RFC 2230

Key Exchange Delegation Record for the DNS

📅 published November 1997, from ietf

RFC 2230: Key Exchange Delegation Record for the DNS 🎀

okay bestie, this is RFC 2230, and it's giving Informational energy 💅 It's by R. Atkinson from NRL 🦋, dated November 1997. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🌸

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1997). All Rights Reserved.

ABSTRACT 💜

okay so this note describes a mechanism where one node gets authorised to act as the key exchanger for a second node, and that delegation gets published through the Secure DNS 🔐 it's meant to be used only with the Secure DNS, but it can work with several security services ✨ for example, a system that wants to use IP Security [RFC-1825, RFC-1826, RFC-1827] to protect IP packets for a given destination can use this mechanism to figure out which remote key exchanger systems are authorised for that destination 🫶

1. INTRODUCTION ✨

bestie, the Domain Name System (DNS) is the standard way Internet nodes look up info about addresses, mail exchangers, and other data about remote Internet nodes 🍓 [RFC-1035, RFC-1034] more recently, Eastlake and Kaufman defined standards-track security extensions to the DNS 💅 [RFC-2065] those extensions can authenticate signed DNS data records, and they can also store signed public keys in the DNS 🔥

the KX record is super useful for an authenticatable way to delegate authorisation for one node to provide key exchange services on behalf of one or more, possibly different, nodes 🎀 this note specifies the syntax and semantics of the KX record, which is currently in limited deployment in certain IP-based networks 🦋 the reader is assumed to already know the basics of DNS, including [RFC-1035, RFC-1034] 💖 and tbh this document is not on the IETF standards-track and doesn't specify any level of standard. it just provides information for the Internet community 🌸

1.1 Identity Terminology 🧚

this doc relies on the concept of "identity domination" 👑 it might be new to you, so we explain it here 🙈 the topic of endpoint naming for security associations has historically been kinda contentious, and this document takes no position on what forms of identity should be used 💀 in a network there are several possible forms of identity ✨

for example, IP Security has defined identity notions that include: IP Address, IP Address Range, Connection ID, Fully-Qualified Domain Name (FQDN), and User with Fully Qualified Domain Name (USER FQDN) 💜

the way domination works: a USER FQDN identity dominates a FQDN identity 🫶 a FQDN identity in turn dominates an IP Address identity 🔥 similarly, a Connection ID dominates an IP Address identity ✨ an IP Address Range dominates each IP Address identity for each IP address within that range 🌈 and for completeness, an IP Address identity is considered to dominate itself 💅

2. APPROACH 🦋

this document specifies a new kind of DNS Resource Record (RR), called the Key Exchanger (KX) record 🎀 a Key Exchanger Record has the mnemonic "KX" and the type code of 36 ✨ each KX record is associated with a fully-qualified domain name 🌸 the KX record is modeled on the MX record described in [Part86] 💖 and any given domain, subdomain, or host entry in the DNS might have a KX record 🍓

2.1 IPsec Examples 🔐

okay so in these two examples, let S be the originating node and let D be the destination node 🧚 S2 is another node on the same subnet as S, and D2 is another node on the same subnet as D 💜 R1 and R2 are IPsec-capable routers 👑 the path from S to D goes via R1 first and later R2, and the return path from D to S goes via R2 first and later R1 🦋

IETF-standard IP Security uses unidirectional Security Associations [RFC-1825] 💅 so a typical IP session uses a pair of related Security Associations, one in each direction 🫶 the examples below talk about how to set up an example Security Association, but in practice a matched pair of Security Associations will normally be used 🔥

2.1.1 Subnet-to-Subnet Example 🌈

literally the simplest version: if neither S nor D implements IPsec, security can still be provided between R1 and R2 by building a secure tunnel 🎀 this can use either AH or ESP ✨

    S ---+                                          +----D
         |                                          |
         +- R1 -----[zero or more routers]-------R2-+
         |                                          |
    S2---+                                          +----D2

    Figure 1:  Network Diagram for Subnet-to-Subnet Example

in this example, R1 makes the policy decision to provide the IPsec service for traffic from R1 destined for R2 🌸 once R1 has decided the packet from S to D should be protected, it does a secure DNS lookup for the records associated with domain D 💖 if R1 only knows the IP address for D, then a secure reverse DNS lookup is needed first to figure out domain D, before that forward secure DNS lookup for the records of domain D 🍓 if those DNS records include a KX record for the IPsec service, then R1 knows which set of nodes are the authorised key exchanger nodes for destination D 🔐

so let there be at least one KX record for D, and let the most preferred KX record for D point at R2 🧚 R1 then selects a key exchanger (in this example, R2) for D from the list it got from the secure DNS 💜 then R1 starts a key management session with that key exchanger (R2 again) to set up an IPsec Security Association between R1 and D 👑 in this example, R1 knows (either by seeing an outbound packet from S destined to D or via other methods) that S will be sending traffic to D 🦋 R1's policy says traffic from S to D should be segregated at least on a host-to-host basis, so R1 wants an IPsec Security Association with a source identity that dominates S, a proxy identity that dominates R1, and a destination identity that dominates R2 💅

in turn, R2 can authenticate the delegation of Key Exchanger authorisation for target S to R1 🫶 it does this by making an authenticated forward DNS lookup for KX records associated with S and checking that at least one such record points to R1 🔥 the identity S is typically given to R2 as part of the key management process between R1 and R2 ✨

if D initially only knows the IP address of S, then it needs a secure reverse DNS lookup to get the fully-qualified domain name for S before that secure forward DNS lookup 🌈

if R2 does not receive an authenticated DNS response indicating that R1 is an authorised key exchanger for S, then D will not accept the SA negotiation from R1 on behalf of identity S 🙈

if the proposed IPsec Security Association is acceptable to both R1 and R2, each of which might have separate policies, then they create that IPsec Security Association via Key Management 🎀

note that for unicast traffic, Key Management will typically also set up a separate (but related) IPsec Security Association for the return traffic 💖 that return Security Association has equivalent identities. in this example, it has a source identity that dominates D, a proxy identity that dominates R2, and a destination identity that dominates R1 🍓

once the IPsec Security Association has been created, R1 uses it to protect traffic from S destined for D via a secure tunnel that starts at R1 and ends at R2 🔐 and for the case of unicast, R2 uses the return IPsec Security Association to protect traffic from D destined for S via a secure tunnel that starts at R2 and ends at R1 🧚

2.1.2 Subnet-to-Host Example 💜

this one is giving variation 👑 consider the case where D and R1 implement IPsec, but S does not implement IPsec, which is an interesting twist on the previous example 🦋 it's shown in Figure 2 below 💅

    S ---+
         |
         +- R1 -----[zero or more routers]-------D
         |
    S2---+

    Figure 2:  Network Diagram for Subnet-to-Host Example

in this example, R1 makes the policy decision that IP Security is needed for the packet travelling from S to D 🫶 then R1 does the secure DNS lookup for D and figures out that D is its own key exchanger 🔥 it can tell that either from a KX record for D pointing to D, or from an authenticated DNS response indicating that no KX record exists for D ✨ if R1 doesn't initially know the domain name of D, then before that forward secure DNS lookup, R1 does a secure reverse DNS lookup on the IP address of D to get its fully-qualified domain name 🌈 then R1 starts key management with D to create an IPsec Security Association on behalf of S 🎀

in turn, D can verify that R1 is authorised to create an IPsec Security Association on behalf of S by doing a DNS KX record lookup for target S 💖 R1 usually gives identity S to D via key management 🍓 if D only has the IP address of S, then D needs a secure reverse lookup on that IP address to find domain name S before the secure forward DNS lookup on S to locate the KX records for S 🔐

if D does not receive an authenticated DNS response indicating that R1 is an authorised key exchanger for S, then D will not accept the SA negotiation from R1 on behalf of identity S 🧚

if the IPsec Security Association is successfully established between R1 and D, it has a source identity that dominates S's IP address, a proxy identity that dominates R1's IP address, and a destination identity that dominates D's IP address 💜

finally, R1 starts providing the security service for packets from S that transit R1 and are destined for D 👑 when D receives such packets, D examines the SA information during IPsec input processing and sees that R1's address is listed as a valid proxy address for that SA and that S is the source address for that SA 🦋 so D knows at input processing time that R1 is authorised to provide security on behalf of S 💅 therefore, packets coming from R1 with valid IP security that claim to be from S are trusted by D to have really come from S 🫶✨

2.1.3 Host to Subnet Example

Okay, now let's look at this from D's side, where D is the one sending IP packets to S 📬✨ This is sometimes called the Mobile Host or "roadwarrier" case 🧳🚗. The same basic ideas apply, but I'm walking through the details again so it's extra clear 🎀

    S ---+
         |
         +- R1 -----[zero or more routers]-------D
         |
    S2---+

Figure 3: Network Diagram for Host-to-Subnet Example

Here, D decides that IP Security is needed for the packets going from D to S 🔐 Then D does a secure DNS lookup for S and finds a KX record for S that points at R1 🎯 If D only has S's IP address, it does a secure reverse DNS lookup on that address first, and only then does the forward secure DNS lookup for S 🔍💅

Next, D starts key management with R1, since R1 is acting on behalf of S, to set up a proper Security Association 🤝 Since D is acting as its own key exchanger, R1 doesn't need to do a secure DNS lookup for KX records tied to D 🙌

D and R1 then build an appropriate IPsec Security Association 🔒 This one is a secure tunnel with a source identity that dominates D's IP Address and a destination identity that dominates R1's IP Address 💖 Because D does IPsec for itself, no proxy identity is needed in this Security Association. If the proxy identity is non-null in this situation, then the proxy identity must dominate D's IP Address 🧚

Finally, D sends secured IP packets to R1 📦 R1 gets them, runs IPsec input processing (including the right inner/outer IP address validation), and forwards the valid packets along to S 🦋✨

2.2 Other Examples

This mechanism can be stretched to work with other services too 🌈 To give you some ideas, this section talks about KX records in environments that use a Key Distribution Center (KDC), such as Kerberos [KN93], and a possible use of KX records alongside mobile nodes that access the network through a dialup service 📞💜

2.2.1 KDC Examples

Picture a destination node that runs IPsec but can only get its Security Association information from a Key Distribution Center (KDC) 🏰 Let's say the KDC runs both the KDC protocol and a non-KDC key management protocol (for example, ISAKMP) 👑 In that setup, each client node of the KDC could have its own KX record pointing at the KDC, so that nodes which don't implement the KDC protocol can still create Security Associations with each of the KDC's clients 🫶

Now, what if the session initiator isn't using the KDC, but the session target is an IPsec node that only uses the KDC? 🤔 The initiator would find the KX record for the target pointing at the KDC. Then the external key management exchange (for example, ISAKMP) happens between the initiator and the KDC. After that, the KDC distributes the IPsec SA to the KDC-only IPsec node using the KDC itself 🔑 The IPsec traffic can still travel directly between the initiator and the destination node 🏃‍♀️💨

What if the initiator can only use the KDC, and the target isn't using the KDC? Then the initiator sends its request for a key to the KDC 📨 The KDC starts an external key management exchange (for example, ISAKMP) with a node that the target's KX record(s) point to, acting on behalf of the initiator node 🎀

The target node can check that the KDC is allowed to proxy for the initiator node by looking up the KX records for the initiator node and finding a KX record for the initiator that lists the KDC 🕵️‍♀️✅

Then the external key exchange gets done between the KDC and the target node 🔄 The KDC hands the resulting IPsec Security Association over to the initiator. Again, the IPsec traffic can travel directly between the initiator and the destination 🦋

2.2.2 Dial-Up Host Example

This example shows one possible way to use KX records with mobile hosts that dial into the network via PPP and get dynamically assigned an IP address and domain name at dial-in time 📱💫

Picture this: each mobile node gets both a domain name and an IP address the moment it dials in 🌸 Let's say the policy requires each mobile node to act as its own Key Exchanger. In that case, it matters that dial-in nodes use addresses from one or more well-known IP subnets or address pools that are dedicated to dial-in access 💅 If that's true, then no KX record or other action is needed to make sure each node acts as its own Key Exchanger, because a lack of a KX record tells you the node is its own Key Exchanger ✨

Now picture a mobile node whose domain name stays the same but whose IP address keeps changing 🔁 Again, the policy requires each mobile node to act as its own Key Exchanger. Here, things can get messy when another node tries a secure reverse DNS lookup on the IP address to find the matching domain name 😭 The authenticated DNS binding (in the form of a PTR record) between the mobile node's currently assigned IP address and its permanent domain name has to be securely updated every single time the node gets a new IP address 🫠 As of when this note was written, there are no mechanisms for doing that which are both IETF-standard and widely deployed 🙈 And using Dynamic DNS Update without authentication is a significant security risk, so it is not recommended for this situation 🚨

3. SYNTAX OF KX RECORD

A KX record has the DNS TYPE of "KX" and a numeric value of 36 🔢 It's a member of the Internet ("IN") CLASS in the DNS 🌐 Each KX record is associated with a <domain-name> entry in the DNS 🎀 A KX record uses this textual syntax:

     <domain-name>  IN  KX  <preference> <domain-name>

For this description, the <domain-name> item to the left of the "KX" string is called <domain-name 1>, and the <domain-name> item to the right of the "KX" string is called <domain-name 2> 🧩 <preference> is a non-negative integer 💜

Internet nodes that are about to start a key exchange with <domain-name 1> should instead contact <domain-name 2> to start the key exchange for a security service between the initiator and <domain-name 2> 🤝 If there's more than one KX record for <domain-name 1>, the <preference> field decides the order of the systems delegated to 🥇 Lower values are preferred over higher values ⬇️ <domain-name 2> is authorised to provide key exchange services on behalf of <domain-name 1> 👑 <domain-name 2> MUST have a CNAME record, an A record, or an AAAA record associated with it 💖

3.1 KX RDATA format

The KX DNS record has this RDATA format 📐

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                  PREFERENCE                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   EXCHANGER                   /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Here's what each part means 🧁

  • PREFERENCE: A 16 bit non-negative integer that sets the preference given to this RR among other KX records at the same owner. Lower values are preferred.
  • EXCHANGER: A <domain-name> that names a host willing to act as a mail exchange for the owner name.

KX records MUST cause type A additional section processing for the host specified by EXCHANGER 🎯 And if the host processing the DNS transaction supports IPv6, KX records MUST also cause type AAAA additional section processing ✨

The KX RDATA field MUST NOT be compressed 🚫🗜️

4. SECURITY CONSIDERATIONS 🔐💀

This section is serious business, bestie 😤

KX records MUST always be signed using the method(s) defined by the DNS Security extensions specified in [RFC-2065] 🖊️ All unsigned KX records MUST be ignored, because assuming unsigned records are valid is a security vulnerability 🙅‍♀️ All signed KX records whose signatures don't correctly validate MUST be ignored too, because trusting an invalid KX record is a potential security vulnerability 🚫

KX records MUST be ignored by systems that don't implement Secure DNS, because those systems have no way to authenticate the KX record 🛑

If a node doesn't have a permanent DNS entry and some form of Dynamic DNS Update is in use, those dynamic DNS updates MUST be fully authenticated 🔏 Otherwise an adversary could inject false DNS records (especially the KX, A, and PTR records) into the Domain Name System 😱 If false records get inserted into the DNS without being signed by the Secure DNS mechanisms, a denial-of-service attack results 🌧️ If false records get inserted into the DNS and are (erroneously) signed by the signing authority, an active attack results 💥

Myriad serious security vulnerabilities can come up if the restrictions throughout this document aren't strictly followed 🥺 Implementers should carefully consider the openly published issues about DNS security [Bell95,Vixie95] as they build their implementations 📚 Readers should also consider the security considerations discussed in the DNS Security Extensions document [RFC-2065] 🎀

5. REFERENCES 📖

  • [RFC-1825] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
  • [RFC-1827] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
  • [Bell95] Bellovin, S., "Using the Domain Name System for System Break-ins", Proceedings of 5th USENIX UNIX Security Symposium, USENIX Association, Berkeley, CA, June 1995. ftp://ftp.research.att.com/dist/smb/dnshack.ps
  • [RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
  • [RFC-1510] Kohl J., and C. Neuman, "The Kerberos Network Authentication Service", RFC 1510, September 1993.
  • [RFC-1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of the 5th USENIX UNIX Security Symposium, USENIX Association, Berkeley, CA, June 1995. ftp://ftp.vix.com/pri/vixie/bindsec.psf

ACKNOWLEDGEMENTS 🌷

Development of this DNS record was mainly done during 1993 through 1995 💕 The author's work on it was sponsored jointly by the Computing Systems Technology Office (CSTO) of the Advanced Research Projects Agency (ARPA) and by the Information Security Program Office (PD71E), Space & Naval Warfare Systems Command (SPAWAR) 🫶 Back in that era, Dave Mihelcic and others gave detailed review and constructive feedback 🙌 More recently, Bob Moscowitz and Todd Welch gave detailed review and constructive feedback on a work-in-progress version of this document 🌟

AUTHOR'S ADDRESS 📮

Randall Atkinson
Code 5544
Naval Research Laboratory
4555 Overlook Avenue, SW
Washington, DC 20375-5337

Phone: (DSN) 354-8590
EMail: atkinson@itd.nrl.navy.mil

Copyright (C) The Internet Society (1997). All Rights Reserved. 🎀

Okay, so this document and translations of it can be copied and handed out to others 🦋. Derivative works that comment on it, explain it, or help with implementing it can be prepared, copied, published, and distributed, in whole or in part, with no restriction of any kind 🌈. The only catch is that the above copyright notice and this paragraph have to be included on all those copies and derivative works 🫶.

BUT the document itself may not be modified in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations 🙈. The exceptions are developing Internet standards, where the copyright procedures in the Internet Standards process must be followed, and translating it into languages other than English 🌸.

The limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them 💜.

This document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

📦 where this page comes from