home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-atkinson-00.txt < prev    next >
Text File  |  1997-07-09  |  17KB  |  392 lines
  1.  
  2. Network Working Group                                    Randall Atkinson
  3. Internet Draft                                                        NRL
  4. draft-rfced-info-atkinson-00.txt                                June 1997
  5.  
  6.  
  7.  
  8.  
  9.                Key Exchange Delegation Record for the DNS
  10.                    <draft-rfced-info-atkinson-00.txt>
  11.           
  12.  
  13.  
  14.  
  15. STATUS OF THIS MEMO
  16.      This document is an Internet Draft.  Internet Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its Areas, and
  18.    its working groups.  Note that other groups may also distribute working
  19.    documents as Internet Drafts.
  20.  
  21.      Internet Drafts are draft documents valid for a maximum of 6 months.
  22.    Internet Drafts may be updated, replaced, or obsoleted by other
  23.    documents at any time.  It is not appropriate to use Internet Drafts as
  24.    reference material or to cite them other than as "work in progress".
  25.  
  26.      This particular Internet Draft describes an extension to the Domain
  27.    Name System that is in limited deployment in certain IP-based networks.
  28.    It does not specify any level of standard and is not intended for
  29.    the IETF standards-track.
  30.  
  31. ABSTRACT
  32.  
  33.            This note describes a mechanism whereby authorisation for one
  34.    node  to act as key exchanger for a second node is delegated and made
  35.    available via the Secure DNS.  This mechanism is intended to be  used
  36.    only  with  the  Secure  DNS.   It  can be used with several security
  37.    services.  For example, a system seeking to use IP Security  [Atk95a,
  38.    Atk95b, Atk95c] to protect IP packets for a given destination can use
  39.    this  mechanism  to  determine  the  set  of  authorised  remote  key
  40.    exchanger systems for that destination.
  41.  
  42. 1. INTRODUCTION
  43.  
  44.            The Domain  Name  System  (DNS)  is  the  standard  way  that
  45.    Internet  nodes  locate information about addresses, mail exchangers,
  46.    and other data relating to remote Internet nodes. [Mock87a,  Mock87b]
  47.    More  recently,  Eastlake  and  Kaufman  have defined standards-track
  48.    security extensions to the DNS. [EK97] These security extensions  can
  49.    be  used to authenticate signed DNS data records and can also be used
  50.  
  51.  
  52.  
  53. Atkinson                  Expires in 6 months                   [Page 1]
  54.  
  55. Internet Draft               DNS KX Record                   26 May 1997
  56.  
  57.  
  58.    to store signed public keys in the DNS.
  59.  
  60.            The KX record  is  useful  in  providing  an  authenticatible
  61.    method  of  delegating  authorisation  for  one  node  to provide key
  62.    exchange services on behalf  of  one  or  more,  possibly  different,
  63.    nodes.   This  note  specifies  the  syntax  and  semantics of the KX
  64.    record, which is currently in limited deployment in certain  IP-based
  65.    networks.   The  reader  is assumed to be familiar with the basics of
  66.    DNS, including familiarity with [Mock87a, Mock87b].  This document is
  67.    not  on  the  IETF  standards-track and does not specify any level of
  68.    standard.  This document merely provides information for the Internet
  69.    community.
  70.  
  71. 2. APPROACH
  72.  
  73.            This document specifies a new kind  of  DNS  Resource  Record
  74.    (RR), known as the Key Exchanger (KX) record.  A Key Exchanger Record
  75.    has the mnemonic "KX" and the type code of <to be assigned by  IANA>.
  76.    Each KX record is associated with a fully-qualified domain name.  The
  77.    KX record is modeled on the MX  record  described  in  [Part86].  Any
  78.    given  domain,  subdomain,  or  host entry in the DNS might have a KX
  79.    record.
  80.  
  81. 2.1 IPsec Examples
  82.  
  83.            In these two examples, let S be the originating node and  let
  84.    D be the destination node.  R1 and R2 are IPsec-capable routers.  The
  85.    path from S to D goes via first R1 and later  R2.   The  return  path
  86.    from  D  to  S  goes  via  first  R2  and later R1.  IETF-standard IP
  87.    Security  uses   unidirectional   Security   Associations   [Atk95a].
  88.    Therefore,  a  typical IP session will use a pair of related Security
  89.    Associations, one in each direction.  The examples below  talk  about
  90.    how  to setup an example Security Association, but in practice a pair
  91.    of matched Security Associations will normally be used.
  92.  
  93. 2.1.1 Subnet-to-Subnet Example
  94.  
  95.            If neither S nor D implements IPsec, security  can  still  be
  96.    provided between R1 and R2 by building a secure tunnel.  This can use
  97.    either AH or ESP.
  98.  
  99.            In this example, the decision to provide  the  IPsec  service
  100.    for  traffic  from  R1  destined  for  R2 is made by R1.  Once R1 has
  101.    decided that the packet to D  should  be  protected,  it  performs  a
  102.    secure DNS lookup for the records associated with domain D.  If these
  103.    records include a KX record for the  IPsec  service,  then  R1  knows
  104.    which  set  of  nodes  are  possible  key  exchanger  nodes  for  the
  105.    destination D.  In this example, let there be at least one KX  record
  106.  
  107.  
  108.  
  109. Atkinson                  Expires in 6 months                   [Page 2]
  110.  
  111. Internet Draft               DNS KX Record                   26 May 1997
  112.  
  113.  
  114.    for  D  and  let  the most preferred KX record for D point at R2.  R1
  115.    then selects a key exchanger (in this example, R2)  for  D  from  the
  116.    list  obtained  from  the  secure  DNS.   Then  R1  initiates  a  key
  117.    management session with that key exchanger (in this example,  R2)  to
  118.    setup  an IPsec Security Association between R1 and D on behalf of S.
  119.    R2  is  able  to  authenticate  the  delegation  of   Key   Exchanger
  120.    authorisation  for  target  S  to  R1  by making an authenticated DNS
  121.    lookup for KX records associated with S and verifying that  at  least
  122.    one such record points to R1.
  123.  
  124.            If  the  key  exchanger  for  D   (in   this   example,   R2)
  125.    authentically  informs  R1  via  the  key  management  that the IPsec
  126.    Security Association should have source address of S,  proxy  address
  127.    of  R1,  and  destination  address  of  R2,  then  R1 sets up such an
  128.    association with R2 to protect traffic from S to  D.   Otherwise,  R1
  129.    creates an IPsec Security Association for a secure tunnel with source
  130.    address of S, proxy address of R1, and destination address of  D  via
  131.    negotiation  with  D's  key  exchanger.   In  each case, the Security
  132.    Association has a source identity that is either  (1)  S  or  (2)  an
  133.    address  range  that  includes  S's address.  Once the IPsec Security
  134.    Association has been created, then R1 uses it to protect traffic from
  135.    S destined for D.  The destination identity is either (1) D or (2) an
  136.    address range that includes the destination address.
  137.  
  138. 2.1.2 Subnet-to-Host Example
  139.  
  140.            If D implements IPsec but S does not  implement  IPsec,  then
  141.    things  are  more  interesting.  In this case, R1 determines that the
  142.    security service is needed for the  packet.   Then  R1  performs  the
  143.    secure  DNS  lookup  for  D  and  determines  that  D  is its own key
  144.    exchanger either from the existence of  a  KX  record  for  domain  D
  145.    pointing to domain D or from an authenticated DNS response indicating
  146.    that no KX record  exists  for  domain  D.   R1  then  initiates  key
  147.    management  with  D to create an IPsec Security Association on behalf
  148.    of S.  D can verify that R1 is authorised to create an IPsec Security
  149.    Association  on  behalf of S by performing a DNS KX record lookup for
  150.    target S.  If there is no authenticated DNS response indicating  that
  151.    R1  is  an authorised key exchanger for S, then D will not accept the
  152.    SA negotiation from R1 on behalf of identity S.
  153.  
  154.            If  the  IPsec   Security   Association   is   accepted   and
  155.    established, it has a source address of S, a proxy address of R1, and
  156.    a destination address of D.  This IPsec Security  Association  has  a
  157.    source  identity  that  is  either (1) S or (2) an address range that
  158.    includes S's address and a destination identity that is either (1)  D
  159.    or (2) an address range that includes D's address.
  160.  
  161.            Finally, R1 begins providing the security service for packets
  162.  
  163.  
  164.  
  165. Atkinson                  Expires in 6 months                   [Page 3]
  166.  
  167. Internet Draft               DNS KX Record                   26 May 1997
  168.  
  169.  
  170.    from S that transit R1 destined for D.  When D receives such packets,
  171.    D examines the SA information during IPsec input processing and  sees
  172.    that  R1's  address  is listed as valid proxy address for that SA and
  173.    that S is the source address for that SA.  Hence, D  knows  at  input
  174.    processing  time  that R1 is authorised to provide security on behalf
  175.    of S.  Therefore packets coming from R1 with valid IP  security  that
  176.    claim to be from S are trusted by D to have really come from S.
  177.  
  178. 2.1.3 Host to Subnet Example
  179.  
  180.            Now consider the above case from D's perspective (i.e.  where
  181.    D  is  sending IP packets to S).  The same concept applies.  However,
  182.    in this case, D determines that the security service  is  needed  for
  183.    the  packets  to  S.  Then D performs the secure DNS lookup for S and
  184.    discovers that a KX record for S exists and points  at  R1.   D  then
  185.    initiates  key management with R1, where R1 is acting on behalf of S,
  186.    to create an appropriate Security Association.
  187.  
  188.            If R1 indicates to  D  via  key  management  that  the  IPsec
  189.    Security  Association  should  be  between  D  and R1, then the IPsec
  190.    Security Association is setup  as  a  secure  tunnel  with  a  source
  191.    address  of D, a destination address of R1, source identity of either
  192.    (1) D or (2) an address range including D, and a destination identity
  193.    of either (1) S or (2) an address range including S.
  194.  
  195.            Otherwise, the  IPsec  Security  Association  is  setup  with
  196.    source  address  of  D,  destination address of S, source identity of
  197.    either (1) D or (2) an address range including D, and  a  destination
  198.    identity of either (1) S or (2) an address range including S.
  199.  
  200.            Finally, D  sends  secured  IP  packets  to  the  IPsec  SA's
  201.    destination.   If  the  IPsec  SA destination is R1, then R1 receives
  202.    those packets, provides IPsec input processing,  and  forwards  valid
  203.    packets  along to S.  Again, authenticated DNS lookups for KX records
  204.    is used to authenticate the delegation of Key Exchanger authority for
  205.    a particular identity to a particular Key Exchanger node.
  206.  
  207. 2.2 Other Examples
  208.  
  209.            This mechanism can be extended for use with other services as
  210.    well.   For  example,  consider a destination node implementing IPsec
  211.    that can only obtain its Security Association information from a  key
  212.    distribution  center  (for  example, using Kerberos [KN93]).  If that
  213.    node's key distribution center  implemented  key  management  gateway
  214.    capabilities  that  could  negotiate  security  associations  using a
  215.    different  key  management  protocol   (e.g.   ISAKMP),   then   that
  216.    destination  node  might  have  a  KX  record  pointing  at  its  key
  217.    distribution center.
  218.  
  219.  
  220.  
  221. Atkinson                  Expires in 6 months                   [Page 4]
  222.  
  223. Internet Draft               DNS KX Record                   26 May 1997
  224.  
  225.  
  226.            In the event the initiator were not using  the  KDC  but  the
  227.    target  was an IPsec node that only used the KDC, the initiator would
  228.    find the KX record for the target pointing at  the  KDC.   Then,  the
  229.    external  key  management exchange (e.g. ISAKMP) would be between the
  230.    initiator and the KDC.  Then the KDC would distribute the IPsec SA to
  231.    the  KDC-only  IPsec  node  using  the KDC.  The IPsec traffic itself
  232.    could travel directly between the initiator and the destination node.
  233.  
  234.      In the event the initiator could only use the KDC  and  the  target
  235.    were  not  using  the KDC, the initiator would send its request for a
  236.    key to the  KDC.   The  KDC  would  then  initiate  an  external  key
  237.    management  exchange  (e.g.  ISAKMP) with a node that the target's KX
  238.    record(s) pointed to, on behalf of the node that could only  use  the
  239.    KDC.   The target could verify that the KDC were allowed to proxy for
  240.    the node only using the KDC by looking up the  KX  records  for  that
  241.    node  only  using  the  KDC  and  finding  a pointer to the KDC.  The
  242.    external key exchange would be performed  between  the  KDC  and  the
  243.    target.  Then the KDC would distribute the IPsec SA to the initiator.
  244.    Again, IPsec traffic itself travels directly  between  the  initiator
  245.    and the destination.
  246.  
  247. 3. SYNTAX OF KX RECORD
  248.  
  249.      A KX record has the DNS TYPE of "KX" and a numeric value of <to  be
  250.    assigned  by  IANA>.   A KX record is a member of the Internet ("IN")
  251.    CLASS in the DNS.  Each KX record is associated with a  <domain-name>
  252.    entry in the DNS.  A KX record has the following textual syntax:
  253.  
  254.            <domain-name>  IN  KX  <preference> <domain-name>
  255.  
  256.      For this description, let the <domain-name> item to the left of the
  257.    "KX"  string  be called <domain-name 1> and the <domain-name> item to
  258.    the right of the "KX" string be called <domain-name 2>.  <preference>
  259.    is a non-negative integer.
  260.  
  261.      Internet nodes about to initiate a key exchange  with  <domain-name
  262.    1>  should  instead  contact  <domain-name  2>  to  initiate  the key
  263.    exchange for a security service between the  initiator  and  <domain-
  264.    name 2>.  If more than one KX record exists for <domain-name 1>, then
  265.    the <preference> field is  used  to  indicate  preference  among  the
  266.    systems delegated to.  Lower values are preferred over higher values.
  267.    The <domain-name 2> is authorised to provide key exchange services on
  268.    behalf  of  <domain-name  1>.  The <domain-name 2> MUST be associated
  269.    with either a Fully Qualified Domain  Name,  a  CNAME  record,  an  A
  270.    record, or an AAAA record.
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277. Atkinson                  Expires in 6 months                   [Page 5]
  278.  
  279. Internet Draft               DNS KX Record                   26 May 1997
  280.  
  281.  
  282. 3.1 KX RDATA format
  283.  
  284.      The KX DNS record has the following RDATA format:
  285.  
  286.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  287.        |                  PREFERENCE                   |
  288.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  289.        /                   EXCHANGER                   /
  290.        /                                               /
  291.        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  292.  
  293.    where:
  294.  
  295.    PREFERENCE      A 16 bit non-negative integer which specifies the
  296.                    preference given to this RR among other KX records
  297.                    at the same owner.  Lower values are preferred.
  298.  
  299.    EXCHANGER       A <domain-name> which specifies a host willing to act as
  300.                    a mail exchange for the owner name.
  301.  
  302.  
  303.    KX records cause type A additional section processing  for  the  host
  304.    specified by EXCHANGER.
  305.  
  306.  
  307. 4. SECURITY CONSIDERATIONS
  308.  
  309.            KX records MUST always be signed using the method(s)  defined
  310.    by  the DNS Security extensions specified in [EK97].  All unsigned KX
  311.    records MUST be ignored because of the security vulnerability  caused
  312.    by  assuming  that unsigned records are valid.  All signed KX records
  313.    whose signatures do not correctly validate MUST be ignored because of
  314.    the  potential  security  vulnerability  in  trusting  an  invalid KX
  315.    record.
  316.  
  317.            KX records MUST be ignored by systems not implementing Secure
  318.    DNS  because  such  systems  have no mechanism to authenticate the KX
  319.    record.
  320.  
  321.            Myriad serious security  vulnerabilities  can  arise  if  the
  322.    above restrictions are not strictly adhered to.
  323.  
  324. 5. REFERENCES
  325.  
  326.    [Atk95a] R. Atkinson, "IP Security Architecture", RFC-1825, August 1995.
  327.  
  328.    [Atk95b] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995.
  329.  
  330.  
  331.  
  332.  
  333. Atkinson                  Expires in 6 months                   [Page 6]
  334.  
  335. Internet Draft               DNS KX Record                   26 May 1997
  336.  
  337.  
  338.    [Atk95c] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827,
  339.            August 1995.
  340.  
  341.    [EK97]  D. Eastlake, C. Kaufman, "Domain Name System Security Extensions",
  342.            RFC-2065, 3 January 1997.
  343.  
  344.    [KN93]  J. Kohl & B. Neuman, "The Kerberos Network Authentication Service",
  345.            RFC-1510, 10 September 1993.
  346.  
  347.    [Mock87a] P. Mockapetris, "Domain names - implementation and specification",
  348.            RFC-1035, 1 November 1987.
  349.  
  350.    [Mock87b] P. Mockapetris, "Domain names - concepts and facilities",
  351.            RFC-1036, 1 November 1987
  352.  
  353.  
  354. ACKNOWLEDGEMENTS
  355.  
  356.            Development of this DNS record was primarily performed during
  357.    1993  through  1995.  The author's work on this was sponsored jointly
  358.    by the Computing Systems Technology Office  (CSTO)  of  the  Advanced
  359.    Research  Projects  Agency  (ARPA)  and  by  the Information Security
  360.    Program  Office  (PD71E),  Space  &  Naval  Warface  Systems  Command
  361.    (SPAWAR).
  362.  
  363. AUTHOR'S ADDRESS:
  364.  
  365.    Randall Atkinson
  366.    Code 5544
  367.    Naval Research Laboratory
  368.    4555 Overlook Avenue, SW
  369.    Washington, DC 20375-5337
  370.  
  371.    Email: rja@cs.nrl.navy.mil
  372.    Telephone: (DSN) 354-8590
  373.  
  374.  
  375.    --PART-BOUNDARY=.1970606161952.ZM10146.eos.home.net--
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389. Atkinson                  Expires in 6 months                   [Page 7]
  390.  
  391. INTERNET-DRAFT               EXPIRES JANUARY 1997        INTERNET-DRAFT
  392.