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-02.txt < prev    next >
Text File  |  1997-09-02  |  41KB  |  1,123 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. Network Working Group                                      Derrell Piper
  7. INTERNET-DRAFT                                             cisco Systems
  8. draft-ietf-ipsec-ipsec-doi-02.txt                      February 28, 1997
  9.  
  10.  
  11.       The Internet IP Security Domain of Interpretation for ISAKMP
  12.                   <draft-ietf-ipsec-ipsec-doi-02.txt>
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This document is an Internet Draft. Internet Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its areas,
  19.    and working groups.  Note that other groups may also distribute
  20.    working documents as Internet Drafts.
  21.  
  22.    Internet Drafts are draft documents valid for a maximum of six months
  23.    and may be updated, replaced, or obsoleted by other documents at any
  24.    time. It is inappropriate to use Internet Drafts as reference
  25.    material or to cite them other than as ``work in progress.''
  26.  
  27.    To learn the current status of any Internet Draft, please check the
  28.    ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow
  29.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30.    munnari.oz.au (Australia), ds.internic.net (US East Coast), or
  31.    ftp.isi.edu (US West Coast).
  32.  
  33.    Distribution of this memo is unlimited. This draft will expire six
  34.    months from date of issue.
  35.  
  36.  
  37. 1. Abstract
  38.  
  39.    The Internet Security Association and Key Management Protocol
  40.    (ISAKMP) defines a framework for security association management and
  41.    cryptographic key establishment for the Internet.  This framework
  42.    consists of defined exchanges and processing guidelines that occur
  43.    within a given Domain of Interpretation (DOI).  This document details
  44.    the Internet IP Security DOI, which is defined to cover the IP
  45.    security protocols that use ISAKMP to negotiate their security
  46.    associations.
  47.  
  48. 2. Introduction
  49.  
  50.    Within ISAKMP, a Domain of Interpretation is used to group related
  51.    protocols using ISAKMP to negotiate security associations.  Security
  52.    protocols sharing a DOI choose security protocol and cryptographic
  53.    transforms from a common namespace and share key exchange protocol
  54.  
  55.  
  56.  
  57. Piper                     Expires in 6 months               [Page 1]
  58.  
  59. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  60.  
  61.  
  62.    identifiers.  They also share a common interpretation of DOI-specific
  63.    payload data content, including the Security Association and
  64.    Identification payloads.
  65.  
  66.    Overall, ISAKMP places the following requirements on a DOI
  67.    definition:
  68.  
  69.      o  define the naming scheme for DOI-specific protocol identifiers
  70.      o  define the interpretation for the Situation field
  71.      o  define the set of applicable security policies
  72.      o  define the syntax for DOI-specific SA Attributes (phase II)
  73.      o  define the syntax for DOI-specific payload contents
  74.      o  define additional mappings or Key Exchange types, if needed
  75.  
  76.    The remainder of this document details the instantiation of these
  77.    requirements for using the IP Security (IPSEC) protocols to provide
  78.    data origin authentication and/or data confidentiality for IP packets
  79.    sent between cooperating host systems and/or firewalls.
  80.  
  81. 3. Terms and Definitions
  82.  
  83. 3.1 Requirements Terminology
  84.  
  85.    In this document, the words that are used to define the significance
  86.    of each particular requirement are usually capitalised.  These words
  87.    are:
  88.  
  89.    - MUST
  90.  
  91.       This word or the adjective "REQUIRED" means that the item is an
  92.       absolute requirement of the specification.
  93.  
  94.    - SHOULD
  95.  
  96.       This word or the adjective "RECOMMENDED" means that there might
  97.       exist valid reasons in particular circumstances to ignore this
  98.       item, but the full implications should be understood and the case
  99.       carefully weighed before taking a different course.
  100.  
  101.    - MAY
  102.  
  103.       This word or the adjective "OPTIONAL" means that this item is
  104.       truly optional.  One vendor might choose to include the item
  105.       because a particular marketplace requires it or because it
  106.       enhances the product, for example; another vendor may omit the
  107.       same item.
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Piper                     Expires in 6 months               [Page 2]
  114.  
  115. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  116.  
  117.  
  118. 4.1 IPSEC Naming Scheme
  119.  
  120.    Within ISAKMP, all DOI's must be registered with the IANA in the
  121.    ``Assigned Numbers'' RFC [STD-2].  The IANA Assigned Number for the
  122.    Internet IP Security DOI is one (1).  Within the IPSEC DOI, all
  123.    well-known identifiers MUST be registered with the IANA under the
  124.    Internet IP Security DOI.  Unless otherwise noted, all tables within
  125.    this document refer to IANA Assigned Numbers for the IPSEC DOI.
  126.  
  127.    All multi-octet binary values are stored in network byte order.
  128.  
  129. 4.2 IPSEC Situation Definition
  130.  
  131.    Within ISAKMP, the Situation provides information that can be used by
  132.    the responder to make a policy determination about how to process the
  133.    incoming Security Association request.  For the IPSEC DOI, the
  134.    Situation field is a four (4) octet bitmask with the following
  135.    values.
  136.  
  137.        Situation                   Value
  138.        ---------                   -----
  139.        SIT_IDENTITY_ONLY           0x01
  140.        SIT_SECRECY                 0x02
  141.        SIT_INTEGRITY               0x04
  142.  
  143.    All other values are reserved to IANA.
  144.  
  145. 4.2.1 SIT_IDENTITY_ONLY
  146.  
  147.    The SIT_IDENTITY_ONLY type specifies that the security association
  148.    will be identified by source identity information present in an
  149.    associated Identification Payload.  See Section 4.6.2 for a complete
  150.    description of the various Identification types.  All IPSEC DOI
  151.    implementations MUST support SIT_IDENTITY_ONLY by including an
  152.    Identification Payload in at least one of the phase I Oakley
  153.    exchanges ([IO], Section 5) and MUST abort any association setup that
  154.    does not include an Identification Payload.
  155.  
  156.    If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the
  157.    situation consists only of the 4 octet situation bitmap and does not
  158.    include the Labeled Domain Identifier field (Figure 1, Section 4.6.1)
  159.    or any subsequent label information.  Conversely, if the initiator
  160.    supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain
  161.    Identifier MUST be included in the situation payload.
  162.  
  163. 4.2.2 SIT_SECRECY
  164.  
  165.    The SIT_SECRECY type specifies that the security association is being
  166.  
  167.  
  168.  
  169. Piper                     Expires in 6 months               [Page 3]
  170.  
  171. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  172.  
  173.  
  174.    negotiated in an environment that requires labeled secrecy.  If
  175.    SIT_SECRECY is present in the Situation bitmap, the Situation field
  176.    will be followed by variable-length data that includes a sensitivity
  177.    level and compartment bitmask.  See Section 4.6.1 for a complete
  178.    description of the Security Association Payload format.
  179.  
  180.    If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be
  181.    set in the Situation bitmap and no secrecy level or category bitmaps
  182.    shall be included.
  183.  
  184.    If a responder does not support SIT_SECRECY, a SITUATION-NOT-
  185.    SUPPORTED Notification Payload SHOULD be returned and the security
  186.    association setup MUST be aborted.
  187.  
  188. 4.2.3 SIT_INTEGRITY
  189.  
  190.    The SIT_INTEGRITY type specifies that the security association is
  191.    being negotiated in an environment that requires labeled integrity.
  192.    If SIT_INTEGRITY is present in the Situation bitmap, the Situation
  193.    field will be followed by variable-length data that includes an
  194.    integrity level and compartment bitmask.  If SIT_SECRECY is also in
  195.    use for the association, the integrity information immediately
  196.    follows the variable-length secrecy level and categories.  See
  197.    section 4.6.1 for a complete description of the Security Association
  198.    Payload format.
  199.  
  200.    If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST
  201.    NOT be set in the Situation bitmap and no integrity level or category
  202.    bitmaps shall be included.
  203.  
  204.    If a responder does not support SIT_INTEGRITY, a SITUATION-NOT-
  205.    SUPPORTED Notification Payload SHOULD be returned and the security
  206.    association setup MUST be aborted.
  207.  
  208. 4.3 IPSEC Security Policy Requirement
  209.  
  210.    The IPSEC DOI does not impose specific security policy requirements
  211.    on any implementation.  Host system policy issues are outside of the
  212.    scope of this document.
  213.  
  214.    However, the following sections touch on some of the issues that must
  215.    be considered when designing an IPSEC DOI host implementation.  This
  216.    section should be considered only informational in nature.
  217.  
  218. 4.3.1 Key Management Issues
  219.  
  220.    It is expected that many systems choosing to implement ISAKMP will
  221.    strive to provide a protected domain of execution for a combined
  222.  
  223.  
  224.  
  225. Piper                     Expires in 6 months               [Page 4]
  226.  
  227. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  228.  
  229.  
  230.    ISAKMP/Oakley key management daemon.  On protected-mode multiuser
  231.    operating systems, this key management daemon will likely exist as a
  232.    separate privileged process.
  233.  
  234.    In such an environment, a formalized API to introduce keying material
  235.    into the TCP/IP kernel may be desirable.  The PF_KEY API [PFKEY] is
  236.    an example of one such API that provides an abstracted key management
  237.    interface.
  238.  
  239. 4.3.2 Static Keying Issues
  240.  
  241.    Host systems that implement static keys, either for use directly by
  242.    IPSEC, or for authentication purposes (see [IO] Section 5.3), should
  243.    take steps to protect the static keying material when it is not
  244.    residing in a protected memory domain or actively in use by the
  245.    TCP/IP kernel.
  246.  
  247.    For example, on a laptop, one might choose to store the static keys
  248.    in a configuration store that is, itself, encrypted under a private
  249.    password.
  250.  
  251.    Depending on the operating system and utility software installed, it
  252.    may not be possible to protect the static keys once they've been
  253.    loaded into the TCP/IP kernel, however they should not be trivially
  254.    recoverable on initial system startup without having to satisfy some
  255.    additional form of authentication.
  256.  
  257. 4.3.3 Host Policy Issues
  258.  
  259.    It is not realistic to assume that the transition to IPSEC will occur
  260.    overnight.  Host systems must be prepared to implement flexible
  261.    policy lists that describe which systems they desire to speak
  262.    securely with and which systems they require speak securely to them.
  263.    Some notion of proxy firewall addresses may also be required.
  264.  
  265.    A minimal approach is probably a static list of IP addresses, network
  266.    masks, and a security required flag or flags.
  267.  
  268.    A more flexible implementation might consist of a list of wildcard
  269.    DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional
  270.    firewall address.  The wildcard DNS name would be used to match
  271.    incoming or outgoing IP addresses, the in/out bitmask would be used
  272.    to determine whether or not security was to be applied and in which
  273.    direction, and the optional firewall address would be used to
  274.    indicate whether or not tunnel mode would be needed to talk to the
  275.    target system though an intermediate firewall.
  276.  
  277. 4.3.4 Certificate Management
  278.  
  279.  
  280.  
  281. Piper                     Expires in 6 months               [Page 5]
  282.  
  283. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  284.  
  285.  
  286.    Host systems implementing a certificate-based authentication scheme
  287.    will need a mechanism for obtaining and managing a database of
  288.    certificates.
  289.  
  290.    Secure DNS is to be one certificate distribution mechanism, however
  291.    the pervasive availability of secure DNS zones, in the short term, is
  292.    doubtful for many reasons.  What's far more likely is that hosts will
  293.    need an ability to import certificates that they acquire through
  294.    secure, out-of-band mechanisms, as well as an ability to export their
  295.    own certificates for use by other systems.
  296.  
  297.    However, manual certificate management should not be done so as to
  298.    preclude the ability to introduce dynamic certificate discovery
  299.    mechanisms and/or protocols as they become available.
  300.  
  301. 4.4 IPSEC Assigned Numbers
  302.  
  303.    The following sections list the Assigned Numbers for the IPSEC DOI
  304.    Security Protocol Identifiers, Transform Identifiers, and Security
  305.    Association Attribute Types.
  306.  
  307. 4.4.1 IPSEC Security Protocol Identifiers
  308.  
  309.    The ISAKMP proposal syntax was specifically designed to allow for the
  310.    simultaneous negotiation of multiple security protocol suites within
  311.    a single negotiation.  As a result, the protocol suites listed below
  312.    form the set of protocols that can be negotiated at the same time.
  313.    It is a host policy decision as to what protocol suites might be
  314.    negotiated together.
  315.  
  316.    The following table lists the values for the Security Protocol
  317.    Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
  318.    DOI.
  319.  
  320.        Protocol ID                         Value
  321.        -----------                         -----
  322.        RESERVED                            0
  323.        PROTO_ISAKMP                        1
  324.        PROTO_IPSEC_AH                      2
  325.        PROTO_IPSEC_ESP                     3
  326.  
  327.    The size of this field is one octet.  The values 4-248 are reserved
  328.    to IANA.  Values 249-255 are reserved for private use.
  329.  
  330.    4.4.1.1 PROTO_ISAKMP
  331.  
  332.    The PROTO_ISAKMP type specifies message protection required during
  333.    Phase I of the ISAKMP protocol.  The specific protection mechanism
  334.  
  335.  
  336.  
  337. Piper                     Expires in 6 months               [Page 6]
  338.  
  339. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  340.  
  341.  
  342.    used for the IPSEC DOI is described in [IO].  All implementations
  343.    within the IPSEC DOI MUST support PROTO_ISAKMP.
  344.  
  345.    NB: ISAKMP reserves the value one (1) across all DOI definitions.
  346.  
  347. 4.4.1.2 PROTO_IPSEC_AH
  348.  
  349.    The PROTO_IPSEC_AH type specifies IP packet data origin
  350.    authentication.  The default AH transform includes data origin
  351.    authentication and replay prevention.  For export control
  352.    considerations, confidentiality MUST NOT be provided by any
  353.    PROTO_IPSEC_AH transform.
  354.  
  355. 4.4.1.3 PROTO_IPSEC_ESP
  356.  
  357.    The PROTO_IPSEC_ESP type specifies IP packet confidentiality.  Data
  358.    origin authentication, if required, must be provided as part of the
  359.    ESP transform.  The default ESP transform includes data origin
  360.    authentication, confidentiality, and replay prevention.
  361.  
  362. 4.4.2 IPSEC ISAKMP Transform Values
  363.  
  364.    As part of an ISAKMP Phase I negotiation, the initiator's choice of
  365.    Key Exchange offerings is made using some host system policy
  366.    description.  The actual selection of Key Exchange mechanism is made
  367.    using the standard ISAKMP Proposal Payload.  The following table
  368.    lists the defined ISAKMP Phase I Transform Identifiers for the
  369.    Proposal Payload for the IPSEC DOI.
  370.  
  371.        Transform                           Value
  372.        ---------                           -----
  373.        RESERVED                            0
  374.        KEY_OAKLEY                          1
  375.        KEY_MANUAL                          2
  376.        KEY_KDC                             3
  377.  
  378.    The size of this field is one octet.  The values 4-248 are reserved
  379.    to IANA.  Values 249-255 are reserved for private use.
  380.  
  381. 4.4.2.1 KEY_OAKLEY
  382.  
  383.    The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
  384.    key exchange as defined in the [IO] document.  All implementations
  385.    within the IPSEC DOI MUST support KEY_OAKLEY.
  386.  
  387. 4.4.2.2 KEY_MANUAL
  388.  
  389.    The KEY_MANUAL type specifies that a shared secret key mechanism is
  390.  
  391.  
  392.  
  393. Piper                     Expires in 6 months               [Page 7]
  394.  
  395. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  396.  
  397.  
  398.    to be used in lieu of a dynamic key mechanism.  Specific details of a
  399.    static key establishment protocol will be described in a future
  400.    document.
  401.  
  402. 4.4.2.3 KEY_KDC
  403.  
  404.    The KEY_KDC type specifies that a secret-key based Key Distribution
  405.    Center will be used to provide dynamic key exchange through a
  406.    Kerberos-like ticket protocol.  Specific details of a KDC-based key
  407.    establishment protocol will be described in a future document.
  408.  
  409. 4.4.3 IPSEC AH Transform Values
  410.  
  411.    The Authentication Header Protocol (AH) defines one mandatory and
  412.    several optional transforms used to provide data origin
  413.    authentication.  The following table lists the defined AH Transform
  414.    Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI.
  415.  
  416.        Transform ID                        Value
  417.        ------------                        -----
  418.        RESERVED                            0
  419.        AH_MD5_KPDK                         1
  420.        AH_MD5                              2
  421.        AH_SHA                              3
  422.  
  423.    The size of this field is one octet.  The values 4-248 are reserved
  424.    to IANA.  Values 249-255 are reserved for private use.
  425.  
  426. 4.4.3.1 AH_MD5_KPDK
  427.  
  428.    The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key)
  429.    described in RFC-1826 and RFC-1828.  This mode MAY be used for
  430.    compatibility with existing implementations.  Implementations are not
  431.    required to support this mode.
  432.  
  433. 4.4.3.2 AH_MD5
  434.  
  435.    The AH_MD5 type specifies a generic AH transform using MD5.  The
  436.    actual protection suite is determined in concert with an associated
  437.    SA attribute list.  A generic MD5 transform is currently undefined.
  438.  
  439.    All implementations within the IPSEC DOI MUST support AH_MD5 along
  440.    with the HMAC and REPLAY attributes.  This suite is defined as the
  441.    HMAC-MD5 transform described in RFC-2085.
  442.  
  443. 4.4.3.3 AH_SHA
  444.  
  445.    The AH_SHA type specifies a generic AH transform using SHA-1.  The
  446.  
  447.  
  448.  
  449. Piper                     Expires in 6 months               [Page 8]
  450.  
  451. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  452.  
  453.  
  454.    actual protection suite is determined in concert with an associated
  455.    SA attribute list.  A generic SHA transform is currently undefined.
  456.  
  457.    All implementations within the IPSEC DOI are strongly encouraged to
  458.    support AH_SHA along with the HMAC and REPLAY attributes.  This suite
  459.    is defined as the HMAC-SHA transform described in [HMACSHA].
  460.  
  461. 4.4.4 IPSEC ESP Transform Identifiers
  462.  
  463.    The Encapsulating Security Protocol (ESP) defines one mandatory and
  464.    several optional transforms used to provide data confidentiality.
  465.    The following table lists the defined ESP Transform Identifiers for
  466.    the ISAKMP Proposal Payload for the IPSEC DOI.
  467.  
  468.        Transform ID                        Value
  469.        ------------                        -----
  470.        RESERVED                            0
  471.        ESP_DES_CBC                         1
  472.        ESP_DES                             2
  473.        ESP_3DES                            3
  474.        ESP_RC5                             4
  475.  
  476.    The size of this field is one octet.  The values 5-248 are reserved
  477.    to IANA.  Values 249-255 are reserved for private use.
  478.  
  479. 4.4.4.1 ESP_DES_CBC
  480.  
  481.    The ESP_DES_CBC type specifies the DES-CBC transform defined in RFC-
  482.    1827 and RFC-1829.  This mode MAY be used for compatibility with
  483.    existing implementations.  Implementations are not required to
  484.    support this mode.
  485.  
  486. 4.4.4.2 ESP_DES
  487.  
  488.    The ESP_DES type specifies a generic DES transform using DES-CBC.
  489.    The actual protection suite is determined in concert with an
  490.    associated SA attribute list.  A generic transform is currently
  491.    undefined.
  492.  
  493.    All implementations within the IPSEC DOI MUST support ESP_DES along
  494.    with the HMAC and REPLAY attributes.  This suite is defined as the
  495.    [Hughes] transform.
  496.  
  497. 4.4.4.3 ESP_3DES
  498.  
  499.    The ESP_3DES type specifies a generic triple-DES transform.  The
  500.    actual protection suite is determined in concert with an associated
  501.    SA attribute list.  The generic transform is currently undefined.
  502.  
  503.  
  504.  
  505. Piper                     Expires in 6 months               [Page 9]
  506.  
  507. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  508.  
  509.  
  510.    All implementations within the IPSEC are strongly encouraged to
  511.    support ESP_3DES along with the HMAC and REPLAY attributes.  This
  512.    suite is defined as the [Naganand] transform.
  513.  
  514. 4.4.4.4 ESP_RC5
  515.  
  516.    The ESP_RC5 type specifies the RC5 transform defined in [RC5].
  517.  
  518. 4.5 IPSEC Security Association Attributes
  519.  
  520.    The following SA attribute definitions are used in phase II of an
  521.    ISAKMP/Oakley negotiation.  Attribute types can be either Basic (B)
  522.    or Variable-Length (V).  Encoding of these attributes is defined in
  523.    the base ISAKMP specification.
  524.  
  525.        Attribute Classes
  526.  
  527.              class               value           type
  528.        -------------------------------------------------
  529.        Auth Key Life Type          1               B
  530.        Auth Key Life Duration      2               B/V
  531.        Enc Key Life Type           3               B
  532.        Enc Key Life Duration       4               B/V
  533.        SA Life Type                5               B
  534.        SA Life Duration            6               B/V
  535.        Replay Protection           7               B
  536.        Group Description           8               B
  537.        CA Distinguished Name       9               B
  538.        Encapsulation Mode          10              B
  539.        HMAC Algorithm              11              B
  540.  
  541.        Class Values
  542.  
  543.          Auth Key Life Type
  544.          Auth Key Duration
  545.  
  546.            Specifies the time-to-live for the authentication key(s)
  547.            used in the corresponding AH HMAC transform.
  548.  
  549.          Enc Key Life Type
  550.          Enc Key Duration
  551.  
  552.            Specifies the time-to-live for the encryption key(s)
  553.            using in the corresponding ESP transform.
  554.  
  555.          SA Life Type
  556.          SA Duration
  557.  
  558.  
  559.  
  560.  
  561. Piper                     Expires in 6 months              [Page 10]
  562.  
  563. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  564.  
  565.  
  566.            Specifies the time-to-live for the overall security
  567.            association.  When the SA expires, all keys negotiated
  568.            under the association (AH or ESP) must be renegotiated
  569.            regardless of the time-to-live remaining for the keys.
  570.  
  571.            RESERVED                0
  572.            seconds                 1
  573.            kilobytes               2
  574.  
  575.            Values 3-61439 are reserved to IANA.  Values 61440-65535
  576.            are for experimental use.  For a given "Life Type," the
  577.            value of the "Life Duration" attribute defines the actual
  578.            length of the component lifetime -- either a number of
  579.            seconds, or a number of Kbytes that can be protected.
  580.  
  581.            If unspecified, the default value shall be assumed to be
  582.            28800 seconds (8 hours) for Auth, Enc, and SA lifetime.
  583.  
  584.          Replay Protection
  585.            RESERVED                0
  586.            required                1
  587.            disallowed              2
  588.  
  589.            Values 3-61439 are reserved to IANA.  Values 61440-65535
  590.            are for private use among mutually consenting parties.
  591.  
  592.            There is no default value for Replay Protection, as it
  593.            must be specified to correctly identify the applicable
  594.            transform.
  595.  
  596.          Group Description
  597.            RESERVED                0
  598.            default group           1
  599.  
  600.            Values 2-61439 are reserved to IANA.  Values 61440-65535
  601.            are for private use among mutually consenting parties.
  602.  
  603.            If unspecified, the default value shall be assumed to be
  604.            the default Oakley group ([IO], Section 5.5.1).
  605.  
  606.          CA Distinguished Name
  607.            RESERVED                0
  608.            DNS Security            1
  609.  
  610.            Values 2-61439 are reserved to IANA.  Values 61440-65535
  611.            are for private use among mutually consenting parties.
  612.  
  613.            If unspecified, the default value shall be assumed to be
  614.  
  615.  
  616.  
  617. Piper                     Expires in 6 months              [Page 11]
  618.  
  619. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  620.  
  621.  
  622.            DNS Security (Section 4.8).
  623.  
  624.          Encapsulation Mode
  625.            RESERVED                0
  626.            Tunnel                  1
  627.            Transport               2
  628.  
  629.            Values 3-61439 are reserved to IANA.  Values 61440-65535
  630.            are for private use among mutually consenting parties.
  631.  
  632.            If unspecified, the default value shall be assumed to be
  633.            unspecified (host-dependent).
  634.  
  635.          HMAC Algorithm
  636.            RESERVED                0
  637.            MD5                     1
  638.            SHA-1                   2
  639.  
  640.            Values 3-61439 are reserved to IANA.  Values 61440-65535
  641.            are for private use among mutually consenting parties.
  642.  
  643.            There is no default value for HMAC Algorithm, as it
  644.            must be specified to correctly identify the applicable
  645.            transform.
  646.  
  647. 4.5.1 Required Attribute Support
  648.  
  649.    To ensure basic interoperability, all implementations MUST support
  650.    all of the following attributes:
  651.  
  652.            Auth Key Life Type
  653.            Auth Key Duration
  654.            Enc Key Life Type
  655.            Enc Key Duration
  656.            SA Life Type
  657.            SA Duration
  658.            Replay Protection
  659.            HMAC Algorithm (MD5 required, SHA-1 optional)
  660.  
  661. 4.5.2 Attribute List Parsing Requirement
  662.  
  663.    To allow for flexible semantics, the IPSEC DOI requires that a
  664.    conforming ISAKMP implementation MUST correctly parse an attribute
  665.    list that contains multiple instances of the same attribute class, so
  666.    long as the different attribute entries do not conflict with one
  667.    another.
  668.  
  669.    To see why this is important, the following example shows the binary
  670.  
  671.  
  672.  
  673. Piper                     Expires in 6 months              [Page 12]
  674.  
  675. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  676.  
  677.  
  678.    encoding of a four entry attribute list that specifies an Encryption
  679.    Key Lifetime of either 100MB or 24 hours.  (See Section 3.3 of
  680.    [ISAKMP] for a complete description of the attribute encoding
  681.    format.)
  682.  
  683.      Attribute #1:
  684.        0x80030001  (AF = 1, type = Enc Key Life Type, value = seconds)
  685.  
  686.      Attribute #2:
  687.        0x00040004  (AF = 0, type = Enc Key Duration, length = 4 bytes)
  688.        0x00015180  (value = 0x15180 = 86400 seconds = 24 hours)
  689.  
  690.      Attribute #3:
  691.        0x80030002  (AF = 1, type = Enc Key Life Type, value = KB)
  692.  
  693.      Attribute #4:
  694.        0x00040004  (AF = 0, type = Enc Key Duration, length = 4 bytes)
  695.        0x000186A0  (value = 0x186A0 = 100000KB = 100MB)
  696.  
  697.    If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED
  698.    Notification Payload SHOULD be returned and the security association
  699.    setup MUST be aborted.
  700.  
  701. 4.6 IPSEC Payload Content
  702.  
  703.    The following sections describe those ISAKMP payloads whose data
  704.    representations are dependent on the applicable DOI.
  705.  
  706. 4.6.1 Security Association Payload
  707.  
  708.    The following diagram illustrates the content of the Security
  709.    Association Payload for the IPSEC DOI.  See Section 4.2 for a
  710.    description of the Situation bitmap.
  711.  
  712.     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
  713.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  714.    !  Next Payload !   RESERVED    !        Payload Length         !
  715.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  716.    !                Domain of Interpretation (IPSEC)               |
  717.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  718.    !                       Situation (bitmap)                      !
  719.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  720.    !                    Labeled Domain Identifier                  !
  721.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  722.    !  Secrecy Length (in octets)   !           RESERVED            !
  723.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  724.    ~                        Secrecy Level                          ~
  725.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  726.  
  727.  
  728.  
  729. Piper                     Expires in 6 months              [Page 13]
  730.  
  731. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  732.  
  733.  
  734.    ! Secrecy Cat. Length (in bits) !           RESERVED            !
  735.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  736.    ~                    Secrecy Category Bitmap                    ~
  737.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  738.    ! Integrity Length (in octets)  !           RESERVED            !
  739.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  740.    ~                       Integrity Level                         ~
  741.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  742.    ! Integ. Cat. Length (in bits)  !           RESERVED            !
  743.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  744.    ~                  Integrity Category Bitmap                    ~
  745.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  746.  
  747.                Figure 1: Security Association Payload Format
  748.  
  749.    The Security Association Payload is defined as follows:
  750.  
  751.      o  Next Payload (2 octets) - Identifier for the payload type of
  752.         the next payload in the message.  If the current payload is
  753.         the last in the message, this field will be zero (0).
  754.  
  755.      o  RESERVED (1 octet) - Unused, must be zero (0).
  756.  
  757.      o  Payload Length (2 octets) - Length, in octets, of the current
  758.         payload, including the generic header.
  759.  
  760.      o  Domain of Interpretation (4 octets) - Specifies the IPSEC DOI,
  761.         which has been assigned the value one (1).
  762.  
  763.      o  Situation (4 octets) - Bitmask used to interpret the
  764.         remainder of the Security Association Payload.  See Section
  765.         4.2 for a complete list of values.
  766.  
  767.      o  Labeled Domain Identifier (4 octets) - IANA Assigned Number
  768.         used to interpret the Secrecy and Integrity information.
  769.  
  770.      o  Secrecy Length (2 octets) - Specifies the length, in octets,
  771.         of the secrecy level identifier.
  772.  
  773.      o  Secrecy Category Length (2 octets) - Specifies the length, in
  774.         bits, of the secrecy category (compartment) bitmap.
  775.  
  776.      o  Secrecy Category Bitmap (variable length) - A bitmap used to
  777.         designate secrecy categories (compartments) that are
  778.         required.
  779.  
  780.      o  Integrity Length (2 octets) - Specifies the length, in
  781.         octets, of the integrity level identifier.
  782.  
  783.  
  784.  
  785. Piper                     Expires in 6 months              [Page 14]
  786.  
  787. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  788.  
  789.  
  790.      o  Integrity Category Length (2 octets) - Specifies the length,
  791.         in bits, of the integrity category (compartment) bitmap.
  792.  
  793.      o  Integrity Category Bitmap (variable length) - A bitmap used
  794.         to designate integrity categories (compartments) that are
  795.         required.
  796.  
  797. 4.6.1.1 Labeled Domain Identifier Values
  798.  
  799.    The following table lists the assigned values for the Labeled Domain
  800.    Identifier field contained in the Situation field of the Security
  801.    Association Payload.
  802.  
  803.        Domain                              Value
  804.        -------                             -----
  805.        RESERVED                            0
  806.  
  807.    The values 1-0x7fffffff are reserved to IANA.  Values 0x8000000-
  808.    0xffffffff are reserved for private use.
  809.  
  810. 4.6.2 Identification Payload Content
  811.  
  812.    The Identification Payload is used to identify the initiator of the
  813.    Security Association.  The identity of the initiator SHOULD be used
  814.    by the responder to determine the correct host system security policy
  815.    requirement for the association.  For example, a host might choose to
  816.    require data origin authentication without confidentiality (AH) from
  817.    a certain set of IP addresses and full authentication with
  818.    confidentiality (Hughes) from another range of IP addresses.  The
  819.    Identification Payload provides information that can be used by the
  820.    responder to make this decision.
  821.  
  822.    The following diagram illustrates the content of the Identification
  823.    Payload.
  824.  
  825.     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
  826.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  827.    !  Next Payload !   RESERVED    !        Payload Length         !
  828.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  829.    !   ID Type     !  Protocol ID  !             Port              !
  830.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  831.    ~                     Identification Data                       ~
  832.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  833.  
  834.                   Figure 2: Identification Payload Format
  835.  
  836.    The Identification Payload field is defined as follows:
  837.  
  838.  
  839.  
  840.  
  841. Piper                     Expires in 6 months              [Page 15]
  842.  
  843. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  844.  
  845.  
  846.      o  Next Payload (2 octets) - Identifier for the payload type of
  847.         the next payload in the message.  If the current payload is
  848.         the last in the message, this field will be zero (0).
  849.  
  850.      o  RESERVED (1 octet) - Unused, must be zero (0).
  851.  
  852.      o  Payload Length (2 octets) - Length, in octets, of the
  853.         identification data, including the generic header.
  854.  
  855.      o  Identification Type (1 octet) - Value describing the
  856.         identity information found in the Identification Data field.
  857.  
  858.      o  Protocol ID (1 octet) - Value specifying an associated
  859.         IP protocol ID (e.g. UDP/TCP).  A value of zero means that the
  860.         Protocol ID field should be ignored.
  861.  
  862.      o  Port (2 octets) - Value specifying an associated port.
  863.         A value of zero means that the Port field should be ignored.
  864.  
  865.      o  RESERVED (1 octet) - Unused, must be zero (0).
  866.  
  867. 4.6.2.1 Identification Type Values
  868.  
  869.    The following table lists the assigned values for the Identification
  870.    Type field found in the Identification Payload.
  871.  
  872.        ID Type                             Value
  873.        -------                             -----
  874.        RESERVED                            0
  875.        ID_IPV4_ADDR                        1
  876.        ID_FQDN                             2
  877.        ID_USER_FQDN                        3
  878.        ID_IPV4_ADDR_SUBNET                 4
  879.        ID_IPV6_ADDR                        5
  880.        ID_IPV6_ADDR_SUBNET                 6
  881.        ID_IPV4_ADDR_RANGE                  7
  882.        ID_IPV6_ADDR_RANGE                  8
  883.  
  884.    The size of this field is one octet.  The values 9-248 are reserved
  885.    to IANA.  Values 249-255 are reserved for private use.
  886.  
  887. 4.6.2.2 ID_IPV4_ADDR
  888.  
  889.    The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
  890.  
  891. 4.6.2.3 ID_FQDN
  892.  
  893.    The ID_FQDN type specifies a fully-qualified domain name string.  An
  894.  
  895.  
  896.  
  897. Piper                     Expires in 6 months              [Page 16]
  898.  
  899. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  900.  
  901.  
  902.    example of a ID_FQDN is, "foo.bar.com".
  903.  
  904. 4.6.2.4 ID_USER_FQDN
  905.  
  906.    The ID_USER_FQDN type specifies a fully-qualified username string, An
  907.    example of a ID_USER_FQDN is, "piper@foo.bar.com".
  908.  
  909. 4.6.2.5 ID_IPV4_ADDR_SUBNET
  910.  
  911.    The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses,
  912.    represented by two four (4) octet values.  The first value is an IPv4
  913.    address.  The second is an IPv4 network mask.  Note that ones (1s) in
  914.    the network mask indicate that the corresponding bit in the address
  915.    is fixed, while zeros (0s) indicate a "wildcard" bit.
  916.  
  917. 4.6.2.6 ID_IPV6_ADDR
  918.  
  919.    The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
  920.    address.
  921.  
  922. 4.6.2.7 ID_IPV6_ADDR_SUBNET
  923.  
  924.    The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses,
  925.    represented by two sixteen (16) octet values.  The first value is an
  926.    IPv6 address.  The second is an IPv6 network mask.  Note that ones
  927.    (1s) in the network mask indicate that the corresponding bit in the
  928.    address is fixed, while zeros (0s) indicate a "wildcard" bit.
  929.  
  930. 4.6.2.8 ID_IPV4_ADDR_RANGE
  931.  
  932.    The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses,
  933.    represented by two four (4) octet values.  The first value is the
  934.    beginning IPv4 address (inclusive) and the second value is the ending
  935.    IPv4 address (inclusive).  All addresses falling between the two
  936.    specified addresses are considered to be within the list.
  937.  
  938. 4.6.2.9 ID_IPV6_ADDR_RANGE
  939.  
  940.    The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses,
  941.    represented by two sixteen (16) octet values.  The first value is the
  942.    beginning IPv6 address (inclusive) and the second value is the ending
  943.    IPv6 address (inclusive).  All addresses falling between the two
  944.    specified addresses are considered to be within the list.
  945.  
  946. 4.7 IPSEC Security Parameter Index (SPI) Encoding
  947.  
  948.    ISAKMP defines the SPI field as eight octets in length, however the
  949.    IPSEC transforms use only four octets.
  950.  
  951.  
  952.  
  953. Piper                     Expires in 6 months              [Page 17]
  954.  
  955. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  956.  
  957.  
  958.    All implementation MUST use the following mapping for the ISAKMP SPI
  959.    field in the IPSEC DOI.
  960.  
  961.     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
  962.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  963.    !                             SPI                               !
  964.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  965.    !                           RESERVED                            !
  966.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  967.  
  968.                        Figure 3: ISAKMP SPI Encoding
  969.  
  970.    The ISAKMP SPI field is defined as follows:
  971.  
  972.      o  SPI - Security Parameter Index (4 octets) - contains the
  973.         SPI value which identifies the security association.
  974.  
  975.      o  RESERVED (4 octets) - Unused, must be zero (0).
  976.  
  977. 4.8 IPSEC Certificate Authorities
  978.  
  979.    The ISAKMP Certificate Request Payload allows either side of an
  980.    ISAKMP negotiation to request its peer to provide a certificate chain
  981.    needed to authenticate itself.  The Certificate Request Payload
  982.    includes a list of acceptable Certificate Types and Certificate
  983.    Authorities.  Appropriate certificate chains are then returned in a
  984.    Certificate Payload response.
  985.  
  986.    The IPSEC DOI defines the following Certificate Authorities for the
  987.    processing of Certificate Request Payloads.  See Section 4.5 for
  988.    details on the specific data attribute type values for these CAs.
  989.  
  990.        Certificate Authority
  991.        ---------------------
  992.        DNS Security
  993.  
  994.    4.8.1 DNS Security
  995.  
  996.    This CA type represents the combination of KEY and SIG records, as
  997.    defined in RFC-2065, that can be used for authentication.  The
  998.    particular encoding required to formulate the Certificate Payload
  999.    (response) is TBD.
  1000.  
  1001. 4.9 IPSEC Key Exchange Requirements
  1002.  
  1003.    The IPSEC DOI introduces no additional Key Exchange types.
  1004.  
  1005. 5. Security Considerations
  1006.  
  1007.  
  1008.  
  1009. Piper                     Expires in 6 months              [Page 18]
  1010.  
  1011. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  1012.  
  1013.  
  1014.    This entire draft pertains to a hybrid protocol, combining Oakley
  1015.    ([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate and derive keying
  1016.    material for security associations in a secure and authenticated
  1017.    manner.  Specific discussion of the various security protocols and
  1018.    transforms identified in this document can be found in the associated
  1019.    base documents.
  1020.  
  1021. Acknowledgements
  1022.  
  1023.    This document is derived, in part, from previous works by Douglas
  1024.    Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,
  1025.    and Dave Carrel.
  1026.  
  1027. References
  1028.  
  1029.    [RFC-1825] Atkinson, R., "Security Architecture for the Internet
  1030.    Protocol," RFC-1825, August 1995.
  1031.  
  1032.    [RFC-1826] Atkinson, R., "IP Authentication Header," RFC-1826, August
  1033.    1995.
  1034.  
  1035.    [RFC-1827] Atkinson, R., "IP Encapsulating Security Payload (ESP),"
  1036.    RFC-1827, August 1995.
  1037.  
  1038.    [RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed
  1039.    MD5," RFC-1828, August 1995.
  1040.  
  1041.    [RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC
  1042.    Transform," RFC-1829, August 1995.
  1043.  
  1044.    [RFC-2065] Eastlake 3rd, D., Kaufman, C., "Domain Name System
  1045.    Security Extensions," RFC-2065, January 1997.
  1046.  
  1047.    [RFC-2085] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with
  1048.    Replay Prevention," RFC-2085, February 1997.
  1049.  
  1050.    [HMACSHA] Chang, S., Glenn, R., "HMAC-SHA IP Authentication with
  1051.    Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-03.txt.
  1052.  
  1053.    [Hughes] Hughes, J., Editor, "Combined DES-CBC, HMAC and Replay
  1054.    Prevention Transform," draft-ietf-ipsec-esp-des-md5-03.txt.
  1055.  
  1056.    [IO] Carrel, D., Harkins, D., "The Resolution of ISAKMP with Oakley,"
  1057.    draft-ietf-ipsec-isakmp-oakley-03.txt.
  1058.  
  1059.    [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
  1060.    "Internet Security Association and Key Management Protocol (ISAKMP),"
  1061.    draft-ietf-ipsec-isakmp-07.{ps,txt}.
  1062.  
  1063.  
  1064.  
  1065. Piper                     Expires in 6 months              [Page 19]
  1066.  
  1067. INTERNET DRAFT                 IPSEC DOI               February 28, 1997
  1068.  
  1069.  
  1070.    [Naganand] Daraswamy, N., "Combined 3DES-CBC, HMAC and Replay
  1071.    Detection Security Transform," draft-ietf-ipsec-esp-3des-md5-00.txt.
  1072.  
  1073.    [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"
  1074.    draft-ietf-ipsec-oakley-01.txt.
  1075.  
  1076.    [PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key
  1077.    Management API, Version 2", draft-mcdonald-pf-key-v2-00.txt, work in
  1078.    progress.
  1079.  
  1080.    [RC5] Howard, B., Baldwin, R., "The ESP RC5-CBC Transform," draft-
  1081.    baldwin-esp-rc5-00.txt.
  1082.  
  1083. Author's Address:
  1084.  
  1085.    Derrell Piper <piper@cisco.com>
  1086.    cisco Systems
  1087.    101 Cooper St.
  1088.    Santa Cruz, California, 95060
  1089.    United States of America
  1090.    +1 408 457-5384
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121. Piper                     Expires in 6 months              [Page 20]
  1122.  
  1123.