summaryrefslogtreecommitdiffstats
path: root/doc/rfc/rfc2230.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2230.txt')
-rw-r--r--doc/rfc/rfc2230.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2230.txt b/doc/rfc/rfc2230.txt
new file mode 100644
index 0000000..03995fe
--- /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]
+