Key Exchange Delegation Record for the DNS

Status of this Memo

Copyright Notice

Abstract

Contents

1. INTRODUCTION

The KX record is useful in providing an authenticatible method of delegating 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 be familiar with the basics of DNS, including familiarity with [RFC1035, RFC1034].  This document is not on the IETF standards-track and does not specify any level of standard. This document merely provides information for the Internet community.
 

1.1 Identity Terminology

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

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 IP address range. Also, for completeness, an IP Address identity is considered to dominate itself.

2. APPROACH

2.1 IPsec Examples

IETF-standard IP Security uses unidirectional Security Associations [RFC1825].  Therefore, a typical IP session will use a pair of related Security Associations, one in each direction.  The examples below talk about how to setup an example Security Association, but in practice a pair of matched Security Associations will normally be used.
 

2.1.1 Subnet-to-Subnet Example

         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 that the packet from S to D should be protected, it performs 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 will be necessary to determine the domain D, before that forward secure DNS lookup for records associated with domain D.  If these DNS records of domain D include a KX record for the IPsec service, then R1 knows which set of nodes are authorised key exchanger nodes for the destination D.

In this example, 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 obtained from the secure DNS.  Then R1 initiates a key management session with that key exchanger (in this example, R2) to setup an IPsec Security Association between R1 and D.  In this example, R1 knows (either by seeing an outbound packet arriving from S destined to D or via other methods) that S will be sending traffic to D.  In this example R1's policy requires that traffic from S to D should be segregated at least on a host-to-host basis, so R1 desires an IPsec Security Association with source identity that dominates S, proxy identity that dominates R1, and destination identity that dominates R2.

In turn, R2 is able to authenticate the delegation of Key Exchanger authorisation for target S to R1 by making an authenticated forward DNS lookup for KX records associated with S and verifying 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 will need to perform a secure reverse DNS lookup to obtain the fully-qualified domain name for S prior to 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 setup a separate (but related) IPsec Security Association for the return traffic.  That return IPsec Security Association will have equivalent identities.  In this example, that return IPsec Security Association will have 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, then R1 uses it to protect traffic from S destined for D via a secure tunnel that originates at R1 and terminates at R2.  For the case of unicast, R2 will use the return IPsec Security Association to protect traffic from D destined for S via a secure tunnel that originates at R2 and terminates at R1.
 

2.1.2 Subnet-to-Host Example

              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 performs the secure DNS lookup for D and determines that D is its own key exchanger, either from the existence of a KX record for D pointing to D or from an authenticated DNS response indicating that no KX record exists for D.  If R1 does not initially know the domain name of D, then prior to the above forward secure DNS lookup, R1 performs a secure reverse DNS lookup on the IP address of D to determine the fully-qualified domain name for that IP address.  R1 then initiates 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 performing a DNS KX record lookup for target S.  R1 usually provides identity S to D via key management.  If D only has the IP address of S, then D will need to perform a secure reverse lookup on the IP address of S to determine domain name S prior to 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, that IPsec Security Association 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 begins providing the security service for packets from S that transit R1 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 valid proxy address for that SA and that S is the source address for that SA.  Hence, 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

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

    Figure 3:  Network Diagram for Host-to-Subnet Example
 
 
In this example, D makes the policy decision that IP Security is needed for the packets from D to S.  Then D performs the secure DNS lookup for S and discovers that a KX record for S exists and points at R1.  If D only has the IP address of S, then it performs a secure reverse DNS lookup on the IP address of S prior to the forward secure DNS lookup for S.

D then initiates key management with R1, where R1 is acting on behalf of S, to create an appropriate Security Association.  Because D is acting as its own key exchanger, R1 does not need to perform a secure DNS lookup for KX records associated with D.

D and R1 then create an appropriate IPsec Security Security Association.  This IPsec Security Association is setup as 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 performs IPsec for itself, no proxy identity is needed in this IPsec 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 receives those packets, provides IPsec input processing (including appropriate inner/outer IP address validation), and forwards valid packets along to S.
 

