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-04.txt < prev    next >
Text File  |  1997-09-22  |  50KB  |  1,400 lines
  1.  
  2.  
  3. Network Working Group                                      Derrell Piper
  4. INTERNET-DRAFT                                             cisco Systems
  5. draft-ietf-ipsec-ipsec-doi-04.txt                     September 19, 1997
  6.  
  7.  
  8.       The Internet IP Security Domain of Interpretation for ISAKMP
  9.                   <draft-ietf-ipsec-ipsec-doi-04.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 inappropriate 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.    For a description of how the IPSEC DOI fits into the overall IP
  46.    Security Documentation framework, please see [ROADMAP].
  47.  
  48.    For a list of changes since the previous version of the IPSEC DOI,
  49.    please see Section 5.
  50.  
  51.  
  52.  
  53.  
  54. Piper                     Expires in 6 months               [Page 1]
  55.  
  56. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  57.  
  58.  
  59. 2. Introduction
  60.  
  61.    Within ISAKMP, a Domain of Interpretation is used to group related
  62.    protocols using ISAKMP to negotiate security associations.  Security
  63.    protocols sharing a DOI choose security protocol and cryptographic
  64.    transforms from a common namespace and share key exchange protocol
  65.    identifiers.  They also share a common interpretation of DOI-specific
  66.    payload data content, including the Security Association and
  67.    Identification payloads.
  68.  
  69.    Overall, ISAKMP places the following requirements on a DOI
  70.    definition:
  71.  
  72.      o  define the naming scheme for DOI-specific protocol identifiers
  73.      o  define the interpretation for the Situation field
  74.      o  define the set of applicable security policies
  75.      o  define the syntax for DOI-specific SA Attributes (phase II)
  76.      o  define the syntax for DOI-specific payload contents
  77.      o  define additional Key Exchange types, if needed
  78.      o  define additional Notification Message types, if needed
  79.  
  80.    The remainder of this document details the instantiation of these
  81.    requirements for using the IP Security (IPSEC) protocols to provide
  82.    authentication, integrity, and/or confidentiality for IP packets sent
  83.    between cooperating host systems and/or firewalls.
  84.  
  85. 3. Terms and Definitions
  86.  
  87. 3.1 Requirements Terminology
  88.  
  89.    In this document, the words that are used to define the significance
  90.    of each particular requirement are usually capitalized.  These words
  91.    are:
  92.  
  93.    - MUST
  94.  
  95.       This word or the adjective "REQUIRED" means that the item is an
  96.       absolute requirement of the specification.
  97.  
  98.    - SHOULD
  99.  
  100.       This word or the adjective "RECOMMENDED" means that there might
  101.       exist valid reasons in particular circumstances to ignore this
  102.       item, but the full implications should be understood and the case
  103.       carefully weighed before taking a different course.
  104.  
  105.    - MAY
  106.  
  107.  
  108.  
  109.  
  110. Piper                     Expires in 6 months               [Page 2]
  111.  
  112. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  113.  
  114.  
  115.       This word or the adjective "OPTIONAL" means that this item is
  116.       truly optional.  One vendor might choose to include the item
  117.       because a particular marketplace requires it or because it
  118.       enhances the product, for example; another vendor may omit the
  119.       same item.
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166. Piper                     Expires in 6 months               [Page 3]
  167.  
  168. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  169.  
  170.  
  171. 4.1 IPSEC Naming Scheme
  172.  
  173.    Within ISAKMP, all DOI's must be registered with the IANA in the
  174.    ``Assigned Numbers'' RFC [STD-2].  The IANA Assigned Number for the
  175.    Internet IP Security DOI is one (1).  Within the IPSEC DOI, all
  176.    well-known identifiers MUST be registered with the IANA under the
  177.    Internet IP Security DOI.  Unless otherwise noted, all tables within
  178.    this document refer to IANA Assigned Numbers for the IPSEC DOI.
  179.  
  180.    All multi-octet binary values are stored in network byte order.
  181.  
  182. 4.2 IPSEC Situation Definition
  183.  
  184.    Within ISAKMP, the Situation provides information that can be used by
  185.    the responder to make a policy determination about how to process the
  186.    incoming Security Association request.  For the IPSEC DOI, the
  187.    Situation field is a four (4) octet bitmask with the following
  188.    values.
  189.  
  190.        Situation                   Value
  191.        ---------                   -----
  192.        SIT_IDENTITY_ONLY           0x01
  193.        SIT_SECRECY                 0x02
  194.        SIT_INTEGRITY               0x04
  195.  
  196.    All other values are reserved to IANA.
  197.  
  198. 4.2.1 SIT_IDENTITY_ONLY
  199.  
  200.    The SIT_IDENTITY_ONLY type specifies that the security association
  201.    will be identified by source identity information present in an
  202.    associated Identification Payload.  See Section 4.6.2 for a complete
  203.    description of the various Identification types.  All IPSEC DOI
  204.    implementations MUST support SIT_IDENTITY_ONLY by including an
  205.    Identification Payload in at least one of the phase I Oakley
  206.    exchanges ([IO], Section 5) and MUST abort any association setup that
  207.    does not include an Identification Payload.
  208.  
  209.    If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the
  210.    situation consists only of the 4 octet situation bitmap and does not
  211.    include the Labeled Domain Identifier field (Figure 1, Section 4.6.1)
  212.    or any subsequent label information.  Conversely, if the initiator
  213.    supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain
  214.    Identifier MUST be included in the situation payload.
  215.  
  216. 4.2.2 SIT_SECRECY
  217.  
  218.    The SIT_SECRECY type specifies that the security association is being
  219.  
  220.  
  221.  
  222. Piper                     Expires in 6 months               [Page 4]
  223.  
  224. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  225.  
  226.  
  227.    negotiated in an environment that requires labeled secrecy.  If
  228.    SIT_SECRECY is present in the Situation bitmap, the Situation field
  229.    will be followed by variable-length data that includes a sensitivity
  230.    level and compartment bitmask.  See Section 4.6.1 for a complete
  231.    description of the Security Association Payload format.
  232.  
  233.    If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be
  234.    set in the Situation bitmap and no secrecy level or category bitmaps
  235.    shall be included.
  236.  
  237.    If a responder does not support SIT_SECRECY, a SITUATION-NOT-
  238.    SUPPORTED Notification Payload SHOULD be returned and the security
  239.    association setup MUST be aborted.
  240.  
  241. 4.2.3 SIT_INTEGRITY
  242.  
  243.    The SIT_INTEGRITY type specifies that the security association is
  244.    being negotiated in an environment that requires labeled integrity.
  245.    If SIT_INTEGRITY is present in the Situation bitmap, the Situation
  246.    field will be followed by variable-length data that includes an
  247.    integrity level and compartment bitmask.  If SIT_SECRECY is also in
  248.    use for the association, the integrity information immediately
  249.    follows the variable-length secrecy level and categories.  See
  250.    section 4.6.1 for a complete description of the Security Association
  251.    Payload format.
  252.  
  253.    If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST
  254.    NOT be set in the Situation bitmap and no integrity level or category
  255.    bitmaps shall be included.
  256.  
  257.    If a responder does not support SIT_INTEGRITY, a SITUATION-NOT-
  258.    SUPPORTED Notification Payload SHOULD be returned and the security
  259.    association setup MUST be aborted.
  260.  
  261. 4.3 IPSEC Security Policy Requirements
  262.  
  263.    The IPSEC DOI does not impose specific security policy requirements
  264.    on any implementation.  Host system policy issues are outside of the
  265.    scope of this document.
  266.  
  267.    However, the following sections touch on some of the issues that must
  268.    be considered when designing an IPSEC DOI host implementation.  This
  269.    section should be considered only informational in nature.
  270.  
  271. 4.3.1 Key Management Issues
  272.  
  273.    It is expected that many systems choosing to implement ISAKMP will
  274.    strive to provide a protected domain of execution for a combined
  275.  
  276.  
  277.  
  278. Piper                     Expires in 6 months               [Page 5]
  279.  
  280. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  281.  
  282.  
  283.    ISAKMP/Oakley key management daemon.  On protected-mode multiuser
  284.    operating systems, this key management daemon will likely exist as a
  285.    separate privileged process.
  286.  
  287.    In such an environment, a formalized API to introduce keying material
  288.    into the TCP/IP kernel may be desirable.  The PF_KEY API [PFKEY] is
  289.    an example of one such API that provides an abstracted key management
  290.    interface.  The IP Security architecture does not place any
  291.    requirements for structure or flow between a host TCP/IP kernel and
  292.    its key management provider.
  293.  
  294. 4.3.2 Static Keying Issues
  295.  
  296.    Host systems that implement static keys, either for use directly by
  297.    IPSEC, or for authentication purposes (see [IO] Section 5.3), should
  298.    take steps to protect the static keying material when it is not
  299.    residing in a protected memory domain or actively in use by the
  300.    TCP/IP kernel.
  301.  
  302.    For example, on a laptop, one might choose to store the static keys
  303.    in a configuration store that is, itself, encrypted under a private
  304.    password.
  305.  
  306.    Depending on the operating system and utility software installed, it
  307.    may not be possible to protect the static keys once they've been
  308.    loaded into the TCP/IP kernel, however they should not be trivially
  309.    recoverable on initial system startup without having to satisfy some
  310.    additional form of authentication.
  311.  
  312. 4.3.3 Host Policy Issues
  313.  
  314.    It is not realistic to assume that the transition to IPSEC will occur
  315.    overnight.  Host systems must be prepared to implement flexible
  316.    policy lists that describe which systems they desire to speak
  317.    securely with and which systems they require speak securely to them.
  318.    Some notion of proxy firewall addresses may also be required.
  319.  
  320.    A minimal approach is probably a static list of IP addresses, network
  321.    masks, and a security required flag or flags.
  322.  
  323.    A more flexible implementation might consist of a list of wildcard
  324.    DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional
  325.    firewall address.  The wildcard DNS name would be used to match
  326.    incoming or outgoing IP addresses, the in/out bitmask would be used
  327.    to determine whether or not security was to be applied and in which
  328.    direction, and the optional firewall address would be used to
  329.    indicate whether or not tunnel mode would be needed to talk to the
  330.    target system though an intermediate firewall.
  331.  
  332.  
  333.  
  334. Piper                     Expires in 6 months               [Page 6]
  335.  
  336. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  337.  
  338.  
  339. 4.3.4 Certificate Management
  340.  
  341.    Host systems implementing a certificate-based authentication scheme
  342.    will need a mechanism for obtaining and managing a database of
  343.    certificates.
  344.  
  345.    Secure DNS is to be one certificate distribution mechanism, however
  346.    the pervasive availability of secure DNS zones, in the short term, is
  347.    doubtful for many reasons.  What's far more likely is that hosts will
  348.    need an ability to import certificates that they acquire through
  349.    secure, out-of-band mechanisms, as well as an ability to export their
  350.    own certificates for use by other systems.
  351.  
  352.    However, manual certificate management should not be done so as to
  353.    preclude the ability to introduce dynamic certificate discovery
  354.    mechanisms and/or protocols as they become available.
  355.  
  356. 4.4 IPSEC Assigned Numbers
  357.  
  358.    The following sections list the Assigned Numbers for the IPSEC DOI
  359.    Security Protocol Identifiers, Transform Identifiers, and Security
  360.    Association Attribute Types.
  361.  
  362. 4.4.1 IPSEC Security Protocol Identifiers
  363.  
  364.    The ISAKMP proposal syntax was specifically designed to allow for the
  365.    simultaneous negotiation of multiple security protocol suites within
  366.    a single negotiation.  As a result, the protocol suites listed below
  367.    form the set of protocols that can be negotiated at the same time.
  368.    It is a host policy decision as to what protocol suites might be
  369.    negotiated together.
  370.  
  371.    The following table lists the values for the Security Protocol
  372.    Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
  373.    DOI.
  374.  
  375.        Protocol ID                         Value
  376.        -----------                         -----
  377.        RESERVED                            0
  378.        PROTO_ISAKMP                        1
  379.        PROTO_IPSEC_AH                      2
  380.        PROTO_IPSEC_ESP                     3
  381.        PROTO_IPCOMP                        4
  382.  
  383.    The size of this field is one octet.  The values 5-248 are reserved
  384.    to IANA.  Values 249-255 are reserved for private use.
  385.  
  386. 4.4.1.1 PROTO_ISAKMP
  387.  
  388.  
  389.  
  390. Piper                     Expires in 6 months               [Page 7]
  391.  
  392. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  393.  
  394.  
  395.    The PROTO_ISAKMP type specifies message protection required during
  396.    Phase I of the ISAKMP protocol.  The specific protection mechanism
  397.    used for the IPSEC DOI is described in [IO].  All implementations
  398.    within the IPSEC DOI MUST support PROTO_ISAKMP.
  399.  
  400.    NB: ISAKMP reserves the value one (1) across all DOI definitions.
  401.  
  402. 4.4.1.2 PROTO_IPSEC_AH
  403.  
  404.    The PROTO_IPSEC_AH type specifies IP packet authentication.  The
  405.    default AH transform provides data origin authentication, integrity
  406.    protection, and replay prevention.  For export control
  407.    considerations, confidentiality MUST NOT be provided by any
  408.    PROTO_IPSEC_AH transform.
  409.  
  410. 4.4.1.3 PROTO_IPSEC_ESP
  411.  
  412.    The PROTO_IPSEC_ESP type specifies IP packet confidentiality.
  413.    Authentication, if required, must be provided as part of the ESP
  414.    transform.  The default ESP transform includes data origin
  415.    authentication, integrity protection, replay prevention, and
  416.    confidentiality.
  417.  
  418. 4.4.1.4 PROTO_IPCOMP
  419.  
  420.    The PROTO_IPCOMP type specifies IP packet compression.
  421.  
  422. 4.4.2 IPSEC ISAKMP Transform Values
  423.  
  424.    As part of an ISAKMP Phase I negotiation, the initiator's choice of
  425.    Key Exchange offerings is made using some host system policy
  426.    description.  The actual selection of Key Exchange mechanism is made
  427.    using the standard ISAKMP Proposal Payload.  The following table
  428.    lists the defined ISAKMP Phase I Transform Identifiers for the
  429.    Proposal Payload for the IPSEC DOI.
  430.  
  431.        Transform                           Value
  432.        ---------                           -----
  433.        RESERVED                            0
  434.        KEY_OAKLEY                          1
  435.  
  436.    The size of this field is one octet.  The values 2-248 are reserved
  437.    to IANA.  Values 249-255 are reserved for private use.
  438.  
  439.    Within the ISAKMP and IPSEC DOI framework it is possible to define
  440.    key establishment protocols other than Oakley.  Previous versions of
  441.    this document defined types both for manual keying and for schemes
  442.    based on use of a generic Key Distribution Center (KDC).  These
  443.  
  444.  
  445.  
  446. Piper                     Expires in 6 months               [Page 8]
  447.  
  448. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  449.  
  450.  
  451.    identifiers have been removed from the current document.
  452.  
  453.    The IPSEC DOI can still be extended later to include values for
  454.    additional non-Oakley key establishment protocols for ISAKMP and
  455.    IPSEC, such as Kerberos [RFC-1510] or the Group Key Management
  456.    Protocol (GKMP) [RFC-2093].
  457.  
  458. 4.4.2.1 KEY_OAKLEY
  459.  
  460.    The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
  461.    key exchange as defined in the [IO] document.  All implementations
  462.    within the IPSEC DOI MUST support KEY_OAKLEY.
  463.  
  464. 4.4.3 IPSEC AH Transform Values
  465.  
  466.    The Authentication Header Protocol (AH) defines one mandatory and
  467.    several optional transforms used to provide authentication,
  468.    integrity, and replay detection.  The following table lists the
  469.    defined AH Transform Identifiers for the ISAKMP Proposal Payload for
  470.    the IPSEC DOI.
  471.  
  472.        Transform ID                        Value
  473.        ------------                        -----
  474.        RESERVED                            0
  475.        AH_MD5_KPDK                         1
  476.        AH_MD5                              2
  477.        AH_SHA                              3
  478.        AH_DES                              4
  479.  
  480.    The size of this field is one octet.  The values 5-248 are reserved
  481.    to IANA.  Values 249-255 are reserved for private use.
  482.  
  483. 4.4.3.1 AH_MD5_KPDK
  484.  
  485.    The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key)
  486.    described in RFC-1826.  This mode MAY be negotiated for compatibility
  487.    with older implementations.  Implementations are not required to
  488.    support this mode.
  489.  
  490. 4.4.3.2 AH_MD5
  491.  
  492.    The AH_MD5 type specifies a generic AH transform using MD5.  The
  493.    actual protection suite is determined in concert with an associated
  494.    SA attribute list.  A generic MD5 transform is currently undefined.
  495.  
  496.    All implementations within the IPSEC DOI MUST support AH_MD5 along
  497.    with the Auth(HMAC-MD5) attribute.  This suite is defined as the
  498.    HMAC-MD5-96 transform described in [HMACMD5].
  499.  
  500.  
  501.  
  502. Piper                     Expires in 6 months               [Page 9]
  503.  
  504. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  505.  
  506.  
  507. 4.4.3.3 AH_SHA
  508.  
  509.    The AH_SHA type specifies a generic AH transform using SHA-1.  The
  510.    actual protection suite is determined in concert with an associated
  511.    SA attribute list.  A generic SHA transform is currently undefined.
  512.  
  513.    All implementations within the IPSEC DOI are strongly encouraged to
  514.    support AH_SHA along with the Auth(HMAC-SHA) attribute.  This suite
  515.    is defined as the HMAC-SHA-1-96 transform described in [HMACSHA].
  516.  
  517. 4.4.3.4 AH_DES
  518.  
  519.    The AH_DES type specifies a generic AH transform using DES.  The
  520.    actual protection suite is determined in concert with an associated
  521.    SA attribute list.  A generic DES transform is currently undefined.
  522.  
  523.  
  524.    The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute
  525.    to be the DES-MAC transform described in [DESMAC].  Implementations
  526.    are not required to support this mode.
  527.  
  528.  
  529. 4.4.4 IPSEC ESP Transform Identifiers
  530.  
  531.    The Encapsulating Security Payload (ESP) defines one mandatory and
  532.    many optional transforms used to provide data confidentiality.  The
  533.    following table lists the defined ESP Transform Identifiers for the
  534.    ISAKMP Proposal Payload for the IPSEC DOI.
  535.  
  536.        Transform ID                        Value
  537.        ------------                        -----
  538.        ESP_NULL                            0
  539.        ESP_DES_IV64                        1
  540.        ESP_DES                             2
  541.        ESP_3DES                            3
  542.        ESP_RC5                             4
  543.        ESP_IDEA                            5
  544.        ESP_CAST                            6
  545.        ESP_BLOWFISH                        7
  546.        ESP_3IDEA                           8
  547.        ESP_DES_IV32                        9
  548.        ESP_ARCFOUR                         10
  549.  
  550.    The size of this field is one octet.  The values 11-248 are reserved
  551.    to IANA. Values 249-255 are reserved for private use.
  552.  
  553. 4.4.4.1 ESP_NULL
  554.  
  555.  
  556.  
  557.  
  558. Piper                     Expires in 6 months              [Page 10]
  559.  
  560. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  561.  
  562.  
  563.    The ESP_NULL type specifies no confidentiality is to be provided by
  564.    ESP.  ESP_NULL is used when ESP is being used to tunnel packets which
  565.    require only authentication and integrity protection.  See the Auth
  566.    Algorithm attribute description in Section 4.5 for additional
  567.    requirements relating to the use of ESP_NULL.
  568.  
  569. 4.4.4.2 ESP_DES_IV64
  570.  
  571.    The ESP_DES_IV64 type specifies the DES-CBC transform defined in
  572.    RFC-1827 and RFC-1829 using a 64-bit IV.  This mode MAY be negotiated
  573.    for compatibility with older implementations.  Implementations are
  574.    not required to support this mode.
  575.  
  576. 4.4.4.3 ESP_DES
  577.  
  578.    The ESP_DES type specifies a generic DES transform using DES-CBC.
  579.    The actual protection suite is determined in concert with an
  580.    associated SA attribute list.  A generic transform is currently
  581.    undefined.
  582.  
  583.    All implementations within the IPSEC DOI MUST support ESP_DES along
  584.    with the Auth(HMAC-MD5) attribute.  This suite is defined as the
  585.    [DES] transform, with authentication and integrity provided by HMAC
  586.    MD5.
  587.  
  588. 4.4.4.4 ESP_3DES
  589.  
  590.    The ESP_3DES type specifies a generic triple-DES transform.  The
  591.    actual protection suite is determined in concert with an associated
  592.    SA attribute list.  The generic transform is currently undefined.
  593.  
  594.    All implementations within the IPSEC DOI are strongly encourage to
  595.    support ESP_3DES along with the Auth(HMAC-MD5) attribute.  This suite
  596.    is defined as the [3DES] transform, with authentication and integrity
  597.    provided by HMAC MD5.
  598.  
  599. 4.4.4.5 ESP_RC5
  600.  
  601.    The ESP_RC5 type specifies the RC5 transform defined in [RC5].
  602.  
  603. 4.4.4.6 ESP_IDEA
  604.  
  605.    The ESP_IDEA type specifies the IDEA transform defined in [IDEA].
  606.  
  607. 4.4.4.7 ESP_CAST
  608.  
  609.    The ESP_CAST type specifies the CAST transform defined in [CAST].
  610.  
  611.  
  612.  
  613.  
  614. Piper                     Expires in 6 months              [Page 11]
  615.  
  616. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  617.  
  618.  
  619. 4.4.4.8 ESP_BLOWFISH
  620.  
  621.    The ESP_BLOWFISH type specifies the BLOWFISH transform defined in
  622.    [BLOW].
  623.  
  624. 4.4.4.9 ESP_3IDEA
  625.  
  626.    The ESP_3IDEA type is reserved for triple-IDEA.
  627.  
  628. 4.4.4.10 ESP_DES_IV32
  629.  
  630.    The ESP_DES_IV32 type specifies the DES-CBC transform defined in
  631.    RFC-1827 and RFC-1829 using a 32-bit IV.  This mode MAY be negotiated
  632.    for compatibility with older implementations.  Implementations are
  633.    not required to support this mode.
  634.  
  635. 4.4.4.11 ESP_ARCFOUR
  636.  
  637.    The ESP_ARCFOUR type specifies the ARCFOUR transform defined in
  638.    [ARCFOUR].
  639.  
  640. 4.4.5 IPSEC IPCOMP Transform Identifiers
  641.  
  642.    The IP Compression (IPCOMP) transforms define optional compression
  643.    algorithms that can be negotiated to provide for IP compression
  644.    before ESP encryption.  The following table lists the defined IPCOMP
  645.    Transform Identifiers for the ISAKMP Proposal Payload within the
  646.    IPSEC DOI.
  647.  
  648.        Transform ID                        Value
  649.        ------------                        -----
  650.        RESERVED                            0
  651.        IPCOMP_OUI                          1
  652.        IPCOMP_DEFLAT                       2
  653.        IPCOMP_LZS                          3
  654.        IPCOMP_V42BIS                       4
  655.  
  656.    The size of this field is one octet.  The values 5-248 are reserved
  657.    to IANA. Values 249-255 are reserved for private use.
  658.  
  659. 4.4.5.1 IPCOMP_OUI
  660.  
  661.    The IPCOMP_OUI type specifies a proprietary compression transform.
  662.    The IPCOMP_OUI type must be accompanied by an attribute which further
  663.    identifies the specific vendor algorithm.
  664.  
  665. 4.4.5.2 IPCOMP_DEFLATE
  666.  
  667.  
  668.  
  669.  
  670. Piper                     Expires in 6 months              [Page 12]
  671.  
  672. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  673.  
  674.  
  675.    The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate
  676.    algorithm.
  677.  
  678. 4.4.5.3 IPCOMP_LZS
  679.  
  680.    The IPCOMP_LZS type specifies the use of the Stac Electronics LZS
  681.    algorithm.
  682.  
  683. 4.4.5.4 IPCOMP_V42BIS
  684.  
  685.    The IPCOMP_V42BIS type specifies the use of V42bis compression.
  686.  
  687. 4.5 IPSEC Security Association Attributes
  688.  
  689.    The following SA attribute definitions are used in phase II of an
  690.    ISAKMP/Oakley negotiation.  Attribute types can be either Basic (B)
  691.    or Variable-Length (V).  Encoding of these attributes is defined in
  692.    the base ISAKMP specification.
  693.  
  694.        Attribute Types
  695.  
  696.              class               value           type
  697.        -------------------------------------------------
  698.        SA Life Type                1               B
  699.        SA Life Duration            2               B/V
  700.        Group Description           3               B
  701.        Encapsulation Mode          4               B
  702.        Authentication Algorithm    5               B
  703.        Key Length                  6               B
  704.        Key Rounds                  7               B
  705.        Compress Dictionary Size    8               B
  706.        Compress Private Algorithm  9               B/V
  707.  
  708.    The size of this field is two octets, with the high bit reserved for
  709.    the ISAKMP B/V encoding.  The values 10-32000 are reserved to IANA.
  710.    Values 32001-32767 are for experimental use.
  711.  
  712.        Class Values
  713.  
  714.          SA Life Type
  715.          SA Duration
  716.  
  717.            Specifies the time-to-live for the overall security
  718.            association.  When the SA expires, all keys negotiated
  719.            under the association (AH or ESP) must be renegotiated.
  720.            The life type values are:
  721.  
  722.            RESERVED                0
  723.  
  724.  
  725.  
  726. Piper                     Expires in 6 months              [Page 13]
  727.  
  728. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  729.  
  730.  
  731.            seconds                 1
  732.            kilobytes               2
  733.  
  734.            Values 3-61439 are reserved to IANA.  Values 61440-65535
  735.            are for experimental use.  For a given Life Type, the
  736.            value of the Life Duration attribute defines the actual
  737.            length of the component lifetime -- either a number of
  738.            seconds, or a number of Kbytes that can be protected.
  739.  
  740.            If unspecified, the default value shall be assumed to be
  741.            28800 seconds (8 hours).
  742.  
  743.            An SA Life Duration attribute MUST always follow
  744.            an SA Life Type which describes the units of duration.
  745.  
  746.            See Section 4.5.4 for additional information relating to
  747.            lifetime notification.
  748.  
  749.          Group Description
  750.            RESERVED                0
  751.            768-bit Oakley group    1
  752.            1024-bit Oakley group   2
  753.            2048-bit Oakley group   3
  754.  
  755.            Values 4-61439 are reserved to IANA.  Values 61440-65535
  756.            are for private use among mutually consenting parties.
  757.  
  758.            This attribute must be included in PFS QM negotiations.
  759.  
  760.          Encapsulation Mode
  761.            RESERVED                0
  762.            Tunnel                  1
  763.            Transport               2
  764.  
  765.            Values 3-61439 are reserved to IANA.  Values 61440-65535
  766.            are for private use among mutually consenting parties.
  767.  
  768.            If unspecified, the default value shall be assumed to be
  769.            unspecified (host-dependent).
  770.  
  771.          Authentication Algorithm
  772.            RESERVED                0
  773.            HMAC-MD5                1
  774.            HMAC-SHA-1              2
  775.            DES-MAC                 3
  776.  
  777.            Values 4-61439 are reserved to IANA.  Values 61440-65535
  778.            are for private use among mutually consenting parties.
  779.  
  780.  
  781.  
  782. Piper                     Expires in 6 months              [Page 14]
  783.  
  784. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  785.  
  786.  
  787.            There is no default value for Auth Algorithm, as it
  788.            must be specified to correctly identify the applicable
  789.            AH or ESP transform, except in the following case.
  790.  
  791.            When negotiating ESP without authentication, the Auth
  792.            Algorithm attribute MUST NOT be included in the proposal.
  793.  
  794.            When negotiating ESP without confidentiality, the Auth
  795.            Algorithm attribute MUST be included in the proposal and
  796.            the ESP transform ID must be ESP_NULL.
  797.  
  798.          Key Length
  799.            RESERVED                0
  800.  
  801.            There is no default value for Key Length, as it must be
  802.            specified for transforms using ciphers with variable key
  803.            lengths.
  804.  
  805.         Key Rounds
  806.            RESERVED                0
  807.  
  808.            There is no default value for Key Rounds, as it must be
  809.            specified for transforms using ciphers with varying
  810.            numbers of rounds.
  811.  
  812.         Compression Dictionary Size
  813.            RESERVED                0
  814.  
  815.            Specifies the log2 maximum size of the dictionary.
  816.  
  817.            There is no default value for dictionary size.
  818.  
  819.         Compression Private Algorithm
  820.  
  821.            Specifies a private vendor compression algorithm.  The
  822.            first three (3) octets must be an IEEE assigned company_id
  823.            (OUI).  The next octet may be a vendor specific compression
  824.            subtype, followed by zero or more octets of vendor data.
  825.  
  826. 4.5.1 Required Attribute Support
  827.  
  828.    To ensure basic interoperability, all implementations MUST be
  829.    prepared to negotiate all of the following attributes.
  830.  
  831.            SA Life Type
  832.            SA Duration
  833.            Auth Algorithm
  834.  
  835.  
  836.  
  837.  
  838. Piper                     Expires in 6 months              [Page 15]
  839.  
  840. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  841.  
  842.  
  843. 4.5.2 Attribute List Parsing Requirement
  844.  
  845.    To allow for flexible semantics, the IPSEC DOI requires that a
  846.    conforming ISAKMP implementation MUST correctly parse an attribute
  847.    list that contains multiple instances of the same attribute class, so
  848.    long as the different attribute entries do not conflict with one
  849.    another.
  850.  
  851.    To see why this is important, the following example shows the binary
  852.    encoding of a four entry attribute list that specifies an SA Lifetime
  853.    of either 100MB or 24 hours.  (See Section 3.3 of [ISAKMP] for a
  854.    complete description of the attribute encoding format.)
  855.  
  856.      Attribute #1:
  857.        0x80010001  (AF = 1, type = SA Life Type, value = seconds)
  858.  
  859.      Attribute #2:
  860.        0x00020004  (AF = 0, type = SA Duration, length = 4 bytes)
  861.        0x00015180  (value = 0x15180 = 86400 seconds = 24 hours)
  862.  
  863.      Attribute #3:
  864.        0x80010002  (AF = 1, type = SA Life Type, value = KB)
  865.  
  866.      Attribute #4:
  867.        0x00020004  (AF = 0, type = SA Duration, length = 4 bytes)
  868.        0x000186A0  (value = 0x186A0 = 100000KB = 100MB)
  869.  
  870.    If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED
  871.    Notification Payload SHOULD be returned and the security association
  872.    setup MUST be aborted.
  873.  
  874.    4.5.3 Attribute Negotiation
  875.  
  876.    If an implementation receives a defined IPSEC DOI attribute (or
  877.    attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT
  878.    SHOULD be sent and the security association setup MUST be aborted,
  879.    unless the attribute value is in the reserved range.
  880.  
  881.    If an implementation receives an attribute value in the reserved
  882.    range, an implementation MAY chose to continue based on local policy.
  883.  
  884.    4.5.4 Lifetime Notification
  885.  
  886.    When an initiator offers an SA lifetime greater than what the
  887.    responder desires based on their local policy, the responder has
  888.    three choices: 1) fail the negotiation entirely; 2) complete the
  889.    negotiation but use a shorter lifetime than what was offered; 3)
  890.    complete the negotiation and send an advisory notification to the
  891.  
  892.  
  893.  
  894. Piper                     Expires in 6 months              [Page 16]
  895.  
  896. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  897.  
  898.  
  899.    initiator with the responder's true lifetime.
  900.  
  901.    In the latter case, the IPSEC DOI requires the following: if the
  902.    initiator offers an SA lifetime longer than the responder is willing
  903.    to accept, the responder SHOULD include an ISAKMP Notification
  904.    Payload in the exchange that includes the responder's IPSEC SA
  905.    payload.  When present, the Notification Payload MUST have the
  906.    following format:
  907.  
  908.      o  Payload Length - set to length of payload + size of Notify Data
  909.      o  DOI - set to IPSEC DOI (1)
  910.      o  Protocol ID - set to selected Protocol ID from chosen SA
  911.      o  SPI Size - set to eight (8) (two four octet IPSEC SPI's)
  912.      o  Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3)
  913.      o  SPI - set to the two IPSEC SPI's
  914.      o  Notification Data - contains an ISAKMP attribute list with the
  915.         responder's actual SA lifetime(s)
  916.  
  917.    Implementation Note: saying that the Notification Data field contains
  918.    an attribute list is equivalent to saying that the Notification Data
  919.    field has zero length and the Notification Payload has an associated
  920.    attribute list.
  921.  
  922. 4.6 IPSEC Payload Content
  923.  
  924.    The following sections describe those ISAKMP payloads whose data
  925.    representations are dependent on the applicable DOI.
  926.  
  927. 4.6.1 Security Association Payload
  928.  
  929.    The following diagram illustrates the content of the Security
  930.    Association Payload for the IPSEC DOI.  See Section 4.2 for a
  931.    description of the Situation bitmap.
  932.  
  933.     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
  934.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  935.    !  Next Payload !   RESERVED    !        Payload Length         !
  936.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  937.    !                Domain of Interpretation (IPSEC)               |
  938.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  939.    !                       Situation (bitmap)                      !
  940.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  941.    !                    Labeled Domain Identifier                  !
  942.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  943.    !  Secrecy Length (in octets)   !           RESERVED            !
  944.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  945.    ~                        Secrecy Level                          ~
  946.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  947.  
  948.  
  949.  
  950. Piper                     Expires in 6 months              [Page 17]
  951.  
  952. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  953.  
  954.  
  955.    ! Secrecy Cat. Length (in bits) !           RESERVED            !
  956.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  957.    ~                    Secrecy Category Bitmap                    ~
  958.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  959.    ! Integrity Length (in octets)  !           RESERVED            !
  960.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  961.    ~                       Integrity Level                         ~
  962.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  963.    ! Integ. Cat. Length (in bits)  !           RESERVED            !
  964.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  965.    ~                  Integrity Category Bitmap                    ~
  966.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  967.  
  968.                Figure 1: Security Association Payload Format
  969.  
  970.    The Security Association Payload is defined as follows:
  971.  
  972.      o  Next Payload (2 octets) - Identifier for the payload type of
  973.         the next payload in the message.  If the current payload is
  974.         the last in the message, this field will be zero (0).
  975.  
  976.      o  RESERVED (1 octet) - Unused, must be zero (0).
  977.  
  978.      o  Payload Length (2 octets) - Length, in octets, of the current
  979.         payload, including the generic header.
  980.  
  981.      o  Domain of Interpretation (4 octets) - Specifies the IPSEC DOI,
  982.         which has been assigned the value one (1).
  983.  
  984.      o  Situation (4 octets) - Bitmask used to interpret the
  985.         remainder of the Security Association Payload.  See Section
  986.         4.2 for a complete list of values.
  987.  
  988.      o  Labeled Domain Identifier (4 octets) - IANA Assigned Number
  989.         used to interpret the Secrecy and Integrity information.
  990.  
  991.      o  Secrecy Length (2 octets) - Specifies the length, in octets,
  992.         of the secrecy level identifier.
  993.  
  994.      o  RESERVED (2 octets) - Unused, must be zero (0).
  995.  
  996.      o  Secrecy Category Length (2 octets) - Specifies the length, in
  997.         bits, of the secrecy category (compartment) bitmap, excluding
  998.         pad bits.
  999.  
  1000.      o  RESERVED (2 octets) - Unused, must be zero (0).
  1001.  
  1002.      o  Secrecy Category Bitmap (variable length) - A bitmap used to
  1003.  
  1004.  
  1005.  
  1006. Piper                     Expires in 6 months              [Page 18]
  1007.  
  1008. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  1009.  
  1010.  
  1011.         designate secrecy categories (compartments) that are
  1012.         required.  The bitmap MUST be padded with zero (0) to the
  1013.         next 32-bit boundry.
  1014.  
  1015.      o  Integrity Length (2 octets) - Specifies the length, in
  1016.         octets, of the integrity level identifier.
  1017.  
  1018.      o  RESERVED (2 octets) - Unused, must be zero (0).
  1019.  
  1020.      o  Integrity Category Length (2 octets) - Specifies the length,
  1021.         in bits, of the integrity category (compartment) bitmap,
  1022.         excluding pad bits.
  1023.  
  1024.      o  RESERVED (2 octets) - Unused, must be zero (0).
  1025.  
  1026.      o  Integrity Category Bitmap (variable length) - A bitmap used
  1027.         to designate integrity categories (compartments) that are
  1028.         required.  The bitmap MUST be padded with zero (0) to the
  1029.         next 32-bit boundry.
  1030.  
  1031. 4.6.1.1 Labeled Domain Identifier Values
  1032.  
  1033.    The following table lists the assigned values for the Labeled Domain
  1034.    Identifier field contained in the Situation field of the Security
  1035.    Association Payload.
  1036.  
  1037.        Domain                              Value
  1038.        -------                             -----
  1039.        RESERVED                            0
  1040.  
  1041.    The values 1-0x7fffffff are reserved to IANA.  Values 0x8000000-
  1042.    0xffffffff are reserved for private use.
  1043.  
  1044. 4.6.2 Identification Payload Content
  1045.  
  1046.    The Identification Payload is used to identify the initiator of the
  1047.    Security Association.  The identity of the initiator SHOULD be used
  1048.    by the responder to determine the correct host system security policy
  1049.    requirement for the association.  For example, a host might choose to
  1050.    require authentication and integrity without confidentiality (AH)
  1051.    from a certain set of IP addresses and full authentication with
  1052.    confidentiality (ESP) from another range of IP addresses.  The
  1053.    Identification Payload provides information that can be used by the
  1054.    responder to make this decision.
  1055.  
  1056.    The following diagram illustrates the content of the Identification
  1057.    Payload.
  1058.  
  1059.  
  1060.  
  1061.  
  1062. Piper                     Expires in 6 months              [Page 19]
  1063.  
  1064. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  1065.  
  1066.  
  1067.     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
  1068.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1069.    !  Next Payload !   RESERVED    !        Payload Length         !
  1070.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1071.    !   ID Type     !  Protocol ID  !             Port              !
  1072.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1073.    ~                     Identification Data                       ~
  1074.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1075.  
  1076.                   Figure 2: Identification Payload Format
  1077.  
  1078.    The Identification Payload fields are defined as follows:
  1079.  
  1080.      o  Next Payload (2 octets) - Identifier for the payload type of
  1081.         the next payload in the message.  If the current payload is
  1082.         the last in the message, this field will be zero (0).
  1083.  
  1084.      o  RESERVED (1 octet) - Unused, must be zero (0).
  1085.  
  1086.      o  Payload Length (2 octets) - Length, in octets, of the
  1087.         identification data, including the generic header.
  1088.  
  1089.      o  Identification Type (1 octet) - Value describing the
  1090.         identity information found in the Identification Data field.
  1091.  
  1092.      o  Protocol ID (1 octet) - Value specifying an associated
  1093.         IP protocol ID (e.g. UDP/TCP).  A value of zero means that the
  1094.         Protocol ID field should be ignored.
  1095.  
  1096.      o  Port (2 octets) - Value specifying an associated port.
  1097.         A value of zero means that the Port field should be ignored.
  1098.  
  1099.      o  Identification Data (variable length) - Value, as indicated
  1100.         by the Identification Type.
  1101.  
  1102. 4.6.2.1 Identification Type Values
  1103.  
  1104.    The following table lists the assigned values for the Identification
  1105.    Type field found in the Identification Payload.
  1106.  
  1107.        ID Type                             Value
  1108.        -------                             -----
  1109.        RESERVED                            0
  1110.        ID_IPV4_ADDR                        1
  1111.        ID_FQDN                             2
  1112.        ID_USER_FQDN                        3
  1113.        ID_IPV4_ADDR_SUBNET                 4
  1114.        ID_IPV6_ADDR                        5
  1115.  
  1116.  
  1117.  
  1118. Piper                     Expires in 6 months              [Page 20]
  1119.  
  1120. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  1121.  
  1122.  
  1123.        ID_IPV6_ADDR_SUBNET                 6
  1124.        ID_IPV4_ADDR_RANGE                  7
  1125.        ID_IPV6_ADDR_RANGE                  8
  1126.        ID_DER_ASN1_DN                      9
  1127.        ID_DER_ASN1_GN                      10
  1128.        ID_KEY_ID                           11
  1129.  
  1130.    The size of this field is one octet.  The values 12-248 are reserved
  1131.    to IANA. Values 249-255 are reserved for private use.
  1132.  
  1133.    For types where the ID entity is variable length, the size of the ID
  1134.    entity is computed from size in the ID payload header.
  1135.  
  1136.    When an ISAKMP/Oakley exchange is authenticated using certificates
  1137.    (of any format), any ID's used for input to local policy decisions
  1138.    SHOULD be contained in the certificate used in the authentication of
  1139.    the exchange.
  1140.  
  1141. 4.6.2.2 ID_IPV4_ADDR
  1142.  
  1143.    The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
  1144.  
  1145. 4.6.2.3 ID_FQDN
  1146.  
  1147.    The ID_FQDN type specifies a fully-qualified domain name string.  An
  1148.    example of a ID_FQDN is, "foo.bar.com".  The string should not
  1149.    contain any terminators.
  1150.  
  1151. 4.6.2.4 ID_USER_FQDN
  1152.  
  1153.    The ID_USER_FQDN type specifies a fully-qualified username string, An
  1154.    example of a ID_USER_FQDN is, "piper@foo.bar.com".  The string should
  1155.    not contain any terminators.
  1156.  
  1157. 4.6.2.5 ID_IPV4_ADDR_SUBNET
  1158.  
  1159.    The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses,
  1160.    represented by two four (4) octet values.  The first value is an IPv4
  1161.    address.  The second is an IPv4 network mask.  Note that ones (1s) in
  1162.    the network mask indicate that the corresponding bit in the address
  1163.    is fixed, while zeros (0s) indicate a "wildcard" bit.
  1164.  
  1165. 4.6.2.6 ID_IPV6_ADDR
  1166.  
  1167.    The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
  1168.    address.
  1169.  
  1170. 4.6.2.7 ID_IPV6_ADDR_SUBNET
  1171.  
  1172.  
  1173.  
  1174. Piper                     Expires in 6 months              [Page 21]
  1175.  
  1176. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  1177.  
  1178.  
  1179.    The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses,
  1180.    represented by two sixteen (16) octet values.  The first value is an
  1181.    IPv6 address.  The second is an IPv6 network mask.  Note that ones
  1182.    (1s) in the network mask indicate that the corresponding bit in the
  1183.    address is fixed, while zeros (0s) indicate a "wildcard" bit.
  1184.  
  1185. 4.6.2.8 ID_IPV4_ADDR_RANGE
  1186.  
  1187.    The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses,
  1188.    represented by two four (4) octet values.  The first value is the
  1189.    beginning IPv4 address (inclusive) and the second value is the ending
  1190.    IPv4 address (inclusive).  All addresses falling between the two
  1191.    specified addresses are considered to be within the list.
  1192.  
  1193. 4.6.2.9 ID_IPV6_ADDR_RANGE
  1194.  
  1195.    The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses,
  1196.    represented by two sixteen (16) octet values.  The first value is the
  1197.    beginning IPv6 address (inclusive) and the second value is the ending
  1198.    IPv6 address (inclusive).  All addresses falling between the two
  1199.    specified addresses are considered to be within the list.
  1200.  
  1201. 4.6.2.10 ID_DER_ASN1_DN
  1202.  
  1203.    The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1
  1204.    X.500 Distinguished Name [X.501] of the principal whose certificates
  1205.    are being exchanged to establish the SA.
  1206.  
  1207. 4.6.2.11 ID_DER_ASN1_GN
  1208.  
  1209.    The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1
  1210.    X.500 GeneralName [X.509] of the principal whose certificates are
  1211.    being exchanged to establish the SA.
  1212.  
  1213. 4.6.2.12 ID_KEY_ID
  1214.  
  1215.    The ID_KEY_ID type specifies an opaque byte stream which may be used
  1216.    to pass vendor-specific information necessary to identify which pre-
  1217.    shared key should be used to authenticate Aggressive mode
  1218.    negotiations.
  1219.  
  1220. 4.6.3 IPSEC DOI Notify Message Types
  1221.  
  1222.    ISAKMP defines two blocks of Notify Message codes, one for errors and
  1223.    one for status.  ISAKMP also allocates a portion of each block for
  1224.    private use within a DOI.  The IPSEC DOI defines the following
  1225.    private message types.
  1226.  
  1227.  
  1228.  
  1229.  
  1230. Piper                     Expires in 6 months              [Page 22]
  1231.  
  1232. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  1233.  
  1234.  
  1235.        Notify Messages - Error Types       Value
  1236.        -----------------------------       -----
  1237.        RESERVED                            8192
  1238.  
  1239.        Notify Messages - Status Types      Value
  1240.        ------------------------------      -----
  1241.        RESPONDER-LIFETIME                  24576
  1242.  
  1243. 4.7 IPSEC Key Exchange Requirements
  1244.  
  1245.    The IPSEC DOI introduces no additional Key Exchange types.
  1246.  
  1247. 5. Changes
  1248.  
  1249.    The following changes were made relative to the IPSEC DOI V3, that
  1250.    was posted to the IPSEC mailing list prior to the Munich IETF:
  1251.  
  1252.      o  added ESP transform identifiers for NULL and ARCFOUR
  1253.      o  renamed HMAC Algorithm to Auth Algorithm to accommodate
  1254.         DES-MAC and optional authentication/integrity for ESP
  1255.      o  added AH and ESP DES-MAC algorithm identifiers
  1256.      o  removed KEY_MANUAL and KEY_KDC identifier definitions
  1257.      o  added lifetime duration MUST follow lifetype attribute to
  1258.         SA Life Type and SA Life Duration attribute definition
  1259.      o  added lifetime notification and IPSEC DOI message type table
  1260.      o  added optional authentication and confidentiality
  1261.         restrictions to MAC Algorithm attribute definition
  1262.      o  corrected attribute parsing example (used obsolete attribute)
  1263.      o  corrected several Internet Draft document references
  1264.      o  added ID_KEY_ID per ipsec list discussion (18-Mar-97)
  1265.      o  removed Group Description default for PFS QM ([IO] MUST)
  1266.  
  1267. 6. Security Considerations
  1268.  
  1269.    This entire draft pertains to a negotiated key management protocol,
  1270.    combining Oakley ([OAKLEY]) with ISAKMP ([ISAKMP]), which negotiates
  1271.    and derives keying material for security associations in a secure and
  1272.    authenticated manner.  Specific discussion of the various security
  1273.    protocols and transforms identified in this document can be found in
  1274.    the associated base documents and in the cipher references.
  1275.  
  1276. Acknowledgements
  1277.  
  1278.    This document is derived, in part, from previous works by Douglas
  1279.    Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,
  1280.    and Dave Carrel.  Matt Thomas, Roy Pereira, Greg Carter, and Ran
  1281.    Atkinson also contributed suggestions and, in many cases, text.
  1282.  
  1283.  
  1284.  
  1285.  
  1286. Piper                     Expires in 6 months              [Page 23]
  1287.  
  1288. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  1289.  
  1290.  
  1291. References
  1292.  
  1293.    [AH] Kent, S., Atkinson, R., "IP Authentication Header," draft-ietf-
  1294.    ipsec-auth-header-01.txt.
  1295.  
  1296.    [ARCFOUR] Thayer, R., "The ESP ARCFOUR Algorithm," draft-ietf-ipsec-
  1297.    ciph-arcfour-00.txt.
  1298.  
  1299.    [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
  1300.    (ESP)," draft-ietf-ipsec-esp-v2-00.txt.
  1301.  
  1302.    [BLOW] Adams, R., "The ESP Blowfish-CBC Algorithm Using an Explicit
  1303.    IV," draft-ietf-ipsec-ciph-blowfish-cbc-00.txt.
  1304.  
  1305.    [CAST] Pereira, R., Carter, G., "The ESP CAST128-CBC Algorithm,"
  1306.    draft-ietf-ipsec-ciph-cast128-cbc-00.txt.
  1307.  
  1308.    [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm
  1309.    With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-00.txt.
  1310.  
  1311.    [3DES] Pereira, R., Thayer, R., "The ESP 3DES-CBC Algorithm Using an
  1312.    Explicit IV," draft-ietf-ipsec-ciph-3des-expiv-00.txt.
  1313.  
  1314.    [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft-
  1315.    bitan-auth-des-mac-00.txt.
  1316.  
  1317.    [HMACMD5] Oehler, M., Glenn, R., "HMAC-MD5-96 IP Authentication with
  1318.    Replay Prevention," draft-ietf-ipsec-ah-hmac-md5-96-00.txt.
  1319.  
  1320.    [HMACSHA] Chang, S., Glenn, R., "HMAC-SHA-1-96 IP Authentication with
  1321.    Replay Prevention," draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt.
  1322.  
  1323.    [IDEA] Adams, R., "The ESP IDEA-CBC Algorithm Using Explicit IV,"
  1324.    draft-ietf-ipsec-ciph-idea-cbc-00.txt.
  1325.  
  1326.    [IO] Harkins, D., Carrel, D., "The Resolution of ISAKMP with Oakley,"
  1327.    draft-ietf-ipsec-isakmp-oakley-04.txt.
  1328.  
  1329.    [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
  1330.    "Internet Security Association and Key Management Protocol (ISAKMP),"
  1331.    draft-ietf-ipsec-isakmp-08.{ps,txt}.
  1332.  
  1333.    [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"
  1334.    draft-ietf-ipsec-oakley-01.txt.
  1335.  
  1336.    [ROADMAP] Thayer, R., Doraswamy, N., Glenn, R., "IP Security
  1337.    Documentation Roadmap," draft-ietf-ipsec-doc-roadmap-00.txt.
  1338.  
  1339.  
  1340.  
  1341.  
  1342. Piper                     Expires in 6 months              [Page 24]
  1343.  
  1344. INTERNET DRAFT                 IPSEC DOI              September 19, 1997
  1345.  
  1346.  
  1347.    [PFKEY] McDonald, D. L., Metz, C. W., Phan, B. G., "PF_KEY Key
  1348.    Management API, Version 2", draft-mcdonald-pf-key-v2-03.txt.
  1349.  
  1350.    [RC5] Pereira, R., Baldwin, R., "The ESP RC5-CBC Transform," draft-
  1351.    ietf-ipsec-ciph-rc5-cbc-00.txt.
  1352.  
  1353.    [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
  1354.    Interconnection - The Directory:  Models", CCITT/ITU Recommendation
  1355.    X.501, 1993.
  1356.  
  1357.    [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
  1358.    Interconnection - The Directory:  Authentication Framework",
  1359.    CCITT/ITU Recommendation X.509, 1993.
  1360.  
  1361. Author's Address:
  1362.  
  1363.    Derrell Piper <piper@cisco.com>
  1364.    cisco Systems
  1365.    101 Cooper St.
  1366.    Santa Cruz, California, 95060
  1367.    United States of America
  1368.    +1 408 457-5384
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398. Piper                     Expires in 6 months              [Page 25]
  1399.  
  1400.