diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2230.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2230.txt | 619 |
1 files changed, 0 insertions, 619 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2230.txt b/contrib/bind9/doc/rfc/rfc2230.txt deleted file mode 100644 index 03995fe..0000000 --- a/contrib/bind9/doc/rfc/rfc2230.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -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] - |
