Key Exchange Delegation Record for the DNS
draft-rfced-info-atkinson-00

Network Working Group                                    Randall Atkinson
Internet Draft                                                        NRL
draft-rfced-info-atkinson-00.txt                                June 1997

               Key Exchange Delegation Record for the DNS
                   <draft-rfced-info-atkinson-00.txt>
          

STATUS OF THIS MEMO
     This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas, and
   its working groups.  Note that other groups may also distribute working
   documents as Internet Drafts.

     Internet Drafts are draft documents valid for a maximum of 6 months.
   Internet Drafts may be updated, replaced, or obsoleted by other
   documents at any time.  It is not appropriate to use Internet Drafts as
   reference material or to cite them other than as "work in progress".

     This particular Internet Draft describes an extension to the Domain
   Name System that is in limited deployment in certain IP-based networks.
   It does not specify any level of standard and is not intended for
   the IETF standards-track.

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  [Atk95a,
   Atk95b, Atk95c] 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. [Mock87a,  Mock87b]
   More  recently,  Eastlake  and  Kaufman  have defined standards-track
   security extensions to the DNS. [EK97] These security extensions  can
   be  used to authenticate signed DNS data records and can also be used

Atkinson                  Expires in 6 months                   [Page 1]
Internet Draft               DNS KX Record                   26 May 1997

   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  reader  is assumed to be familiar with the basics of
   DNS, including familiarity with [Mock87a, Mock87b].  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.

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 <to be assigned by  IANA>.
   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.  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   [Atk95a].
   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 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.

           In this example, the decision to provide  the  IPsec  service
   for  traffic  from  R1  destined  for  R2 is made by R1.  Once R1 has
   decided that the packet to D  should  be  protected,  it  performs  a
   secure DNS lookup for the records associated with domain D.  If these
   records include a KX record for the  IPsec  service,  then  R1  knows
   which  set  of  nodes  are  possible  key  exchanger  nodes  for  the
   destination D.  In this example, let there be at least one KX  record

Atkinson                  Expires in 6 months                   [Page 2]
Internet Draft               DNS KX Record                   26 May 1997

   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 on behalf of S.
   R2  is  able  to  authenticate  the  delegation  of   Key   Exchanger
   authorisation  for  target  S  to  R1  by making an authenticated DNS
   lookup for KX records associated with S and verifying that  at  least
   one such record points to R1.

           If  the  key  exchanger  for  D   (in   this   example,   R2)
   authentically  informs  R1  via  the  key  management  that the IPsec
   Security Association should have source address of S,  proxy  address
   of  R1,  and  destination  address  of  R2,  then  R1 sets up such an
   association with R2 to protect traffic from S to  D.   Otherwise,  R1
   creates an IPsec Security Association for a secure tunnel with source
   address of S, proxy address of R1, and destination address of  D  via
   negotiation  with  D's  key  exchanger.   In  each case, the Security
   Association has a source identity that is either  (1)  S  or  (2)  an
   address  range  that  includes  S's address.  Once the IPsec Security
   Association has been created, then R1 uses it to protect traffic from
   S destined for D.  The destination identity is either (1) D or (2) an
   address range that includes the destination address.

2.1.2 Subnet-to-Host Example

           If D implements IPsec but S does not  implement  IPsec,  then
   things  are  more  interesting.  In this case, R1 determines that the
   security service is needed for the  packet.   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  domain  D
   pointing to domain D or from an authenticated DNS response indicating
   that no KX record  exists  for  domain  D.   R1  then  initiates  key
   management  with  D to create an IPsec Security Association on behalf
   of S.  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.  If there is no 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   accepted   and
   established, it has a source address of S, a proxy address of R1, and
   a destination address of D.  This IPsec Security  Association  has  a
   source  identity  that  is  either (1) S or (2) an address range that
   includes S's address and a destination identity that is either (1)  D
   or (2) an address range that includes D's address.

           Finally, R1 begins providing the security service for packets

