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-ipsec-doi-01.txt < prev    next >
Text File  |  1996-11-19  |  31KB  |  840 lines
  1.  
  2.  
  3. Network Working Group                                      Derrell Piper
  4. INTERNET-DRAFT                                             cisco Systems
  5. draft-ietf-ipsec-ipsec-doi-01.txt                      November 15, 1996
  6.  
  7.  
  8.       The Internet IP Security Domain of Interpretation for ISAKMP
  9.                   <draft-ietf-ipsec-ipsec-doi-01.txt>
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet Draft. Internet Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its areas,
  16.    and working groups.  Note that other groups may also distribute
  17.    working documents as Internet Drafts.
  18.  
  19.    Internet Drafts are draft documents valid for a maximum of six months
  20.    and may be updated, replaced, or obsoleted by other documents at any
  21.    time. It is inapproporiate to use Internet Drafts as reference
  22.    material or to cite them other than as ``work in progress.''
  23.  
  24.    To learn the current status of any Internet Draft, please check the
  25.    ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow
  26.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  27.    munnari.oz.au (Australia), ds.internic.net (US East Coast), or
  28.    ftp.isi.edu (US West Coast).
  29.  
  30.    Distribution of this memo is unlimited. This draft will expire six
  31.    months from date of issue.
  32.  
  33.  
  34. 1. Abstract
  35.  
  36.    The Internet Security Association and Key Management Protocol
  37.    (ISAKMP) defines a framework for security association management and
  38.    cryptographic key establishment for the Internet.  This framework
  39.    consists of defined exchanges and processing guidelines that occur
  40.    within a given Domain of Interpretation (DOI).  This document details
  41.    the Internet IP Security DOI, which is defined to cover the IP
  42.    security protocols that use ISAKMP to negotiate their security
  43.    associations.
  44.  
  45. 2. Introduction
  46.  
  47.    Within ISAKMP, a Domain of Interpretation is used to group related
  48.    protocols using ISAKMP to negotiate security associations.  Security
  49.    protocols sharing a DOI choose security protocol and cryptographic
  50.    transforms from a common namespace and share key exchange protocol
  51.  
  52.  
  53.  
  54. Piper                     Expires in 6 months               [Page 1]
  55.  
  56. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  57.  
  58.  
  59.    identifiers.  They also share a common interpretation of DOI-specific
  60.    payload data content, including the Security Association and
  61.    Identification payloads.
  62.  
  63.    Overall, ISAKMP places the following requirements on a DOI
  64.    definition:
  65.  
  66.      o  define the naming scheme for DOI-specific protocol identifiers
  67.      o  define the interpretation for the Situation field
  68.      o  define the set of applicable security policies
  69.      o  define the syntax for DOI-specific SA Attributes (phase II)
  70.      o  define the syntax for DOI-specific payload contents
  71.      o  define additional mappings or Key Exchange types, if needed
  72.  
  73.    The remainder of this document details the instantiation of these
  74.    requirements for using the IP Security (IPSEC) protocols to provide
  75.    data origin authentication and/or data confidentiality for IP packets
  76.    sent between cooperating host systems and/or firewalls.
  77.  
  78. 3. Terms and Definitions
  79.  
  80. 3.1 Requirements Terminology
  81.  
  82.    In this document, the words that are used to define the significance
  83.    of each particular requirement are usually capitalised.  These words
  84.    are:
  85.  
  86.    - MUST
  87.  
  88.       This word or the adjective "REQUIRED" means that the item is an
  89.       absolute requirement of the specification.
  90.  
  91.    - SHOULD
  92.  
  93.       This word or the adjective "RECOMMENDED" means that there might
  94.       exist valid reasons in particular circumstances to ignore this
  95.       item, but the full implications should be understood and the case
  96.       carefully weighed before taking a different course.
  97.  
  98.    - MAY
  99.  
  100.       This word or the adjective "OPTIONAL" means that this item is
  101.       truly optional.  One vendor might choose to include the item
  102.       because a particular marketplace requires it or because it
  103.       enhances the product, for example; another vendor may omit the
  104.       same item.
  105.  
  106.  
  107.  
  108.  
  109.  
  110. Piper                     Expires in 6 months               [Page 2]
  111.  
  112. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  113.  
  114.  
  115. 4.1 IPSEC Naming Scheme
  116.  
  117.    Within ISAKMP, all DOI's must be registered with the IANA in the
  118.    ``Assigned Numbers'' RFC [STD-2].  The IANA Assigned Number for the
  119.    Internet IP Security DOI is one (1).  Within the IPSEC DOI, all
  120.    well-known identifiers MUST be registered with the IANA under the
  121.    Internet IP Security DOI.  Unless otherwise noted, all tables within
  122.    this document refer to IANA Assigned Numbers for the IPSEC DOI.
  123.  
  124.    All multi-octet binary values are stored in network byte order.
  125.  
  126. 4.2 IPSEC Situation Definition
  127.  
  128.    Within ISAKMP, the Situation provides information that can be used by
  129.    the responder to make a policy determination about how to process the
  130.    incoming Security Association request.  For the IPSEC DOI, the
  131.    Situation field is a four (4) octet bitmask with the following
  132.    values.
  133.  
  134.        Situation                   Value
  135.        ---------                   -----
  136.        SIT_IDENTITY_ONLY           0x01
  137.        SIT_SECRECY                 0x02
  138.        SIT_INTEGRITY               0x04
  139.  
  140.    All other values are reserved to IANA.
  141.  
  142. 4.2.1 SIT_IDENTITY_ONLY
  143.  
  144.    The SIT_IDENTITY_ONLY type specifies that the security association
  145.    will be identified by source identity information present in an
  146.    associated Identification Payload.  See Section 4.6.2 for a complete
  147.    description of the various Identification types.  All IPSEC DOI
  148.    implementations MUST support SIT_IDENTITY_ONLY by including an
  149.    Identification Payload in at least one of the phase I Oakley
  150.    exchanges ([IO], Section 5) and MUST abort any association setup that
  151.    does not include an Identification Payload.
  152.  
  153. 4.2.2 SIT_SECRECY
  154.  
  155.    The SIT_SECRECY type specifies that the security association is being
  156.    negotiated in an environment that requires labeled secrecy.  If
  157.    SIT_SECRECY is present in the Situation bitmap, the Situation field
  158.    will be followed by variable-length data that includes a sensitivity
  159.    level and compartment bitmask.  See Section 4.6.1 for a complete
  160.    description of the Security Association Payload format.
  161.  
  162.    If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be
  163.  
  164.  
  165.  
  166. Piper                     Expires in 6 months               [Page 3]
  167.  
  168. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  169.  
  170.  
  171.    set in the Situation bitmap and no secrecy level or category bitmaps
  172.    shall be included.
  173.  
  174.    If a responder does not support SIT_SECRECY, a SITUATION-NOT-
  175.    SUPPORTED Notification Payload SHOULD be returned and the security
  176.    association setup MUST be aborted.
  177.  
  178. 4.2.3 SIT_INTEGRITY
  179.  
  180.    The SIT_INTEGRITY type specifies that the security association is
  181.    being negotiated in an environment that requires labeled integrity.
  182.    If SIT_INTEGRITY is present in the Situation bitmap, the Situation
  183.    field will be followed by variable-length data that includes an
  184.    integrity level and compartment bitmask.  If SIT_SECRECY is also in
  185.    use for the association, the integrity information immediately
  186.    follows the variable-length secrecy level and categories.  See
  187.    section 4.6.1 for a complete description of the Security Association
  188.    Payload format.
  189.  
  190.    If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST
  191.    NOT be set in the Situation bitmap and no integrity level or category
  192.    bitmaps shall be included.
  193.  
  194.    If a responder does not support SIT_INTEGRITY, a SITUATION-NOT-
  195.    SUPPORTED Notification Payload SHOULD be returned and the security
  196.    association setup MUST be aborted.
  197.  
  198. 4.3 IPSEC Security Policy Requirement
  199.  
  200.    The IPSEC DOI does not impose specific security policy requirements
  201.    on any implementation.  Host system policy issues are outside of the
  202.    scope of this document.
  203.  
  204.    However, the following sections touch on some of the issues that must
  205.    be considered when designing an IPSEC DOI host implementation.  This
  206.    section should be considered only informational in nature.
  207.  
  208. 4.3.1 Key Management Issues
  209.  
  210.    It is expected that many systems choosing to implement ISAKMP will
  211.    strive to provide a protected domain of execution for a combined
  212.    ISAKMP/Oakley key management daemon.  On protected-mode multiuser
  213.    operating systems, this key management daemon will likely exist as a
  214.    separate privileged process.
  215.  
  216.    In such an environment, a formalized API to introduce keying material
  217.    into the TCP/IP kernel may be desirable.  The PF_KEY API [PFKEY] is
  218.    an example of one such API that provides an abstracted key management
  219.  
  220.  
  221.  
  222. Piper                     Expires in 6 months               [Page 4]
  223.  
  224. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  225.  
  226.  
  227.    interface.
  228.  
  229. 4.3.2 Static Keying Issues
  230.  
  231.    Host systems that implement static keys, either for use directly by
  232.    IPSEC, or for authentication purposes (see [IO] Section 5.3), should
  233.    take steps to protect the static keying material when it is not
  234.    residing in a protected memory domain or actively in use by the
  235.    TCP/IP kernel.
  236.  
  237.    For example, on a laptop, one might choose to store the static keys
  238.    in a configuration store that is, itself, encrypted under a private
  239.    password.
  240.  
  241.    Depending on the operating system and utility software installed, it
  242.    may not be possible to protect the static keys once they've been
  243.    loaded into the TCP/IP kernel, however they should not be trivially
  244.    recoverable on initial system startup without having to satisfy some
  245.    additional form of authentication.
  246.  
  247. 4.3.3 Host Policy Issues
  248.  
  249.    It is not realistic to assume that the transition to IPSEC will occur
  250.    overnight.  Host systems must be prepared to implement flexible
  251.    policy lists that describe which systems they desire to speak
  252.    securely with and which systems they require speak securely to them.
  253.    Some notion of proxy firewall addresses may also be required.
  254.  
  255.    A minimal approach is probably a static list of IP addresses, network
  256.    masks, and a security required flag or flags.
  257.  
  258.    A more flexible implementation might consist of a list of wildcard
  259.    DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional
  260.    firewall address.  The wildcard DNS name would be used to match
  261.    incoming or outgoing IP addresses, the in/out bitmask would be used
  262.    to determine whether or not security was to be applied and in which
  263.    direction, and the optional firewall address would be used to
  264.    indicate whether or not tunnel mode would be needed to talk to the
  265.    target system though an intermediate firewall.
  266.  
  267. 4.3.4 Certificate Management
  268.  
  269.    Host systems implementing a certificate-based authentication scheme
  270.    will need a mechanism for obtaining and managing a database of
  271.    certificates.
  272.  
  273.    Secure DNS is to be one certificate distribution mechanism, however
  274.    the pervasive availability of secure DNS zones, in the short term, is
  275.  
  276.  
  277.  
  278. Piper                     Expires in 6 months               [Page 5]
  279.  
  280. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  281.  
  282.  
  283.    doubtful for many reasons.  What's far more likely is that hosts will
  284.    need an ability to import certificates that they acquire through
  285.    secure, out-of-band mechanisms, as well as an ability to export their
  286.    own certificates for use by other systems.
  287.  
  288.    However, manual certificate management should not be done so as to
  289.    preclude the ability to introduce dynamic certificate discovery
  290.    mechanisms and/or protocols as they become available.
  291.  
  292. 4.4 IPSEC Assigned Numbers
  293.  
  294.    The following sections list the Assigned Numbers for the IPSEC DOI
  295.    Security Protocol Identifiers, Transform Identifiers, and Security
  296.    Association Attribute Types.
  297.  
  298. 4.4.1 IPSEC Security Protocol Identifiers
  299.  
  300.    The ISAKMP proposal syntax was specifically designed to allow for the
  301.    simultaneous negotiation of multiple security protocol suites within
  302.    a single negotiation.  As a result, the protocol suites listed below
  303.    form the set of protocols that can be negotiated at the same time.
  304.    It is a host policy decision as to what protocol suites might be
  305.    negotiated together.
  306.  
  307.    The following table lists the values for the Security Protocol
  308.    Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
  309.    DOI.
  310.  
  311.        Protocol ID                         Value
  312.        -----------                         -----
  313.        RESERVED                            0
  314.        PROTO_ISAKMP                        1
  315.        PROTO_IPSEC_AH                      2
  316.        PROTO_IPSEC_ESP                     3
  317.  
  318.    The values 4-15360 are reserved to IANA.  Values 15361-16384 are
  319.    reserved for private use.
  320.  
  321.    4.4.1.1 PROTO_ISAKMP
  322.  
  323.    The PROTO_ISAKMP type specifies message protection required during
  324.    Phase I of the ISAKMP protocol.  The specific protection mechanism
  325.    used for the IPSEC DOI is described in [IO].  All implementations
  326.    within the IPSEC DOI MUST support PROTO_ISAKMP.
  327.  
  328.    NB: ISAKMP reserves the value one (1) across all DOI definitions.
  329.  
  330. 4.4.1.2 PROTO_IPSEC_AH
  331.  
  332.  
  333.  
  334. Piper                     Expires in 6 months               [Page 6]
  335.  
  336. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  337.  
  338.  
  339.    The PROTO_IPSEC_AH type specifies IP packet data origin
  340.    authentication.  Confidentiality MUST NOT be provided by any
  341.    PROTO_IPSEC_AH transform.
  342.  
  343. 4.4.1.3 PROTO_IPSEC_ESP
  344.  
  345.    The PROTO_IPSEC_ESP type specifies IP packet confidentiality.  Data
  346.    origin authentication, if required, must be provided as part of the
  347.    ESP transform.  The default ESP transform includes data origin
  348.    authentication and replay prevention.
  349.  
  350. 4.4.2 IPSEC ISAKMP Transform Values
  351.  
  352.    As part of an ISAKMP Phase I negotiation, the initiator's choice of
  353.    Key Exchange offerings is made using some host system policy
  354.    description.  The actual selection of Key Exchange mechanism is made
  355.    using the standard ISAKMP Proposal Payload.  The following table
  356.    lists the defined ISAKMP Phase I Transform Identifiers for the
  357.    Proposal Payload for the IPSEC DOI.
  358.  
  359.        Transform                           Value
  360.        ---------                           -----
  361.        RESERVED                            0
  362.        KEY_OAKLEY                          1
  363.        KEY_MANUAL                          2
  364.        KEY_KDC                             3
  365.  
  366.    The values 4-15360 are reserved to IANA.  Values 15361-16384 are
  367.    reserved for private use.
  368.  
  369. 4.4.2.1 KEY_OAKLEY
  370.  
  371.    The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
  372.    key exchange as defined in the [IO] document.  All implementations
  373.    within the IPSEC DOI MUST support KEY_OAKLEY.
  374.  
  375. 4.4.2.2 KEY_MANUAL
  376.  
  377.    The KEY_MANUAL type specifies that a shared secret key mechanism is
  378.    to be used in lieu of a dynamic key mechanism.  Specific details of a
  379.    static key establishment protocol will be described in a future
  380.    document.
  381.  
  382. 4.4.2.3 KEY_KDC
  383.  
  384.    The KEY_KDC type specifies that a secret-key based Key Distribution
  385.    Center will be used to provide dynamic key exchange through a
  386.    Kerberos-like ticket protocol.  Specific details of a KDC-based key
  387.  
  388.  
  389.  
  390. Piper                     Expires in 6 months               [Page 7]
  391.  
  392. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  393.  
  394.  
  395.    establishment protocol will be described in a future document.
  396.  
  397. 4.4.3 IPSEC AH Transform Values
  398.  
  399.    The Authentication Header Protocol (AH) defines one mandatory and
  400.    several optional transforms used to provide data origin
  401.    authentication.  The following table lists the defined AH Transform
  402.    Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI.
  403.  
  404.        Transform                           Value
  405.        ---------                           -----
  406.        RESERVED                            0
  407.        AH_1828                             1
  408.        AH_HMAC_MD5_REPLAY                  2
  409.        AH_MHAC_SHA_REPLAY                  3
  410.  
  411.    The values 4-15360 are reserved to IANA.  Values 15361-16384 are
  412.    reserved for private use.
  413.  
  414. 4.4.3.1 AH_1828
  415.  
  416.    The AH_1828 type specifies the transform described in RFC-1828.  This
  417.    mode should be used only for compatibility with existing RFC-1828
  418.    implementations.
  419.  
  420. 4.4.3.2 AH_MD5_REPLAY
  421.  
  422.    The AH_MD5_REPLAY type specifies the transform described in
  423.    [HMACMD5].  This transform MUST be supported by all implementations
  424.    and is the preferred AH transform for the IPSEC DOI.
  425.  
  426. 4.4.3.3 AH_SHA_REPLAY
  427.  
  428.    The AH_SHA_REPLAY type specifies the transform described in
  429.    [HMACSHA]. While not required, it is strongly recommended that all
  430.    implementations include the AH_SHA_REPLAY transform in addition to
  431.    AH_MD5_REPLAY.
  432.  
  433. 4.4.4 IPSEC ESP Transform Identifiers
  434.  
  435.    The Encapsulating Security Protocol (ESP) defines one mandatory and
  436.    several optional transforms used to provide data confidentiality.
  437.    The following table lists the defined ESP Transform Identifiers for
  438.    the ISAKMP Proposal Payload for the IPSEC DOI.
  439.  
  440.        Transform ID                        Value
  441.        ------------                        -----
  442.        RESERVED                            0
  443.  
  444.  
  445.  
  446. Piper                     Expires in 6 months               [Page 8]
  447.  
  448. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  449.  
  450.  
  451.        ESP_1829_TRANSPORT                  1
  452.        ESP_1829_TUNNEL                     2
  453.        ESP_DES_CBC_HMAC_REPLAY             3
  454.  
  455.    The values 4-15360 are reserved to IANA.  Values 15361-16384 are
  456.    reserved for private use.
  457.  
  458. 4.4.4.1 ESP_1829_TRANSPORT
  459.  
  460.    The ESP_1829_TRANSPORT type specifies the ESP transform described in
  461.    RFC-1829, operating in Transport Mode.  This mode should be used only
  462.    for compatibility with existing RFC-1829 implementations.
  463.  
  464. 4.4.4.2 ESP_1829_TUNNEL
  465.  
  466.    The ESP_1829_TUNNEL type specifies the ESP transform described in
  467.    RFC-1829, operating in Tunnel Mode.  This mode should be used only
  468.    for compatibility with existing RFC-1829 implementation.
  469.  
  470. 4.4.4.3 ESP_DES_CBC_HMAC_REPLAY
  471.  
  472.    The ESP_DES_CBC_HMAC_REPLAY type specifies the transform described in
  473.    [Hughes].  This transform MUST be supported by all implementations
  474.    and is the preferred ESP transform for the IPSEC DOI.
  475.  
  476. 4.5 IPSEC Security Association Atttributes
  477.  
  478.    The following SA attribute definitions are used in phase II of an
  479.    ISAKMP/Oakley negotation.  Attribute types can be either Basic (B) or
  480.    Variable-Length (V).  Encoding of these attributes is defined in the
  481.    base ISAKMP specification.
  482.  
  483.        Attribute Classes
  484.  
  485.              class               value           type
  486.        -------------------------------------------------
  487.        Auth Key Life Type          1               B
  488.        Auth Key Life Duration      2               B/V
  489.        Enc Key Life Type           3               B
  490.        Enc Key Life Duration       4               B/V
  491.        SA Life Type                5               B
  492.        SA Life Duration            6               B/V
  493.        Replay Protection           7               B
  494.  
  495.        Class Values
  496.  
  497.          Auth Key Life Type
  498.          Enc Key Life Type
  499.  
  500.  
  501.  
  502. Piper                     Expires in 6 months               [Page 9]
  503.  
  504. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  505.  
  506.  
  507.          SA Life Type
  508.            seconds                 1
  509.            kilobytes               2
  510.  
  511.          Values 3-65000 are reserved to IANA.  Values 65001-65535
  512.          are for experimental use.  For a given "Life Type," the
  513.          value of the "Life Duration" attribute defines the actual
  514.          length of the component lifetime -- either a number of
  515.          seconds, or a number of Kbytes that can be protected.
  516.  
  517.          Replay Protection
  518.            not required            0
  519.            required                1
  520.  
  521.          Values 2-65000 are reserved to IANA.  Values 65001-65535
  522.          are for experimental use.
  523.  
  524. 4.6 IPSEC Payload Content
  525.  
  526.    The following sections describe those ISAKMP payloads whose data
  527.    representations are dependent on the applicable DOI.
  528.  
  529. 4.6.1 Security Association Payload
  530.  
  531.    The following diagram illustrates the content of the Security
  532.    Association Payload for the IPSEC DOI.  See Section 4.2 for a
  533.    description of the Situation bitmap.
  534.  
  535.     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
  536.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  537.    !  Next Payload !   RESERVED    !        Payload Length         !
  538.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  539.    !                Domain of Interpretation (IPSEC)               |
  540.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  541.    !           RESERVED            !      Situation (bitmap)       !
  542.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  543.    !                    Labeled Domain Identifier                  !
  544.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  545.    !  Secrecy Length (in octets)   !           RESERVED            !
  546.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  547.    ~                        Secrecy Level                          ~
  548.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  549.    ! Secrecy Cat. Length (in bits) !           RESERVED            !
  550.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  551.    ~                    Secrecy Category Bitmap                    ~
  552.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  553.    ! Integrity Length (in octets)  !           RESERVED            !
  554.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  555.  
  556.  
  557.  
  558. Piper                     Expires in 6 months              [Page 10]
  559.  
  560. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  561.  
  562.  
  563.    ~                       Integrity Level                         ~
  564.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  565.    ! Integ. Cat. Length (in bits)  !           RESERVED            !
  566.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  567.    ~                  Integrity Category Bitmap                    ~
  568.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  569.  
  570.                Figure 1: Security Association Payload Format
  571.  
  572.    The Security Association Payload is defined as follows:
  573.  
  574.      o  Next Payload (2 octets) - Identifier for the payload type of
  575.         the next payload in the message.  If the current payload is
  576.         the last in the message, this field will be zero (0).
  577.  
  578.      o  RESERVED (1 octet) - Unused, must be zero (0).
  579.  
  580.      o  Payload Length (2 octets) - Length, in octets, of the current
  581.         payload, including the generic header.
  582.  
  583.      o  Domain of Intepretation (4 octets) - Specifies the IPSEC DOI,
  584.         which has been assigned the value one (1).
  585.  
  586.      o  Situation (2 octets) - Bitmask used to interpret the
  587.         remainder of the Security Association Payload.  See Section
  588.         4.2 for a complete list of values.
  589.  
  590.      o  RESERVED (2 octets) - Unused, must be zero (0).
  591.  
  592.      o  Labeled Domain Identifier (4 octets) - IANA Assigned Number
  593.         used to interpret the Secrecy and Integrity information.
  594.  
  595.      o  Secrecy Length (2 octets) - Specifies the length, in octets,
  596.         of the secrecy level identifier.
  597.  
  598.      o  Secrecy Category Length (2 octets) - Specifies the length, in
  599.         bits, of the secrecy category (compartment) bitmap.
  600.  
  601.      o  Secrecy Category Bitmap (variable length) - A bitmap used to
  602.         designate secrecy categories (compartments) that are
  603.         required.
  604.  
  605.      o  Integrity Length (2 octets) - Specifies the length, in
  606.         octets, of the integrity level identifier.
  607.  
  608.      o  Integrity Category Length (2 octets) - Specifies the length,
  609.         in bits, of the integrity category (compartment) bitmap.
  610.  
  611.  
  612.  
  613.  
  614. Piper                     Expires in 6 months              [Page 11]
  615.  
  616. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  617.  
  618.  
  619.      o  Integrity Category Bitmap (variable length) - A bitmap used
  620.         to designate integrity categories (compartments) that are
  621.         required.
  622.  
  623.    4.6.2 Identification Payload Content
  624.  
  625.       The Identification Payload is used to identify the initiator of
  626.       the Security Association.  The identity of the initiator SHOULD be
  627.       used by the responder to determine the correct host system
  628.       security policy requirement for the association.  For example, a
  629.       host might choose to require data origin authentication without
  630.       confidentiality (AH) from a certain set of IP addresses and full
  631.       authentication with confidentiality (Hughes) from another range of
  632.       IP addresses.  The Identification Payload provides information
  633.       that can be used by the responder to make this decision.
  634.  
  635.       The following diagram illustrates the content of the
  636.       Identification Payload.
  637.  
  638.        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
  639.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  640.       !  Next Payload !   RESERVED    !        Payload Length         !
  641.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  642.       !   ID Type     !                  RESERVED                     !
  643.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  644.       ~                     Identification Data                       ~
  645.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  646.  
  647.                    Figure 2: Identification Payload Format
  648.  
  649.       The Identification Payload field is defined as follows:
  650.  
  651.         o  Next Payload (2 octets) - Identifier for the payload type of
  652.            the next payload in the message.  If the current payload is
  653.            the last in the message, this field will be zero (0).
  654.  
  655.         o  RESERVED (1 octet) - Unused, must be zero (0).
  656.  
  657.         o  Payload Length (2 octets) - Length, in octets, of the
  658.            identification data, including the generic header.
  659.  
  660.         o  Identification Type (1 octet) - Value describing the
  661.            identity information found in the Identification Data field.
  662.  
  663.         o  RESERVED (3 octets) - Unused, must be zero (0).
  664.  
  665. 4.6.2.1 Identifiction Type Values
  666.  
  667.  
  668.  
  669.  
  670. Piper                     Expires in 6 months              [Page 12]
  671.  
  672. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  673.  
  674.  
  675.    The following table lists the assigned values for the Identification
  676.    Type field found in the Identification Payload.
  677.  
  678.        ID Type                             Value
  679.        -------                             -----
  680.        RESERVED                            0
  681.        ID_IPV4_ADDR                        1
  682.        ID_FQDN                             2
  683.        ID_FQUN                             3
  684.        ID_IPV4_ADDR_RANGE                  4
  685.        ID_IPV6_ADDR                        5
  686.        ID_IPV6_ADDR_RANGE                  6
  687.  
  688.    The values 6-500 are reserved to IANA.  Values 501-512 are reserved
  689.    for private use.
  690.  
  691. 4.6.2.2 ID_IPV4_ADDR
  692.  
  693.    The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
  694.  
  695. 4.6.2.3 ID_FQDN
  696.  
  697.    The ID_FQDN type specifies a fully-qualified domain name string.  An
  698.    example of a ID_FQDN is, "foo.bar.com".
  699.  
  700. 4.6.2.4 ID_FQUN
  701.  
  702.    The ID_FQUN type specifies a fully-qualified username string, An
  703.    example of a ID_FQUN is, "piper@foo.bar.com".
  704.  
  705. 4.6.2.5 ID_IPV4_ADDR_RANGE
  706.  
  707.    The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses,
  708.    represented by two four (4) octet values.  The first value is an IPv4
  709.    address.  The second is an IPv4 network mask.  Note that ones (1s) in
  710.    the network mask indicate that the corresponding bit in the address
  711.    is fixed, while zeros (0s) indicate a "wildcard" bit.
  712.  
  713. 4.6.2.6 ID_IPV6_ADDR
  714.  
  715.    The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
  716.    address.
  717.  
  718. 4.6.2.7 ID_IPV6_ADDR_RANGE
  719.  
  720.    The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses,
  721.    represented by two sixteen (16) octet values.  The first value is an
  722.    IPv6 address.  The second is an IPv6 network mask.  Note that ones
  723.  
  724.  
  725.  
  726. Piper                     Expires in 6 months              [Page 13]
  727.  
  728. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  729.  
  730.  
  731.    (1s) in the network mask indicate that the corresponding bit in the
  732.    address is fixed, while zeros (0s) indicate a "wildcard" bit.
  733.  
  734. 4.7 IPSEC Security Parameter Index (SPI) Encoding
  735.  
  736.    ISAKMP defines the SPI field as eight octets in length, however the
  737.    IPSEC transforms use only four octets.
  738.  
  739.    All implementation MUST use the following mapping for the ISAKMP SPI
  740.    field in the IPSEC DOI.
  741.  
  742.     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
  743.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  744.    !                             SPI                               !
  745.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  746.    !                           RESERVED                            !
  747.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  748.  
  749.                        Figure 3: ISAKMP SPI Encoding
  750.  
  751.    The ISAKMP SPI field is defined as follows:
  752.  
  753.      o  SPI - Security Paramater Index (4 octets) - contains the
  754.         SPI value which identifies the security association.
  755.  
  756.      o  RESERVED (4 octets) - Unused, must be zero (0).
  757.  
  758. 4.8 IPSEC Key Exchange Requirements
  759.  
  760.    The IPSEC DOI introduces no additional Key Exhange types.
  761.  
  762. 5. Security Considerations
  763.  
  764.    This entire draft pertains to a hybrid protocol, combining Oakley
  765.    ([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate and derive keying
  766.    material for security associations in a secure and authenticated
  767.    manner.  Specific discussion of the various security protocols and
  768.    transforms identified in this document can be found in the associated
  769.    base documents.
  770.  
  771. Acknowledgements
  772.  
  773.    This document is derived, in part, from previous works by Douglas
  774.    Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,
  775.    and Dave Carrel.
  776.  
  777. References
  778.  
  779.  
  780.  
  781.  
  782. Piper                     Expires in 6 months              [Page 14]
  783.  
  784. INTERNET DRAFT                 IPSEC DOI               November 15, 1996
  785.  
  786.  
  787.    [HMACMD5] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with
  788.    Replay Prevention," draft-ietf-ipsec-ah-hmac-md5-03.txt.
  789.  
  790.    [HMACSHA] Chang, S., Glenn, R., "HMAC-SHA IP Authentication with
  791.    Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-03.txt.
  792.  
  793.    [Hughes] Hughes, J., Editor, "Combined DES-CBC, HMAC and Replay
  794.    Prevention Transform," draft-ietf-ipsec-esp-des-md5-03.txt.
  795.  
  796.    [IO] Carrel, D., Harkins, D., "The Resolution of ISAKMP with Oakley,"
  797.    draft-ietf-ipsec-isakmp-oakley-02.txt.
  798.  
  799.    [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
  800.    "Internet Security Association and Key Management Protocol (ISAKMP),"
  801.    draft-ietf-ipsec-isakmp-06.{ps,txt}.
  802.  
  803.    [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"
  804.    draft-ietf-ipsec-oakley-01.txt.
  805.  
  806.    [PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key
  807.    Management API, Version 2", draft-mcdonald-pf-key-v2-00.txt, work in
  808.    progress.
  809.  
  810. Author's Address:
  811.  
  812.    Derrell Piper <piper@cisco.com>
  813.    cisco Systems
  814.    101 Cooper St.
  815.    Santa Cruz, California, 95060
  816.    United States of America
  817.    +1 408 457-5384
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838. Piper                     Expires in 6 months              [Page 15]
  839.  
  840.