Key Exchange Delegation Record for the DNS
draft-rfced-info-atkinson-00
This document is an Internet-Draft (I-D) that has been submitted to the Legacy stream.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 2230.
|
|
---|---|---|---|
Author | Ran Atkinson | ||
Last updated | 2013-03-02 (Latest revision 1997-07-09) | ||
RFC stream | Legacy | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Legacy state | (None) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Became RFC 2230 (Informational) | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-rfced-info-atkinson-00
Network Working Group Randall Atkinson Internet Draft NRL draft-rfced-info-atkinson-00.txt June 1997 Key Exchange Delegation Record for the DNS <draft-rfced-info-atkinson-00.txt> STATUS OF THIS MEMO This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". This particular Internet Draft describes an extension to the Domain Name System that is in limited deployment in certain IP-based networks. It does not specify any level of standard and is not intended for the IETF standards-track. ABSTRACT This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. It can be used with several security services. For example, a system seeking to use IP Security [Atk95a, Atk95b, Atk95c] to protect IP packets for a given destination can use this mechanism to determine the set of authorised remote key exchanger systems for that destination. 1. INTRODUCTION The Domain Name System (DNS) is the standard way that Internet nodes locate information about addresses, mail exchangers, and other data relating to remote Internet nodes. [Mock87a, Mock87b] More recently, Eastlake and Kaufman have defined standards-track security extensions to the DNS. [EK97] These security extensions can be used to authenticate signed DNS data records and can also be used Atkinson Expires in 6 months [Page 1] Internet Draft DNS KX Record 26 May 1997 to store signed public keys in the DNS. 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 [Mock87a, Mock87b]. 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. 2. APPROACH This document specifies a new kind of DNS Resource Record (RR), known as the Key Exchanger (KX) record. A Key Exchanger Record has the mnemonic "KX" and the type code of <to be assigned by IANA>. Each KX record is associated with a fully-qualified domain name. The KX record is modeled on the MX record described in [Part86]. Any given domain, subdomain, or host entry in the DNS might have a KX record. 2.1 IPsec Examples In these two examples, let S be the originating node and let D be the destination node. R1 and R2 are IPsec-capable routers. The path from S to D goes via first R1 and later R2. The return path from D to S goes via first R2 and later R1. IETF-standard IP Security uses unidirectional Security Associations [Atk95a]. 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 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. In this example, the decision to provide the IPsec service for traffic from R1 destined for R2 is made by R1. Once R1 has decided that the packet to D should be protected, it performs a secure DNS lookup for the records associated with domain D. If these records include a KX record for the IPsec service, then R1 knows which set of nodes are possible key exchanger nodes for the destination D. In this example, let there be at least one KX record Atkinson Expires in 6 months [Page 2] Internet Draft DNS KX Record 26 May 1997 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 on behalf of S. R2 is able to authenticate the delegation of Key Exchanger authorisation for target S to R1 by making an authenticated DNS lookup for KX records associated with S and verifying that at least one such record points to R1. If the key exchanger for D (in this example, R2) authentically informs R1 via the key management that the IPsec Security Association should have source address of S, proxy address of R1, and destination address of R2, then R1 sets up such an association with R2 to protect traffic from S to D. Otherwise, R1 creates an IPsec Security Association for a secure tunnel with source address of S, proxy address of R1, and destination address of D via negotiation with D's key exchanger. In each case, the Security Association has a source identity that is either (1) S or (2) an address range that includes S's address. Once the IPsec Security Association has been created, then R1 uses it to protect traffic from S destined for D. The destination identity is either (1) D or (2) an address range that includes the destination address. 2.1.2 Subnet-to-Host Example If D implements IPsec but S does not implement IPsec, then things are more interesting. In this case, R1 determines that the security service is needed for the packet. 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 domain D pointing to domain D or from an authenticated DNS response indicating that no KX record exists for domain D. R1 then initiates key management with D to create an IPsec Security Association on behalf of S. 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. If there is no 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 accepted and established, it has a source address of S, a proxy address of R1, and a destination address of D. This IPsec Security Association has a source identity that is either (1) S or (2) an address range that includes S's address and a destination identity that is either (1) D or (2) an address range that includes D's address. Finally, R1 begins providing the security service for packets Atkinson Expires in 6 months [Page 3] Internet Draft DNS KX Record 26 May 1997 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 Now consider the above case from D's perspective (i.e. where D is sending IP packets to S). The same concept applies. However, in this case, D determines that the security service is needed for the packets to S. Then D performs the secure DNS lookup for S and discovers that a KX record for S exists and points at R1. D then initiates key management with R1, where R1 is acting on behalf of S, to create an appropriate Security Association. If R1 indicates to D via key management that the IPsec Security Association should be between D and R1, then the IPsec Security Association is setup as a secure tunnel with a source address of D, a destination address of R1, source identity of either (1) D or (2) an address range including D, and a destination identity of either (1) S or (2) an address range including S. Otherwise, the IPsec Security Association is setup with source address of D, destination address of S, source identity of either (1) D or (2) an address range including D, and a destination identity of either (1) S or (2) an address range including S. Finally, D sends secured IP packets to the IPsec SA's destination. If the IPsec SA destination is R1, then R1 receives those packets, provides IPsec input processing, and forwards valid packets along to S. Again, authenticated DNS lookups for KX records is used to authenticate the delegation of Key Exchanger authority for a particular identity to a particular Key Exchanger node. 2.2 Other Examples This mechanism can be extended for use with other services as well. For example, consider a destination node implementing IPsec that can only obtain its Security Association information from a key distribution center (for example, using Kerberos [KN93]). If that node's key distribution center implemented key management gateway capabilities that could negotiate security associations using a different key management protocol (e.g. ISAKMP), then that destination node might have a KX record pointing at its key distribution center. Atkinson Expires in 6 months [Page 4] Internet Draft DNS KX Record 26 May 1997 In the event the initiator were not using the KDC but the 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 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 node that could only use the KDC. The target could verify that the KDC were allowed to proxy for the node only using the KDC by looking up the KX records for that node only using the KDC and finding a pointer to the KDC. The external key exchange would be performed between the KDC and the target. Then the KDC would distribute the IPsec SA to the initiator. Again, IPsec traffic itself travels directly between the initiator and the destination. 3. SYNTAX OF KX RECORD A KX record has the DNS TYPE of "KX" and a numeric value of <to be assigned by IANA>. A KX record is 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 has the following textual syntax: <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 be associated with either a Fully Qualified Domain Name, a CNAME record, an A record, or an AAAA record. Atkinson Expires in 6 months [Page 5] Internet Draft DNS KX Record 26 May 1997 3.1 KX RDATA format The KX DNS record has the following 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 cause type A additional section processing for the host specified by EXCHANGER. 4. SECURITY CONSIDERATIONS KX records MUST always be signed using the method(s) defined by the DNS Security extensions specified in [EK97]. All unsigned KX records MUST be ignored because of the security vulnerability caused by assuming that unsigned records are valid. All signed KX records whose signatures do not correctly validate MUST be ignored because of the potential security vulnerability in trusting an invalid KX record. KX records MUST be ignored by systems not implementing Secure DNS because such systems have no mechanism to authenticate the KX record. Myriad serious security vulnerabilities can arise if the above restrictions are not strictly adhered to. 5. REFERENCES [Atk95a] R. Atkinson, "IP Security Architecture", RFC-1825, August 1995. [Atk95b] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. Atkinson Expires in 6 months [Page 6] Internet Draft DNS KX Record 26 May 1997 [Atk95c] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827, August 1995. [EK97] D. Eastlake, C. Kaufman, "Domain Name System Security Extensions", RFC-2065, 3 January 1997. [KN93] J. Kohl & B. Neuman, "The Kerberos Network Authentication Service", RFC-1510, 10 September 1993. [Mock87a] P. Mockapetris, "Domain names - implementation and specification", RFC-1035, 1 November 1987. [Mock87b] P. Mockapetris, "Domain names - concepts and facilities", RFC-1036, 1 November 1987 ACKNOWLEDGEMENTS Development of this DNS record was primarily performed during 1993 through 1995. The author's work on this 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 Warface Systems Command (SPAWAR). AUTHOR'S ADDRESS: Randall Atkinson Code 5544 Naval Research Laboratory 4555 Overlook Avenue, SW Washington, DC 20375-5337 Email: rja@cs.nrl.navy.mil Telephone: (DSN) 354-8590 --PART-BOUNDARY=.1970606161952.ZM10146.eos.home.net-- Atkinson Expires in 6 months [Page 7] INTERNET-DRAFT EXPIRES JANUARY 1997 INTERNET-DRAFT