home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipsec-isakmp-mode-cfg-00.txt < prev    next >
Text File  |  1997-10-02  |  13KB  |  391 lines
  1.  
  2. Internet Engineering Task Force                             R. Pereira
  3. IP Security Working Group                         TimeStep Corporation
  4. Internet Draft                                                S. Anand
  5. Expires in six months                            Microsoft Corporation
  6.                                                        October 1, 1997
  7.  
  8.  
  9.  
  10.                     The ISAKMP Configuration Mode
  11.               <draft-ietf-ipsec-isakmp-mode-cfg-00.txt>
  12.  
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This document is a submission to the IETF Internet Protocol
  18.    Security (IPSECond) Working Group. Comments are solicited and
  19.    should be addressed to the working group mailing list
  20.    (ipsec@tis.com) or to the editor.
  21.  
  22.    This document is an Internet-Draft.  Internet Drafts are working
  23.    documents of the Internet Engineering Task Force (IETF), its areas,
  24.    and its working Groups. Note that other groups may also distribute
  25.    working documents as Internet Drafts.
  26.  
  27.    Internet-Drafts draft documents are valid for a maximum of six
  28.    months and may be updated, replaced, or obsolete by other documents
  29.    at any time. It is inappropriate to use Internet-Drafts as
  30.    reference material or to cite them other than as "work in
  31.    progress."
  32.  
  33.    To learn the current status of any Internet-Draft, please check the
  34.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  35.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  36.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  37.    ftp.isi.edu (US West Coast).
  38.  
  39.    Distribution of this memo is unlimited.
  40.  
  41. Abstract
  42.  
  43.    This document describes a new ISAKMP mode that allows configuration
  44.    items to be set by using both push/acknowledge and request/reply
  45.    paradigms.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. R. Pereira, S. Anand                                          [Page 1]
  56. Internet Draft      The ISAKMP Configuration Mode         October, 97
  57.  
  58.  
  59. Table of Contents
  60.  
  61.    1. Introduction...................................................2
  62.      1.1. Specification of Requirements..............................2
  63.    2. Configuration Mode.............................................3
  64.    3. Configuration Transaction......................................3
  65.      3.1. Configuration Codes........................................4
  66.    4. Configuration Payload..........................................4
  67.    5. Configuration Attributes.......................................5
  68.    6. Security Considerations........................................6
  69.    7. References.....................................................6
  70.    8. Acknowledgments................................................7
  71.    9. Editors' Addresses.............................................7
  72.  
  73.  
  74. 1.   Introduction
  75.  
  76.    ISAKMP provides a framework to negotiate and derive Security
  77.    Associations.  But since it is used within the IPSec framework, it
  78.    may also be used to configure secure hosts.  This configuration may
  79.    take place between a gateway, an end-host client, or a
  80.    configuration manager.  For example, this can be used to configure
  81.    multi-protocol IP tunnels securely.
  82.  
  83.    It is assumed that the reader is familiar with the terms and
  84.    concepts described in the "Security Architecture for the Internet
  85.    Protocol" [Atkinson95] and "IP Security Document Roadmap"
  86.    [Thayer97] documents.
  87.  
  88.    Readers are advised to be familiar with both [Harkins97] and
  89.    [ISAKMP] because of the terminology used within this document and
  90.    the fact that this document is an extension of both of those
  91.    documents.
  92.  
  93.  
  94. 1.1. Specification of Requirements
  95.  
  96.    The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
  97.    NOT", and "MAY" that appear in this document are to be interpreted
  98.    as described in [Bradner97].
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111. R. Pereira, S. Anand                                          [Page 2]
  112. Internet Draft      The ISAKMP Configuration Mode         October, 97
  113.  
  114.  
  115. 2.   Configuration Mode
  116.  
  117.    Configuration Mode uses an XCHG type of 34 for the ISAKMP header.
  118.    This mode MUST NOT be used prior to establishment of an ISAKMP
  119.    Phase 1 Security Association.
  120.  
  121.            Initiator                        Responder
  122.           -----------                      -----------
  123.            HDR*, HASH, CFG      -->
  124.                                    <--      HDR*, HASH, CFG
  125.  
  126.    where HASH is the prf output, using SKEYID_a as the key, and the
  127.    message-ID from the ISAKMP header concatenated with the entire CFG
  128.    payload, including attributes.  In other words the hashes for the
  129.    above exchange are:
  130.  
  131.          HASH = prf(SKEYID_a, M-ID | CFG)
  132.  
  133.    Only one CFG payload MAY be present in one exchange of this mode.
  134.  
  135.  
  136. 3.   Configuration Transaction
  137.  
  138.    A "Configuration Transaction" is defined as two Configuration Mode
  139.    exchanges, the first being either a Set or a Request and the second
  140.    being either a Acknowledge or a Reply respectively.  The Message ID
  141.    within the ISAKMP header identifies the configuration transaction
  142.    and MUST NOT be zero.
  143.  
  144.    There are two paradigms to follow for this mode.
  145.  
  146.    o "Set/Acknowledge" works on the push principle that allows a
  147.      configuration manager (a host that wishes to send information to
  148.      another) to start the configuration transaction.  The
  149.      Acknowledge code MUST return zero length attributes that it
  150.      accepted.  Those attributes that it did not accept will NOT be
  151.      sent back in the acknowledgement.
  152.  
  153.    o "Request/Reply" allows a host to request information from an
  154.      informed host (a configuration manager).  Attributes in the
  155.      Request exchange may have values filled in to request these
  156.      values once again.  The Reply exchange MAY wish to choose those
  157.      values, or return new values.  It MAY also add new attributes
  158.      and not include some requested attributes.
  159.  
  160.    Transactions are completed once the Reply or Acknowledge code is
  161.    received.  If one is not received, the implementation MAY wish to
  162.    retransmit the original exchange.
  163.  
  164.  
  165.  
  166.  
  167. R. Pereira, S. Anand                                          [Page 3]
  168. Internet Draft      The ISAKMP Configuration Mode         October, 97
  169.  
  170.  
  171.    If a badly formatted exchange is received, the exchange SHOULD be
  172.    dropped and logged locally, as per local policy.  Badly formatted
  173.    exchanges would also include those with unknown codes or unknown
  174.    attributes within the Configuration Mode.
  175.  
  176.  
  177. 3.1. Configuration Codes
  178.  
  179.     Code                       Value
  180.    ========================== ===========
  181.     ISKAMP_CFG_REQUEST         1
  182.     ISKAMP_CFG_REPLY           2
  183.     ISKAMP_CFG_SET             3
  184.     ISKAMP_CFG_ACK             4
  185.     Reserved for future use    5 - 127
  186.     Reserved for private use   128 - 255
  187.  
  188.  
  189. 4.   Configuration Payload
  190.  
  191.    The Configuration Payload is used to accomplish configuration
  192.    transactions between two secure hosts.  Its "next payload" value is
  193.    13.
  194.                          1                   2                   3
  195.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  196.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  197.     | Next Payload  |   RESERVED    |         Payload Length        |
  198.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  199.     |     Code      |   RESERVED    |     Number of Attributes      |
  200.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  201.     |                                                               |
  202.     ~                         Attributes                            ~
  203.     |                                                               |
  204.     +---------------------------------------------------------------+
  205.  
  206.    The Configuration Payload fields are defined as follows:
  207.  
  208.    o Next Payload (1 octet) - Identifier for the payload type of the
  209.      next payload in the message.  If the current payload is the last
  210.      in the message, then this field will be 0.  For the
  211.      Configuration Mode, this field MUST be 0, since there is never a
  212.      next payload.
  213.  
  214.    o RESERVED (1 octet) - Unused, set to 0.
  215.  
  216.    o Payload Length (2 octets) - Length in octets of the entire
  217.      Configuration payload, including the Configuration payload
  218.      header and all of the attributes.
  219.  
  220.  
  221.  
  222.  
  223. R. Pereira, S. Anand                                          [Page 4]
  224. Internet Draft      The ISAKMP Configuration Mode         October, 97
  225.  
  226.  
  227.    o Code (1 octet) - A code that represents a command to be
  228.      fulfilled or an action that has been completed.  Please see
  229.      Section 4.1 for a description of each code.
  230.  
  231.    o RESERVED (1 octet) - Unused, set to 0.
  232.  
  233.    o Number of Attributes (2 octets) - States the number of
  234.      attributes to follow.  Note that both the payload length and the
  235.      number of attributes field may be used to process the
  236.      attributes.
  237.  
  238.    o Attributes (variable) - One or more data attributes as defined
  239.      in [ISAKMP], section 3.3.  Please see a later section for more
  240.      information on the contents of these attributes.
  241.  
  242.  
  243.  
  244. 5.   Configuration Attributes
  245.  
  246.     Attribute                  Value   Type             Length
  247.    ========================== ======= ================ ============
  248.     INTERNAL_IP4_ADDRESS       1       Variable         4 octets
  249.     INTERNAL_IPX_ADDRESS       2       Variable         6 octets
  250.     INTERNAL_NB_ADDRESS        3       Variable         16 octets
  251.     INTERNAL_IP4_DNS           4       Variable         4 octets
  252.     INTERNAL_IP4_NBNS          5       Variable         4 octets
  253.     RENEW_SECONDS              6       Basic/Variable   2 or 4 octets
  254.     USE_IP4_DHCP               7       Variable         4 octets
  255.     Reserved for future use    8-63
  256.     Reserved for private use   64-127
  257.  
  258.    o INTERNAL_IP4_ADDRESS - Specifies an IPv4 address within the
  259.      internal network.  This address is sometimes called a red node
  260.      address.  This address is sometimes an illegal address on the
  261.      Internet.
  262.  
  263.    o INTERNAL_IPX_ADDRESS - Specifies an IPX address within the
  264.      internal network.
  265.  
  266.    o INTERNAL_NB_ADDRESS - Specifies a NetBios address within the
  267.      internal network.
  268.  
  269.    o INTERNAL_IP4_DNS - Specifies an IPv4 address of a DNS server
  270.      within the network.
  271.  
  272.    o INTERNAL_IP4_NBNS - Specifies an IPv4 address of a NetBios Name
  273.      Server (WINS) within the network.
  274.  
  275.  
  276.  
  277.  
  278. R. Pereira, S. Anand                                          [Page 5]
  279. Internet Draft      The ISAKMP Configuration Mode         October, 97
  280.  
  281.  
  282.    o RENEW_SECONDS - Specifies the number of seconds that the host
  283.      can use all of the information set within the configuration
  284.      transaction.  The host MUST renew this information before this
  285.      expiry time and MUST not use any of the information obtained
  286.      through the configuration transaction after the expiry time.
  287.  
  288.    o USE_IP4_DHCP - Instructs the host to request any subsequent
  289.      information through the DHCP protocol.  This attribute holds the
  290.      IPv4 address of a DHCP server.
  291.  
  292.   It is hoped that more attribute types will be defined in the
  293.   future.  Some suggestions would be to distribute local policy, or
  294.   even authentication certificates.  Also, note that no
  295.   recommendations are made to how an implementation actually figures
  296.   out what information to send.  i.e. we do not recommend any
  297.   specific method of (a gateway) determining which DNS server should
  298.   be returned to a requesting host.
  299.  
  300.  
  301.  
  302. 6.   Security Considerations
  303.  
  304.   This entire draft discusses a new ISAKMP mode to allow entities in
  305.   the network to acquire and share configuration information.
  306.  
  307.   The draft mandates that this exchange always occur after the Phase
  308.   I Security Association has been set up and that the entire exchange
  309.   be protected by the Phase I SA.  Thus the exchange is as secure as
  310.   any Phase II SA.
  311.  
  312.  
  313. 7.   References
  314.  
  315.    [Atkinson95] Atkinson, R., "Security Architecture for the Internet
  316.    Protocol", draft-ietf-ipsec-arch-sec-01
  317.  
  318.    [Bradner97] Bradner, S., "Key words for use in RFCs to indicate
  319.    Requirement Levels", RFC2119, March 1997
  320.  
  321.    [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner,
  322.    "Internet Security Association and Key Management Protocol",
  323.    draft-ietf-ipsec-isakmp-08
  324.  
  325.    [Harkins97] D. Harkins, "The Resolution of ISAKMP and Oakley",
  326.    draft-ietf-ipsec-isakmp-oakley-04
  327.  
  328.    [Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document
  329.    Roadmap", draft-ietf-ipsec-doc-roadmap-00
  330.  
  331.  
  332.  
  333.  
  334. R. Pereira, S. Anand                                          [Page 6]
  335. Internet Draft      The ISAKMP Configuration Mode         October, 97
  336.  
  337.  
  338. 8.   Acknowledgments
  339.  
  340.    The editors would like to thank Peter Ford of Microsoft and Bob
  341.    Moskowitz of Chrysler.
  342.  
  343.  
  344. 9.   Editors' Addresses
  345.  
  346.      Roy Pereira
  347.      rpereira@timestep.com
  348.      TimeStep Corporation
  349.      +1 (613) 599-3610 x 4808
  350.  
  351.      Sanjay Anand
  352.      sanjayan@microsoft.com
  353.      Microsoft Corporation
  354.      +1 (206) 936-6367
  355.  
  356.  
  357.    The IPSec working group can be contacted via the IPSec working
  358.    group's mailing list (ipsec@tis.com) or through its chairs:
  359.  
  360.      Robert Moskowitz
  361.      rgm@chrysler.com
  362.      Chrysler Corporation
  363.  
  364.      Theodore Y. TsÆo
  365.      tytso@MIT.EDU
  366.      Massachusetts Institute of Technology
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390. R. Pereira, S. Anand                                          [Page 7]
  391.