rfc2230.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

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.