2.2 Other Examples

2.2.1 KDC Examples

In the event the session initiator were not using the KDC but the session target was an IPsec node that only used the KDC, the initiator would find the KX record for the target pointing at the KDC.  Then, the external key management exchange (e.g. ISAKMP) would be between the initiator and the KDC.  Then the KDC would distribute the IPsec SA to the KDC-only IPsec node using the KDC.  The IPsec traffic itself could travel directly between the initiator and the destination node.

In the event the initiator node could only use the KDC and the target were not using the KDC, the initiator would send its request for a key to the KDC.  The KDC would then initiate an external key management exchange (e.g. ISAKMP) with a node that the target's KX record(s) pointed to, on behalf of the initiator node.

The target node could verify that the KDC were 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 listed the KDC.

Then the external key exchange would be performed between the KDC and the target node.  Then the KDC would distribute the resulting IPsec Security Association to the initiator.  Again, IPsec traffic itself could travel directly between the initiator and the destination.

2.2.2 Dial-Up Host Example

Consider the situation where each mobile node is dynamically assigned both a domain name and an IP address at the time that node dials into the network.  Let the policy require that each mobile node act as its own Key Exchanger.  In this case, it is important that dial-in nodes use addresses from one or more well known IP subnets or address pools edicated to dial-in access.  If that is true, then no KX record or other action is needed to ensure that each node will act as its own Key Exchanger because lack of a KX record indicates that the node is
its own Key Exchanger.

Consider the situation where the mobile node's domain name remains constant but its IP address changes.  Let the policy require that each mobile node act as its own Key Exchanger.  In this case, there might be operational problems when another node attempts to perform a secure reverse DNS lookup on the IP address to determine the corresponding 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 will need to be securely updated each time the node is assigned a new IP address.  There are no mechanisms for accomplishing this that are both IETF-standard and widely deployed as of the time this note was written.  Use of Dynamic
 
DNS Update without authentication is a significant security risk and hence is not recommended for this situation.
 

3. SYNTAX OF KX RECORD

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

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

Internet nodes about to initiate a key exchange with <domain-name 1> should instead contact <domain-name 2> to initiate the key exchange for a security service between the initiator and <domain-name 2>.  If more than one KX record exists for <domain-name 1>, then the <preference> field is used to indicate preference among the systems delegated to.  Lower values are preferred over higher values.  The <domain-name 2> is authorised to provide key exchange services on behalf of <domain-name 1>.  The <domain-name 2> MUST have a CNAME
record, an A record, or an AAAA record associated with it.
 

3.1 KX RDATA format

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

where:

PREFERENCE
A 16 bit non-negative integer which specifies the preference given to this RR among other KX records  at the same owner.  Lower values are preferred.

EXCHANGER
A <domain-name> which specifies 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.  In the event that 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

KX records MUST be ignored by systems not implementing Secure DNS because such systems have no mechanism to authenticate the KX record.

If a node does not have a permanent DNS entry and some form of Dynamic DNS Update is in use, then those dynamic DNS updates MUST be fully authenticated to prevent an adversary from injecting false DNS records (especially the KX, A, and PTR records) into the Domain Name System.  If false records were inserted into the DNS without being signed by the Secure DNS mechanisms, then a denial-of-service attack results.  If false records were inserted into the DNS and were (erroneously) signed by the signing authority, then an active attack results.

Myriad serious security vulnerabilities can arise if the restrictions throuhout this document are not strictly adhered to.  Implementers should carefully consider the openly published issues relating to DNS security [Bell95,Vixie95] as they build their implementations. Readers should also consider the security considerations discussed in the DNS Security Extensions document [RFC2065].
 

5. REFERENCES

ACKNOWLEDGEMENTS

AUTHOR'S ADDRESS

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

Full Copyright Statement

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published andand distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.  However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein 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.