diff options
Diffstat (limited to 'doc/rfc/rfc2230.txt')
| -rw-r--r-- | doc/rfc/rfc2230.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2230.txt b/doc/rfc/rfc2230.txt new file mode 100644 index 00000000..03995fe2 --- /dev/null +++ b/doc/rfc/rfc2230.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group R. Atkinson +Request for Comments: 2230 NRL +Category: Informational November 1997 + + + Key Exchange Delegation Record for the DNS + +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 Notice + + Copyright (C) The Internet Society (1997). All Rights Reserved. + +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 [RFC- + 1825, RFC-1826, RFC-1827] 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. [RFC-1035, RFC-1034] More + recently, Eastlake and Kaufman have defined standards-track security + extensions to the DNS. [RFC-2065] These security extensions can be + used to authenticate signed DNS data records and can also be used 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 + + + + + + + +Atkinson Informational [Page 1] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + + reader is assumed to be familiar with the basics of DNS, including + familiarity with [RFC-1035, RFC-1034]. 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 + + This document relies upon the concept of "identity domination". This + concept might be new to the reader and so is explained in this + section. The subject of endpoint naming for security associations + has historically been somewhat contentious. This document takes no + position on what forms of identity should be used. In a network, + there are several forms of identity that are possible. + + 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 + + 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 36. 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. S2 is another node on the same subnet as S. 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 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 + [RFC-1825]. 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 + + + +Atkinson Informational [Page 2] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + + 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. + + 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. + + + + + + +Atkinson Informational [Page 3] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + + 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 + + Consider the case where D and R1 implement IPsec, but S does not + implement IPsec, which is an interesting variation on the previous + example. This example is 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 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 + + + +Atkinson Informational [Page 4] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + + 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 + + Now consider the above case from D's perspective (i.e. where D is + sending IP packets to S). This variant is sometimes known as the + Mobile Host or "roadwarrier" case. The same basic concepts apply, but + the details are covered here in hope of improved clarity. + + S ---+ + | + +- R1 -----[zero or more routers]-------D + | + S2---+ + + Figure 3: Network Diagram for Host-to-Subnet Example + + + + + + +Atkinson Informational [Page 5] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + + 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 + + This mechanism can be extended for use with other services as well. + To give some insight into other possible uses, this section discusses + use of KX records in environments using a Key Distribution Center + (KDC), such as Kerberos [KN93], and a possible use of KX records in + conjunction with mobile nodes accessing the network via a dialup + service. + +2.2.1 KDC Examples + + This example considers the situation of a destination node + implementing IPsec that can only obtain its Security Association + information from a Key Distribution Center (KDC). Let the KDC + implement both the KDC protocol and also a non-KDC key management + protocol (e.g. ISAKMP). In such a case, each client node of the KDC + might have its own KX record pointing at the KDC so that nodes not + implementing the KDC protocol can still create Security Associations + with each of the client nodes of the KDC. + + 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 + + + +Atkinson Informational [Page 6] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + + 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 + + This example outlines a possible use of KX records with mobile hosts + that dial into the network via PPP and are dynamically assigned an IP + address and domain-name at dial-in time. + + 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 + dedicated 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 + + + +Atkinson Informational [Page 7] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + + DNS Update without authentication is a significant security risk and + hence 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. 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 have a CNAME + record, an A record, or an AAAA record associated with it. + +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. + + + + + +Atkinson Informational [Page 8] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + + 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 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 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. + + 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 [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. + + + + + + +Atkinson Informational [Page 9] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + + [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 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). In that + era, Dave Mihelcic and others provided detailed review and + constructive feedback. More recently, Bob Moscowitz and Todd Welch + provided detailed review and constructive feedback of 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 + + + + + + + +Atkinson Informational [Page 10] + +RFC 2230 DNS Key Exchange Delegation Record November 1997 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1997). All Rights Reserved. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + +Atkinson Informational [Page 11] + |