doc: Add RFC documents

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]
+