Atkinson                  Expires in 6 months                   [Page 3]
Internet Draft               DNS KX Record                   26 May 1997

   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).  The same concept applies.  However,
   in this case, D determines that the security service  is  needed  for
   the  packets  to  S.  Then D performs the secure DNS lookup for S and
   discovers that a KX record for S exists and points  at  R1.   D  then
   initiates  key management with R1, where R1 is acting on behalf of S,
   to create an appropriate Security Association.

           If R1 indicates to  D  via  key  management  that  the  IPsec
   Security  Association  should  be  between  D  and R1, then the IPsec
   Security Association is setup  as  a  secure  tunnel  with  a  source
   address  of D, a destination address of R1, source identity of either
   (1) D or (2) an address range including D, and a destination identity
   of either (1) S or (2) an address range including S.

           Otherwise, the  IPsec  Security  Association  is  setup  with
   source  address  of  D,  destination address of S, source identity of
   either (1) D or (2) an address range including D, and  a  destination
   identity of either (1) S or (2) an address range including S.

           Finally, D  sends  secured  IP  packets  to  the  IPsec  SA's
   destination.   If  the  IPsec  SA destination is R1, then R1 receives
   those packets, provides IPsec input processing,  and  forwards  valid
   packets  along to S.  Again, authenticated DNS lookups for KX records
   is used to authenticate the delegation of Key Exchanger authority for
   a particular identity to a particular Key Exchanger node.

2.2 Other Examples

           This mechanism can be extended for use with other services as
   well.   For  example,  consider a destination node implementing IPsec
   that can only obtain its Security Association information from a  key
   distribution  center  (for  example, using Kerberos [KN93]).  If that
   node's key distribution center  implemented  key  management  gateway
   capabilities  that  could  negotiate  security  associations  using a
   different  key  management  protocol   (e.g.   ISAKMP),   then   that
   destination  node  might  have  a  KX  record  pointing  at  its  key
   distribution center.

Atkinson                  Expires in 6 months                   [Page 4]
Internet Draft               DNS KX Record                   26 May 1997

           In the event the initiator were not using  the  KDC  but  the
   target  was an IPsec node that only used the KDC, the initiator would
   find the KX record for the target pointing at  the  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 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 node that could only  use  the
   KDC.   The target could verify that the KDC were allowed to proxy for
   the node only using the KDC by looking up the  KX  records  for  that
   node  only  using  the  KDC  and  finding  a pointer to the KDC.  The
   external key exchange would be performed  between  the  KDC  and  the
   target.  Then the KDC would distribute the IPsec SA to the initiator.
   Again, IPsec traffic itself travels directly  between  the  initiator
   and the destination.

3. SYNTAX OF KX RECORD

     A KX record has the DNS TYPE of "KX" and a numeric value of <to  be
   assigned  by  IANA>.   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 be associated
   with either a Fully Qualified Domain  Name,  a  CNAME  record,  an  A
   record, or an AAAA record.

Atkinson                  Expires in 6 months                   [Page 5]
Internet Draft               DNS KX Record                   26 May 1997

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.

   KX records cause type A additional section processing  for  the  host
   specified by EXCHANGER.

4. SECURITY CONSIDERATIONS

           KX records MUST always be signed using the method(s)  defined
   by  the DNS Security extensions specified in [EK97].  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.

           Myriad serious security  vulnerabilities  can  arise  if  the
   above restrictions are not strictly adhered to.

5. REFERENCES

   [Atk95a] R. Atkinson, "IP Security Architecture", RFC-1825, August 1995.

   [Atk95b] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995.

Atkinson                  Expires in 6 months                   [Page 6]
Internet Draft               DNS KX Record                   26 May 1997

   [Atk95c] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827,
           August 1995.

   [EK97]  D. Eastlake, C. Kaufman, "Domain Name System Security Extensions",
           RFC-2065, 3 January 1997.

   [KN93]  J. Kohl & B. Neuman, "The Kerberos Network Authentication Service",
           RFC-1510, 10 September 1993.

   [Mock87a] P. Mockapetris, "Domain names - implementation and specification",
           RFC-1035, 1 November 1987.

   [Mock87b] P. Mockapetris, "Domain names - concepts and facilities",
           RFC-1036, 1 November 1987

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).

AUTHOR'S ADDRESS:

   Randall Atkinson
   Code 5544
   Naval Research Laboratory
   4555 Overlook Avenue, SW
   Washington, DC 20375-5337

   Email: rja@cs.nrl.navy.mil
   Telephone: (DSN) 354-8590

   --PART-BOUNDARY=.1970606161952.ZM10146.eos.home.net--

Atkinson                  Expires in 6 months                   [Page 7]

INTERNET-DRAFT               EXPIRES JANUARY 1997        INTERNET-DRAFT