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