GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc2407

Network Working Group D. Piper Request for Comments: 2407 Network Alchemy Category: Standards Track November 1998

    The Internet IP Security Domain of Interpretation for ISAKMP

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (1998).  All Rights Reserved.

IESG Note

 Section 4.4.4.2 states, "All implememtations within the IPSEC DOI
 MUST support ESP_DES...".  Recent work in the area of cryptanalysis
 suggests that DES may not be sufficiently strong for many
 applications.  Therefore, it is very likely that the IETF will
 deprecate the use of ESP_DES as a mandatory cipher suite in the near
 future.  It will remain as an optional use protocol.  Although the
 IPsec working group and the IETF in general have not settled on an
 alternative algorithm (taking into account concerns of security and
 performance), implementers may want to heed the recommendations of
 section 4.4.4.3 on the use of ESP_3DES.

1. Abstract

 The Internet Security Association and Key Management Protocol
 (ISAKMP) defines a framework for security association management and
 cryptographic key establishment for the Internet.  This framework
 consists of defined exchanges, payloads, and processing guidelines
 that occur within a given Domain of Interpretation (DOI).  This
 document defines the Internet IP Security DOI (IPSEC DOI), which
 instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate
 security associations.
 For a list of changes since the previous version of the IPSEC DOI,
 please see Section 7.

Piper Standards Track [Page 1] RFC 2407 IP Security Domain of Interpretation November 1998

2. Introduction

 Within ISAKMP, a Domain of Interpretation is used to group related
 protocols using ISAKMP to negotiate security associations.  Security
 protocols sharing a DOI choose security protocol and cryptographic
 transforms from a common namespace and share key exchange protocol
 identifiers.  They also share a common interpretation of DOI-specific
 payload data content, including the Security Association and
 Identification payloads.
 Overall, ISAKMP places the following requirements on a DOI
 definition:
   o  define the naming scheme for DOI-specific protocol identifiers
   o  define the interpretation for the Situation field
   o  define the set of applicable security policies
   o  define the syntax for DOI-specific SA Attributes (Phase II)
   o  define the syntax for DOI-specific payload contents
   o  define additional Key Exchange types, if needed
   o  define additional Notification Message types, if needed
 The remainder of this document details the instantiation of these
 requirements for using the IP Security (IPSEC) protocols to provide
 authentication, integrity, and/or confidentiality for IP packets sent
 between cooperating host systems and/or firewalls.
 For a description of the overall IPSEC architecture, see [ARCH],
 [AH], and [ESP].

3. Terms and Definitions

 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
 document, are to be interpreted as described in [RFC 2119].

4.1 IPSEC Naming Scheme

 Within ISAKMP, all DOI's must be registered with the IANA in the
 "Assigned Numbers" RFC [STD-2].  The IANA Assigned Number for the
 Internet IP Security DOI (IPSEC DOI) is one (1).  Within the IPSEC
 DOI, all well-known identifiers MUST be registered with the IANA
 under the IPSEC DOI.  Unless otherwise noted, all tables within this
 document refer to IANA Assigned Numbers for the IPSEC DOI.  See
 Section 6 for further information relating to the IANA registry for
 the IPSEC DOI.
 All multi-octet binary values are stored in network byte order.

Piper Standards Track [Page 2] RFC 2407 IP Security Domain of Interpretation November 1998

4.2 IPSEC Situation Definition

 Within ISAKMP, the Situation provides information that can be used by
 the responder to make a policy determination about how to process the
 incoming Security Association request.  For the IPSEC DOI, the
 Situation field is a four (4) octet bitmask with the following
 values.
     Situation                   Value
     ---------                   -----
     SIT_IDENTITY_ONLY           0x01
     SIT_SECRECY                 0x02
     SIT_INTEGRITY               0x04

4.2.1 SIT_IDENTITY_ONLY

 The SIT_IDENTITY_ONLY type specifies that the security association
 will be identified by source identity information present in an
 associated Identification Payload.  See Section 4.6.2 for a complete
 description of the various Identification types.  All IPSEC DOI
 implementations MUST support SIT_IDENTITY_ONLY by including an
 Identification Payload in at least one of the Phase I Oakley
 exchanges ([IKE], Section 5) and MUST abort any association setup
 that does not include an Identification Payload.
 If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the
 situation consists only of the 4 octet situation bitmap and does not
 include the Labeled Domain Identifier field (Figure 1, Section 4.6.1)
 or any subsequent label information.  Conversely, if the initiator
 supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain
 Identifier MUST be included in the situation payload.

4.2.2 SIT_SECRECY

 The SIT_SECRECY type specifies that the security association is being
 negotiated in an environment that requires labeled secrecy.  If
 SIT_SECRECY is present in the Situation bitmap, the Situation field
 will be followed by variable-length data that includes a sensitivity
 level and compartment bitmask.  See Section 4.6.1 for a complete
 description of the Security Association Payload format.
 If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be
 set in the Situation bitmap and no secrecy level or category bitmaps
 shall be included.
 If a responder does not support SIT_SECRECY, a SITUATION-NOT-
 SUPPORTED Notification Payload SHOULD be returned and the security
 association setup MUST be aborted.

Piper Standards Track [Page 3] RFC 2407 IP Security Domain of Interpretation November 1998

4.2.3 SIT_INTEGRITY

 The SIT_INTEGRITY type specifies that the security association is
 being negotiated in an environment that requires labeled integrity.
 If SIT_INTEGRITY is present in the Situation bitmap, the Situation
 field will be followed by variable-length data that includes an
 integrity level and compartment bitmask.  If SIT_SECRECY is also in
 use for the association, the integrity information immediately
 follows the variable-length secrecy level and categories.  See
 section 4.6.1 for a complete description of the Security Association
 Payload format.
 If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST
 NOT be set in the Situation bitmap and no integrity level or category
 bitmaps shall be included.
 If a responder does not support SIT_INTEGRITY, a SITUATION-NOT-
 SUPPORTED Notification Payload SHOULD be returned and the security
 association setup MUST be aborted.

4.3 IPSEC Security Policy Requirements

 The IPSEC DOI does not impose specific security policy requirements
 on any implementation.  Host system policy issues are outside of the
 scope of this document.
 However, the following sections touch on some of the issues that must
 be considered when designing an IPSEC DOI host implementation.  This
 section should be considered only informational in nature.

4.3.1 Key Management Issues

 It is expected that many systems choosing to implement ISAKMP will
 strive to provide a protected domain of execution for a combined IKE
 key management daemon.  On protected-mode multiuser operating
 systems, this key management daemon will likely exist as a separate
 privileged process.
 In such an environment, a formalized API to introduce keying material
 into the TCP/IP kernel may be desirable.  The IP Security
 architecture does not place any requirements for structure or flow
 between a host TCP/IP kernel and its key management provider.

Piper Standards Track [Page 4] RFC 2407 IP Security Domain of Interpretation November 1998

4.3.2 Static Keying Issues

 Host systems that implement static keys, either for use directly by
 IPSEC, or for authentication purposes (see [IKE] Section 5.4), should
 take steps to protect the static keying material when it is not
 residing in a protected memory domain or actively in use by the
 TCP/IP kernel.
 For example, on a laptop, one might choose to store the static keys
 in a configuration store that is, itself, encrypted under a private
 password.
 Depending on the operating system and utility software installed, it
 may not be possible to protect the static keys once they've been
 loaded into the TCP/IP kernel, however they should not be trivially
 recoverable on initial system startup without having to satisfy some
 additional form of authentication.

4.3.3 Host Policy Issues

 It is not realistic to assume that the transition to IPSEC will occur
 overnight.  Host systems must be prepared to implement flexible
 policy lists that describe which systems they desire to speak
 securely with and which systems they require speak securely to them.
 Some notion of proxy firewall addresses may also be required.
 A minimal approach is probably a static list of IP addresses, network
 masks, and a security required flag or flags.
 A more flexible implementation might consist of a list of wildcard
 DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional
 firewall address.  The wildcard DNS name would be used to match
 incoming or outgoing IP addresses, the in/out bitmask would be used
 to determine whether or not security was to be applied and in which
 direction, and the optional firewall address would be used to
 indicate whether or not tunnel mode would be needed to talk to the
 target system though an intermediate firewall.

4.3.4 Certificate Management

 Host systems implementing a certificate-based authentication scheme
 will need a mechanism for obtaining and managing a database of
 certificates.
 Secure DNS is to be one certificate distribution mechanism, however
 the pervasive availability of secure DNS zones, in the short term, is
 doubtful for many reasons.  What's far more likely is that hosts will

Piper Standards Track [Page 5] RFC 2407 IP Security Domain of Interpretation November 1998

 need an ability to import certificates that they acquire through
 secure, out-of-band mechanisms, as well as an ability to export their
 own certificates for use by other systems.
 However, manual certificate management should not be done so as to
 preclude the ability to introduce dynamic certificate discovery
 mechanisms and/or protocols as they become available.

4.4 IPSEC Assigned Numbers

 The following sections list the Assigned Numbers for the IPSEC DOI:
 Situation Identifiers, Protocol Identifiers, Transform Identifiers,
 AH, ESP, and IPCOMP Transform Identifiers, Security Association
 Attribute Type Values, Labeled Domain Identifiers, ID Payload Type
 Values, and Notify Message Type Values.

4.4.1 IPSEC Security Protocol Identifier

 The ISAKMP proposal syntax was specifically designed to allow for the
 simultaneous negotiation of multiple Phase II security protocol
 suites within a single negotiation.  As a result, the protocol suites
 listed below form the set of protocols that can be negotiated at the
 same time.  It is a host policy decision as to what protocol suites
 might be negotiated together.
 The following table lists the values for the Security Protocol
 Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC
 DOI.
     Protocol ID                         Value
     -----------                         -----
     RESERVED                            0
     PROTO_ISAKMP                        1
     PROTO_IPSEC_AH                      2
     PROTO_IPSEC_ESP                     3
     PROTO_IPCOMP                        4

4.4.1.1 PROTO_ISAKMP

 The PROTO_ISAKMP type specifies message protection required during
 Phase I of the ISAKMP protocol.  The specific protection mechanism
 used for the IPSEC DOI is described in [IKE].  All implementations
 within the IPSEC DOI MUST support PROTO_ISAKMP.
 NB: ISAKMP reserves the value one (1) across all DOI definitions.

Piper Standards Track [Page 6] RFC 2407 IP Security Domain of Interpretation November 1998

4.4.1.2 PROTO_IPSEC_AH

 The PROTO_IPSEC_AH type specifies IP packet authentication.  The
 default AH transform provides data origin authentication, integrity
 protection, and replay detection.  For export control considerations,
 confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform.

4.4.1.3 PROTO_IPSEC_ESP

 The PROTO_IPSEC_ESP type specifies IP packet confidentiality.
 Authentication, if required, must be provided as part of the ESP
 transform.  The default ESP transform includes data origin
 authentication, integrity protection, replay detection, and
 confidentiality.

4.4.1.4 PROTO_IPCOMP

 The PROTO_IPCOMP type specifies IP payload compression as defined in
 [IPCOMP].

4.4.2 IPSEC ISAKMP Transform Identifiers

 As part of an ISAKMP Phase I negotiation, the initiator's choice of
 Key Exchange offerings is made using some host system policy
 description.  The actual selection of Key Exchange mechanism is made
 using the standard ISAKMP Proposal Payload.  The following table
 lists the defined ISAKMP Phase I Transform Identifiers for the
 Proposal Payload for the IPSEC DOI.
     Transform                           Value
     ---------                           -----
     RESERVED                            0
     KEY_IKE                             1
 Within the ISAKMP and IPSEC DOI framework it is possible to define
 key establishment protocols other than IKE (Oakley).  Previous
 versions of this document defined types both for manual keying and
 for schemes based on use of a generic Key Distribution Center (KDC).
 These identifiers have been removed from the current document.
 The IPSEC DOI can still be extended later to include values for
 additional non-Oakley key establishment protocols for ISAKMP and
 IPSEC, such as Kerberos [RFC-1510] or the Group Key Management
 Protocol (GKMP) [RFC-2093].

Piper Standards Track [Page 7] RFC 2407 IP Security Domain of Interpretation November 1998

4.4.2.1 KEY_IKE

 The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
 key exchange (IKE) as defined in the [IKE] document.  All
 implementations within the IPSEC DOI MUST support KEY_IKE.

4.4.3 IPSEC AH Transform Identifiers

 The Authentication Header Protocol (AH) defines one mandatory and
 several optional transforms used to provide authentication,
 integrity, and replay detection.  The following table lists the
 defined AH Transform Identifiers for the ISAKMP Proposal Payload for
 the IPSEC DOI.
 Note: the Authentication Algorithm attribute MUST be specified to
 identify the appropriate AH protection suite.  For example, AH_MD5
 can best be thought of as a generic AH transform using MD5.  To
 request the HMAC construction with AH, one specifies the AH_MD5
 transform ID along with the Authentication Algorithm attribute set to
 HMAC-MD5.  This is shown using the "Auth(HMAC-MD5)" notation in the
 following sections.
     Transform ID                        Value
     ------------                        -----
     RESERVED                            0-1
     AH_MD5                              2
     AH_SHA                              3
     AH_DES                              4
 Note: all mandatory-to-implement algorithms are listed as "MUST"
 implement (e.g. AH_MD5) in the following sections.  All other
 algorithms are optional and MAY be implemented in any particular
 implementation.

4.4.3.1 AH_MD5

 The AH_MD5 type specifies a generic AH transform using MD5.  The
 actual protection suite is determined in concert with an associated
 SA attribute list.  A generic MD5 transform is currently undefined.
 All implementations within the IPSEC DOI MUST support AH_MD5 along
 with the Auth(HMAC-MD5) attribute.  This suite is defined as the
 HMAC-MD5-96 transform described in [HMACMD5].
 The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH
 transform (Key/Pad/Data/Key) described in RFC-1826.

Piper Standards Track [Page 8] RFC 2407 IP Security Domain of Interpretation November 1998

 Use of AH_MD5 with any other Authentication Algorithm attribute value
 is currently undefined.

4.4.3.2 AH_SHA

 The AH_SHA type specifies a generic AH transform using SHA-1.  The
 actual protection suite is determined in concert with an associated
 SA attribute list.  A generic SHA transform is currently undefined.
 All implementations within the IPSEC DOI MUST support AH_SHA along
 with the Auth(HMAC-SHA) attribute.  This suite is defined as the
 HMAC-SHA-1-96 transform described in [HMACSHA].
 Use of AH_SHA with any other Authentication Algorithm attribute value
 is currently undefined.

4.4.3.3 AH_DES

 The AH_DES type specifies a generic AH transform using DES.  The
 actual protection suite is determined in concert with an associated
 SA attribute list.  A generic DES transform is currently undefined.
 The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute
 to be a DES-MAC transform.  Implementations are not required to
 support this mode.
 Use of AH_DES with any other Authentication Algorithm attribute value
 is currently undefined.

4.4.4 IPSEC ESP Transform Identifiers

 The Encapsulating Security Payload (ESP) defines one mandatory and
 many optional transforms used to provide data confidentiality.  The
 following table lists the defined ESP Transform Identifiers for the
 ISAKMP Proposal Payload for the IPSEC DOI.
 Note: when authentication, integrity protection, and replay detection
 are required, the Authentication Algorithm attribute MUST be
 specified to identify the appropriate ESP protection suite.  For
 example, to request HMAC-MD5 authentication with 3DES, one specifies
 the ESP_3DES transform ID with the Authentication Algorithm attribute
 set to HMAC-MD5.  For additional processing requirements, see Section
 4.5 (Authentication Algorithm).

Piper Standards Track [Page 9] RFC 2407 IP Security Domain of Interpretation November 1998

     Transform ID                        Value
     ------------                        -----
     RESERVED                            0
     ESP_DES_IV64                        1
     ESP_DES                             2
     ESP_3DES                            3
     ESP_RC5                             4
     ESP_IDEA                            5
     ESP_CAST                            6
     ESP_BLOWFISH                        7
     ESP_3IDEA                           8
     ESP_DES_IV32                        9
     ESP_RC4                             10
     ESP_NULL                            11
 Note: all mandatory-to-implement algorithms are listed as "MUST"
 implement (e.g. ESP_DES) in the following sections.  All other
 algorithms are optional and MAY be implemented in any particular
 implementation.

4.4.4.1 ESP_DES_IV64

 The ESP_DES_IV64 type specifies the DES-CBC transform defined in
 RFC-1827 and RFC-1829 using a 64-bit IV.

4.4.4.2 ESP_DES

 The ESP_DES type specifies a generic DES transform using DES-CBC.
 The actual protection suite is determined in concert with an
 associated SA attribute list.  A generic transform is currently
 undefined.
 All implementations within the IPSEC DOI MUST support ESP_DES along
 with the Auth(HMAC-MD5) attribute.  This suite is defined as the
 [DES] transform, with authentication and integrity provided by HMAC
 MD5 [HMACMD5].

4.4.4.3 ESP_3DES

 The ESP_3DES type specifies a generic triple-DES transform.  The
 actual protection suite is determined in concert with an associated
 SA attribute list.  The generic transform is currently undefined.
 All implementations within the IPSEC DOI are strongly encouraged to
 support ESP_3DES along with the Auth(HMAC-MD5) attribute.  This suite
 is defined as the [ESPCBC] transform, with authentication and
 integrity provided by HMAC MD5 [HMACMD5].

Piper Standards Track [Page 10] RFC 2407 IP Security Domain of Interpretation November 1998

4.4.4.4 ESP_RC5

 The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].

4.4.4.5 ESP_IDEA

 The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].

4.4.4.6 ESP_CAST

 The ESP_CAST type specifies the CAST transform defined in [ESPCBC].

4.4.4.7 ESP_BLOWFISH

 The ESP_BLOWFISH type specifies the BLOWFISH transform defined in
 [ESPCBC].

4.4.4.8 ESP_3IDEA

 The ESP_3IDEA type is reserved for triple-IDEA.

4.4.4.9 ESP_DES_IV32

 The ESP_DES_IV32 type specifies the DES-CBC transform defined in
 RFC-1827 and RFC-1829 using a 32-bit IV.

4.4.4.10 ESP_RC4

 The ESP_RC4 type is reserved for RC4.

4.4.4.11 ESP_NULL

 The ESP_NULL type specifies no confidentiality is to be provided by
 ESP.  ESP_NULL is used when ESP is being used to tunnel packets which
 require only authentication, integrity protection, and replay
 detection.
 All implementations within the IPSEC DOI MUST support ESP_NULL.  The
 ESP NULL transform is defined in [ESPNULL].  See the Authentication
 Algorithm attribute description in Section 4.5 for additional
 requirements relating to the use of ESP_NULL.

4.4.5 IPSEC IPCOMP Transform Identifiers

 The IP Compression (IPCOMP) transforms define optional compression
 algorithms that can be negotiated to provide for IP payload
 compression ([IPCOMP]).  The following table lists the defined IPCOMP
 Transform Identifiers for the ISAKMP Proposal Payload within the

Piper Standards Track [Page 11] RFC 2407 IP Security Domain of Interpretation November 1998

 IPSEC DOI.
     Transform ID                        Value
     ------------                        -----
     RESERVED                            0
     IPCOMP_OUI                          1
     IPCOMP_DEFLATE                      2
     IPCOMP_LZS                          3

4.4.5.1 IPCOMP_OUI

 The IPCOMP_OUI type specifies a proprietary compression transform.
 The IPCOMP_OUI type must be accompanied by an attribute which further
 identifies the specific vendor algorithm.

4.4.5.2 IPCOMP_DEFLATE

 The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate
 algorithm as specified in [DEFLATE].

4.4.5.3 IPCOMP_LZS

 The IPCOMP_LZS type specifies the use of the Stac Electronics LZS
 algorithm as specified in [LZS].

4.5 IPSEC Security Association Attributes

 The following SA attribute definitions are used in Phase II of an IKE
 negotiation.  Attribute types can be either Basic (B) or Variable-
 Length (V).  Encoding of these attributes is defined in the base
 ISAKMP specification.
 Attributes described as basic MUST NOT be encoded as variable.
 Variable length attributes MAY be encoded as basic attributes if
 their value can fit into two octets.  See [IKE] for further
 information on attribute encoding in the IPSEC DOI.  All restrictions
 listed in [IKE] also apply to the IPSEC DOI.

Piper Standards Track [Page 12] RFC 2407 IP Security Domain of Interpretation November 1998

     Attribute Types
           class               value           type
     -------------------------------------------------
     SA Life Type                1               B
     SA Life Duration            2               V
     Group Description           3               B
     Encapsulation Mode          4               B
     Authentication Algorithm    5               B
     Key Length                  6               B
     Key Rounds                  7               B
     Compress Dictionary Size    8               B
     Compress Private Algorithm  9               V
     Class Values
       SA Life Type
       SA Duration
         Specifies the time-to-live for the overall security
         association.  When the SA expires, all keys negotiated under
         the association (AH or ESP) must be renegotiated.  The life
         type values are:
         RESERVED                0
         seconds                 1
         kilobytes               2
         Values 3-61439 are reserved to IANA.  Values 61440-65535 are
         for private use.  For a given Life Type, the value of the
         Life Duration attribute defines the actual length of the
         component lifetime -- either a number of seconds, or a number
         of Kbytes that can be protected.
         If unspecified, the default value shall be assumed to be
         28800 seconds (8 hours).
         An SA Life Duration attribute MUST always follow an SA Life
         Type which describes the units of duration.
         See Section 4.5.4 for additional information relating to
         lifetime notification.
       Group Description
         Specifies the Oakley Group to be used in a PFS QM
         negotiation.  For a list of supported values, see Appendix A
         of [IKE].

Piper Standards Track [Page 13] RFC 2407 IP Security Domain of Interpretation November 1998

       Encapsulation Mode
         RESERVED                0
         Tunnel                  1
         Transport               2
         Values 3-61439 are reserved to IANA.  Values 61440-65535 are
         for private use.
         If unspecified, the default value shall be assumed to be
         unspecified (host-dependent).
       Authentication Algorithm
         RESERVED                0
         HMAC-MD5                1
         HMAC-SHA                2
         DES-MAC                 3
         KPDK                    4
         Values 5-61439 are reserved to IANA.  Values 61440-65535 are
         for private use.
         There is no default value for Auth Algorithm, as it must be
         specified to correctly identify the applicable AH or ESP
         transform, except in the following case.
         When negotiating ESP without authentication, the Auth
         Algorithm attribute MUST NOT be included in the proposal.
         When negotiating ESP without confidentiality, the Auth
         Algorithm attribute MUST be included in the proposal and the
         ESP transform ID must be ESP_NULL.
       Key Length
         RESERVED                0
         There is no default value for Key Length, as it must be
         specified for transforms using ciphers with variable key
         lengths.  For fixed length ciphers, the Key Length attribute
         MUST NOT be sent.
       Key Rounds
         RESERVED                0
         There is no default value for Key Rounds, as it must be
         specified for transforms using ciphers with varying numbers
         of rounds.

Piper Standards Track [Page 14] RFC 2407 IP Security Domain of Interpretation November 1998

       Compression Dictionary Size
         RESERVED                0
         Specifies the log2 maximum size of the dictionary.
         There is no default value for dictionary size.
       Compression Private Algorithm
         Specifies a private vendor compression algorithm.  The first
         three (3) octets must be an IEEE assigned company_id (OUI).
         The next octet may be a vendor specific compression subtype,
         followed by zero or more octets of vendor data.

4.5.1 Required Attribute Support

 To ensure basic interoperability, all implementations MUST be
 prepared to negotiate all of the following attributes.
         SA Life Type
         SA Duration
         Auth Algorithm

4.5.2 Attribute Parsing Requirement (Lifetime)

 To allow for flexible semantics, the IPSEC DOI requires that a
 conforming ISAKMP implementation MUST correctly parse an attribute
 list that contains multiple instances of the same attribute class, so
 long as the different attribute entries do not conflict with one
 another.  Currently, the only attributes which requires this
 treatment are Life Type and Duration.
 To see why this is important, the following example shows the binary
 encoding of a four entry attribute list that specifies an SA Lifetime
 of either 100MB or 24 hours.  (See Section 3.3 of [ISAKMP] for a
 complete description of the attribute encoding format.)
   Attribute #1:
     0x80010001  (AF = 1, type = SA Life Type, value = seconds)
   Attribute #2:
     0x00020004  (AF = 0, type = SA Duration, length = 4 bytes)
     0x00015180  (value = 0x15180 = 86400 seconds = 24 hours)
   Attribute #3:
     0x80010002  (AF = 1, type = SA Life Type, value = KB)

Piper Standards Track [Page 15] RFC 2407 IP Security Domain of Interpretation November 1998

   Attribute #4:
     0x00020004  (AF = 0, type = SA Duration, length = 4 bytes)
     0x000186A0  (value = 0x186A0 = 100000KB = 100MB)
 If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED
 Notification Payload SHOULD be returned and the security association
 setup MUST be aborted.

4.5.3 Attribute Negotiation

 If an implementation receives a defined IPSEC DOI attribute (or
 attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT
 SHOULD be sent and the security association setup MUST be aborted,
 unless the attribute value is in the reserved range.
 If an implementation receives an attribute value in the reserved
 range, an implementation MAY chose to continue based on local policy.

4.5.4 Lifetime Notification

 When an initiator offers an SA lifetime greater than what the
 responder desires based on their local policy, the responder has
 three choices: 1) fail the negotiation entirely; 2) complete the
 negotiation but use a shorter lifetime than what was offered; 3)
 complete the negotiation and send an advisory notification to the
 initiator indicating the responder's true lifetime.  The choice of
 what the responder actually does is implementation specific and/or
 based on local policy.
 To ensure interoperability in the latter case, the IPSEC DOI requires
 the following only when the responder wishes to notify the initiator:
 if the initiator offers an SA lifetime longer than the responder is
 willing to accept, the responder SHOULD include an ISAKMP
 Notification Payload in the exchange that includes the responder's
 IPSEC SA payload.  Section 4.6.3.1 defines the payload layout for the
 RESPONDER-LIFETIME Notification Message type which MUST be used for
 this purpose.

4.6 IPSEC Payload Content

 The following sections describe those ISAKMP payloads whose data
 representations are dependent on the applicable DOI.

4.6.1 Security Association Payload

 The following diagram illustrates the content of the Security
 Association Payload for the IPSEC DOI.  See Section 4.2 for a
 description of the Situation bitmap.

Piper Standards Track [Page 16] RFC 2407 IP Security Domain of Interpretation November 1998

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !  Next Payload !   RESERVED    !        Payload Length         !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !                Domain of Interpretation (IPSEC)               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !                       Situation (bitmap)                      !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !                    Labeled Domain Identifier                  !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !  Secrecy Length (in octets)   !           RESERVED            !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                        Secrecy Level                          ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Secrecy Cat. Length (in bits) !           RESERVED            !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                    Secrecy Category Bitmap                    ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Integrity Length (in octets)  !           RESERVED            !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                       Integrity Level                         ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Integ. Cat. Length (in bits)  !           RESERVED            !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                  Integrity Category Bitmap                    ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 1: Security Association Payload Format
 The Security Association Payload is defined as follows:
   o  Next Payload (1 octet) - Identifier for the payload type of
      the next payload in the message.  If the current payload is the
      last in the message, this field will be zero (0).
   o  RESERVED (1 octet) - Unused, must be zero (0).
   o  Payload Length (2 octets) - Length, in octets, of the current
      payload, including the generic header.
   o  Domain of Interpretation (4 octets) - Specifies the IPSEC DOI,
      which has been assigned the value one (1).
   o  Situation (4 octets) - Bitmask used to interpret the remainder
      of the Security Association Payload.  See Section 4.2 for a
      complete list of values.

Piper Standards Track [Page 17] RFC 2407 IP Security Domain of Interpretation November 1998

   o  Labeled Domain Identifier (4 octets) - IANA Assigned Number used
      to interpret the Secrecy and Integrity information.
   o  Secrecy Length (2 octets) - Specifies the length, in octets, of
      the secrecy level identifier, excluding pad bits.
   o  RESERVED (2 octets) - Unused, must be zero (0).
   o  Secrecy Level (variable length) - Specifies the mandatory
      secrecy level required.  The secrecy level MUST be padded with
      zero (0) to align on the next 32-bit boundary.
   o  Secrecy Category Length (2 octets) - Specifies the length, in
      bits, of the secrecy category (compartment) bitmap, excluding
      pad bits.
   o  RESERVED (2 octets) - Unused, must be zero (0).
   o  Secrecy Category Bitmap (variable length) - A bitmap used to
      designate secrecy categories (compartments) that are required.
      The bitmap MUST be padded with zero (0) to align on the next
      32-bit boundary.
   o  Integrity Length (2 octets) - Specifies the length, in octets,
      of the integrity level identifier, excluding pad bits.
   o  RESERVED (2 octets) - Unused, must be zero (0).
   o  Integrity Level (variable length) - Specifies the mandatory
      integrity level required.  The integrity level MUST be padded
      with zero (0) to align on the next 32-bit boundary.
   o  Integrity Category Length (2 octets) - Specifies the length, in
      bits, of the integrity category (compartment) bitmap, excluding
      pad bits.
   o  RESERVED (2 octets) - Unused, must be zero (0).
   o  Integrity Category Bitmap (variable length) - A bitmap used to
      designate integrity categories (compartments) that are required.
      The bitmap MUST be padded with zero (0) to align on the next
      32-bit boundary.

4.6.1.1 IPSEC Labeled Domain Identifiers

 The following table lists the assigned values for the Labeled Domain
 Identifier field contained in the Situation field of the Security
 Association Payload.

Piper Standards Track [Page 18] RFC 2407 IP Security Domain of Interpretation November 1998

     Domain                              Value
     -------                             -----
     RESERVED                            0

4.6.2 Identification Payload Content

 The Identification Payload is used to identify the initiator of the
 Security Association.  The identity of the initiator SHOULD be used
 by the responder to determine the correct host system security policy
 requirement for the association.  For example, a host might choose to
 require authentication and integrity without confidentiality (AH)
 from a certain set of IP addresses and full authentication with
 confidentiality (ESP) from another range of IP addresses.  The
 Identification Payload provides information that can be used by the
 responder to make this decision.
 During Phase I negotiations, the ID port and protocol fields MUST be
 set to zero or to UDP port 500.  If an implementation receives any
 other values, this MUST be treated as an error and the security
 association setup MUST be aborted.  This event SHOULD be auditable.
 The following diagram illustrates the content of the Identification
 Payload.
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !  Next Payload !   RESERVED    !        Payload Length         !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 !   ID Type     !  Protocol ID  !             Port              !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Identification Data                       ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 2: Identification Payload Format
 The Identification Payload fields are defined as follows:
   o  Next Payload (1 octet) - Identifier for the payload type of
      the next payload in the message.  If the current payload is the
      last in the message, this field will be zero (0).
   o  RESERVED (1 octet) - Unused, must be zero (0).
   o  Payload Length (2 octets) - Length, in octets, of the
      identification data, including the generic header.
   o  Identification Type (1 octet) - Value describing the identity
      information found in the Identification Data field.

Piper Standards Track [Page 19] RFC 2407 IP Security Domain of Interpretation November 1998

   o  Protocol ID (1 octet) - Value specifying an associated IP
      protocol ID (e.g. UDP/TCP).  A value of zero means that the
      Protocol ID field should be ignored.
   o  Port (2 octets) - Value specifying an associated port.  A value
      of zero means that the Port field should be ignored.
   o  Identification Data (variable length) - Value, as indicated by
      the Identification Type.

4.6.2.1 Identification Type Values

 The following table lists the assigned values for the Identification
 Type field found in the Identification Payload.
     ID Type                   Value
     -------                   -----
     RESERVED                            0
     ID_IPV4_ADDR                        1
     ID_FQDN                             2
     ID_USER_FQDN                        3
     ID_IPV4_ADDR_SUBNET                 4
     ID_IPV6_ADDR                        5
     ID_IPV6_ADDR_SUBNET                 6
     ID_IPV4_ADDR_RANGE                  7
     ID_IPV6_ADDR_RANGE                  8
     ID_DER_ASN1_DN                      9
     ID_DER_ASN1_GN                      10
     ID_KEY_ID                           11
 For types where the ID entity is variable length, the size of the ID
 entity is computed from size in the ID payload header.
 When an IKE exchange is authenticated using certificates (of any
 format), any ID's used for input to local policy decisions SHOULD be
 contained in the certificate used in the authentication of the
 exchange.

4.6.2.2 ID_IPV4_ADDR

 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.

4.6.2.3 ID_FQDN

 The ID_FQDN type specifies a fully-qualified domain name string.  An
 example of a ID_FQDN is, "foo.bar.com".  The string should not
 contain any terminators.

Piper Standards Track [Page 20] RFC 2407 IP Security Domain of Interpretation November 1998

4.6.2.4 ID_USER_FQDN

 The ID_USER_FQDN type specifies a fully-qualified username string, An
 example of a ID_USER_FQDN is, "piper@foo.bar.com".  The string should
 not contain any terminators.

4.6.2.5 ID_IPV4_ADDR_SUBNET

 The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses,
 represented by two four (4) octet values.  The first value is an IPv4
 address.  The second is an IPv4 network mask.  Note that ones (1s) in
 the network mask indicate that the corresponding bit in the address
 is fixed, while zeros (0s) indicate a "wildcard" bit.

4.6.2.6 ID_IPV6_ADDR

 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
 address.

4.6.2.7 ID_IPV6_ADDR_SUBNET

 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses,
 represented by two sixteen (16) octet values.  The first value is an
 IPv6 address.  The second is an IPv6 network mask.  Note that ones
 (1s) in the network mask indicate that the corresponding bit in the
 address is fixed, while zeros (0s) indicate a "wildcard" bit.

4.6.2.8 ID_IPV4_ADDR_RANGE

 The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses,
 represented by two four (4) octet values.  The first value is the
 beginning IPv4 address (inclusive) and the second value is the ending
 IPv4 address (inclusive).  All addresses falling between the two
 specified addresses are considered to be within the list.

4.6.2.9 ID_IPV6_ADDR_RANGE

 The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses,
 represented by two sixteen (16) octet values.  The first value is the
 beginning IPv6 address (inclusive) and the second value is the ending
 IPv6 address (inclusive).  All addresses falling between the two
 specified addresses are considered to be within the list.

4.6.2.10 ID_DER_ASN1_DN

 The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1
 X.500 Distinguished Name [X.501] of the principal whose certificates
 are being exchanged to establish the SA.

Piper Standards Track [Page 21] RFC 2407 IP Security Domain of Interpretation November 1998

4.6.2.11 ID_DER_ASN1_GN

 The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1
 X.500 GeneralName [X.509] of the principal whose certificates are
 being exchanged to establish the SA.

4.6.2.12 ID_KEY_ID

 The ID_KEY_ID type specifies an opaque byte stream which may be used
 to pass vendor-specific information necessary to identify which pre-
 shared key should be used to authenticate Aggressive mode
 negotiations.

4.6.3 IPSEC Notify Message Types

 ISAKMP defines two blocks of Notify Message codes, one for errors and
 one for status messages.  ISAKMP also allocates a portion of each
 block for private use within a DOI.  The IPSEC DOI defines the
 following private message types for its own use.
     Notify Messages - Error Types       Value
     -----------------------------       -----
     RESERVED                            8192
     Notify Messages - Status Types      Value
     ------------------------------      -----
     RESPONDER-LIFETIME                  24576
     REPLAY-STATUS                       24577
     INITIAL-CONTACT                     24578
 Notification Status Messages MUST be sent under the protection of an
 ISAKMP SA: either as a payload in the last Main Mode exchange; in a
 separate Informational Exchange after Main Mode or Aggressive Mode
 processing is complete; or as a payload in any Quick Mode exchange.
 These messages MUST NOT be sent in Aggressive Mode exchange, since
 Aggressive Mode does not provide the necessary protection to bind the
 Notify Status Message to the exchange.
 Nota Bene: a Notify payload is fully protected only in Quick Mode,
 where the entire payload is included in the HASH(n) digest.  In Main
 Mode, while the notify payload is encrypted, it is not currently
 included in the HASH(n) digests.  As a result, an active substitution
 attack on the Main Mode ciphertext could cause the notify status
 message type to be corrupted.  (This is true, in general, for the
 last message of any Main Mode exchange.)  While the risk is small, a
 corrupt notify message might cause the receiver to abort the entire
 negotiation thinking that the sender encountered a fatal error.

Piper Standards Track [Page 22] RFC 2407 IP Security Domain of Interpretation November 1998

 Implementation Note: the ISAKMP protocol does not guarantee delivery
 of Notification Status messages when sent in an ISAKMP Informational
 Exchange.  To ensure receipt of any particular message, the sender
 SHOULD include a Notification Payload in a defined Main Mode or Quick
 Mode exchange which is protected by a retransmission timer.

4.6.3.1 RESPONDER-LIFETIME

 The RESPONDER-LIFETIME status message may be used to communicate the
 IPSEC SA lifetime chosen by the responder.
 When present, the Notification Payload MUST have the following
 format:
   o  Payload Length - set to length of payload + size of data (var)
   o  DOI - set to IPSEC DOI (1)
   o  Protocol ID - set to selected Protocol ID from chosen SA
   o  SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
      cookies) or four (4) (one IPSEC SPI)
   o  Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3)
   o  SPI - set to the two ISAKMP cookies or to the sender's inbound
      IPSEC SPI
   o  Notification Data - contains an ISAKMP attribute list with the
      responder's actual SA lifetime(s)
 Implementation Note: saying that the Notification Data field contains
 an attribute list is equivalent to saying that the Notification Data
 field has zero length and the Notification Payload has an associated
 attribute list.

4.6.3.2 REPLAY-STATUS

 The REPLAY-STATUS status message may be used for positive
 confirmation of the responder's election on whether or not he is to
 perform anti-replay detection.
 When present, the Notification Payload MUST have the following
 format:
   o  Payload Length - set to length of payload + size of data (4)
   o  DOI - set to IPSEC DOI (1)
   o  Protocol ID - set to selected Protocol ID from chosen SA
   o  SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
      cookies) or four (4) (one IPSEC SPI)
   o  Notify Message Type - set to REPLAY-STATUS
   o  SPI - set to the two ISAKMP cookies or to the sender's inbound
      IPSEC SPI
   o  Notification Data - a 4 octet value:

Piper Standards Track [Page 23] RFC 2407 IP Security Domain of Interpretation November 1998

        0 = replay detection disabled
        1 = replay detection enabled

4.6.3.3 INITIAL-CONTACT

 The INITIAL-CONTACT status message may be used when one side wishes
 to inform the other that this is the first SA being established with
 the remote system.  The receiver of this Notification Message might
 then elect to delete any existing SA's it has for the sending system
 under the assumption that the sending system has rebooted and no
 longer has access to the original SA's and their associated keying
 material.  When used, the content of the Notification Data field
 SHOULD be null (i.e. the Payload Length should be set to the fixed
 length of Notification Payload).
 When present, the Notification Payload MUST have the following
 format:
   o  Payload Length - set to length of payload + size of data (0)
   o  DOI - set to IPSEC DOI (1)
   o  Protocol ID - set to selected Protocol ID from chosen SA
   o  SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies)
   o  Notify Message Type - set to INITIAL-CONTACT
   o  SPI - set to the two ISAKMP cookies
   o  Notification Data - <not included>

4.7 IPSEC Key Exchange Requirements

 The IPSEC DOI introduces no additional Key Exchange types.

5. Security Considerations

 This entire memo pertains to the Internet Key Exchange protocol
 ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to
 provide for the derivation of cryptographic keying material in a
 secure and authenticated manner.  Specific discussion of the various
 security protocols and transforms identified in this document can be
 found in the associated base documents and in the cipher references.

6. IANA Considerations

 This document contains many "magic" numbers to be maintained by the
 IANA.  This section explains the criteria to be used by the IANA to
 assign additional numbers in each of these lists.  All values not
 explicitly defined in previous sections are reserved to IANA.

Piper Standards Track [Page 24] RFC 2407 IP Security Domain of Interpretation November 1998

6.1 IPSEC Situation Definition

 The Situation Definition is a 32-bit bitmask which represents the
 environment under which the IPSEC SA proposal and negotiation is
 carried out.  Requests for assignments of new situations must be
 accompanied by an RFC which describes the interpretation for the
 associated bit.
 If the RFC is not on the standards-track (i.e., it is an
 informational or experimental RFC), it must be explicitly reviewed
 and approved by the IESG before the RFC is published and the
 transform identifier is assigned.
 The upper two bits are reserved for private use amongst cooperating
 systems.

6.2 IPSEC Security Protocol Identifiers

 The Security Protocol Identifier is an 8-bit value which identifies a
 security protocol suite being negotiated.  Requests for assignments
 of new security protocol identifiers must be accompanied by an RFC
 which describes the requested security protocol.  [AH] and [ESP] are
 examples of security protocol documents.
 If the RFC is not on the standards-track (i.e., it is an
 informational or experimental RFC), it must be explicitly reviewed
 and approved by the IESG before the RFC is published and the
 transform identifier is assigned.
 The values 249-255 are reserved for private use amongst cooperating
 systems.

6.3 IPSEC ISAKMP Transform Identifiers

 The IPSEC ISAKMP Transform Identifier is an 8-bit value which
 identifies a key exchange protocol to be used for the negotiation.
 Requests for assignments of new ISAKMP transform identifiers must be
 accompanied by an RFC which describes the requested key exchange
 protocol.  [IKE] is an example of one such document.
 If the RFC is not on the standards-track (i.e., it is an
 informational or experimental RFC), it must be explicitly reviewed
 and approved by the IESG before the RFC is published and the
 transform identifier is assigned.
 The values 249-255 are reserved for private use amongst cooperating
 systems.

Piper Standards Track [Page 25] RFC 2407 IP Security Domain of Interpretation November 1998

6.4 IPSEC AH Transform Identifiers

 The IPSEC AH Transform Identifier is an 8-bit value which identifies
 a particular algorithm to be used to provide integrity protection for
 AH.  Requests for assignments of new AH transform identifiers must be
 accompanied by an RFC which describes how to use the algorithm within
 the AH framework ([AH]).
 If the RFC is not on the standards-track (i.e., it is an
 informational or experimental RFC), it must be explicitly reviewed
 and approved by the IESG before the RFC is published and the
 transform identifier is assigned.
 The values 249-255 are reserved for private use amongst cooperating
 systems.

6.5 IPSEC ESP Transform Identifiers

 The IPSEC ESP Transform Identifier is an 8-bit value which identifies
 a particular algorithm to be used to provide secrecy protection for
 ESP.  Requests for assignments of new ESP transform identifiers must
 be accompanied by an RFC which describes how to use the algorithm
 within the ESP framework ([ESP]).
 If the RFC is not on the standards-track (i.e., it is an
 informational or experimental RFC), it must be explicitly reviewed
 and approved by the IESG before the RFC is published and the
 transform identifier is assigned.
 The values 249-255 are reserved for private use amongst cooperating
 systems.

6.6 IPSEC IPCOMP Transform Identifiers

 The IPSEC IPCOMP Transform Identifier is an 8-bit value which
 identifier a particular algorithm to be used to provide IP-level
 compression before ESP.  Requests for assignments of new IPCOMP
 transform identifiers must be accompanied by an RFC which describes
 how to use the algorithm within the IPCOMP framework ([IPCOMP]).  In
 addition, the requested algorithm must be published and in the public
 domain.
 If the RFC is not on the standards-track (i.e., it is an
 informational or experimental RFC), it must be explicitly reviewed
 and approved by the IESG before the RFC is published and the
 transform identifier is assigned.

Piper Standards Track [Page 26] RFC 2407 IP Security Domain of Interpretation November 1998

 The values 1-47 are reserved for algorithms for which an RFC has been
 approved for publication.  The values 48-63 are reserved for private
 use amongst cooperating systems.  The values 64-255 are reserved for
 future expansion.

6.7 IPSEC Security Association Attributes

 The IPSEC Security Association Attribute consists of a 16-bit type
 and its associated value.  IPSEC SA attributes are used to pass
 miscellaneous values between ISAKMP peers.  Requests for assignments
 of new IPSEC SA attributes must be accompanied by an Internet Draft
 which describes the attribute encoding (Basic/Variable-Length) and
 its legal values.  Section 4.5 of this document provides an example
 of such a description.
 The values 32001-32767 are reserved for private use amongst
 cooperating systems.

6.8 IPSEC Labeled Domain Identifiers

 The IPSEC Labeled Domain Identifier is a 32-bit value which
 identifies a namespace in which the Secrecy and Integrity levels and
 categories values are said to exist.  Requests for assignments of new
 IPSEC Labeled Domain Identifiers should be granted on demand.  No
 accompanying documentation is required, though Internet Drafts are
 encouraged when appropriate.
 The values 0x80000000-0xffffffff are reserved for private use amongst
 cooperating systems.

6.9 IPSEC Identification Type

 The IPSEC Identification Type is an 8-bit value which is used as a
 discriminant for interpretation of the variable-length Identification
 Payload.  Requests for assignments of new IPSEC Identification Types
 must be accompanied by an RFC which describes how to use the
 identification type within IPSEC.
 If the RFC is not on the standards-track (i.e., it is an
 informational or experimental RFC), it must be explicitly reviewed
 and approved by the IESG before the RFC is published and the
 transform identifier is assigned.
 The values 249-255 are reserved for private use amongst cooperating
 systems.

Piper Standards Track [Page 27] RFC 2407 IP Security Domain of Interpretation November 1998

6.10 IPSEC Notify Message Types

 The IPSEC Notify Message Type is a 16-bit value taken from the range
 of values reserved by ISAKMP for each DOI.  There is one range for
 error messages (8192-16383) and a different range for status messages
 (24576-32767).  Requests for assignments of new Notify Message Types
 must be accompanied by an Internet Draft which describes how to use
 the identification type within IPSEC.
 The values 16001-16383 and the values 32001-32767 are reserved for
 private use amongst cooperating systems.

7. Change Log

7.1 Changes from V9

   o  add explicit reference to [IPCOMP], [DEFLATE], and [LZS]
   o  allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed
      at an IPSEC SPI in addition to the ISAKMP "SPI"
   o  added padding exclusion to Secrecy and Integrity Length text
   o  added forward reference to Section 4.5 in Section 4.4.4
   o  update document references

7.2 Changes from V8

   o  update IPCOMP identifier range to better reflect IPCOMP draft
   o  update IANA considerations per Jeff/Ted's suggested text
   o  eliminate references to DES-MAC ID ([DESMAC])
   o  correct bug in Notify section; ISAKMP Notify values are 16-bits

7.3 Changes from V7

   o  corrected name of IPCOMP (IP Payload Compression)
   o  corrected references to [ESPCBC]
   o  added missing Secrecy Level and Integrity Level to Figure 1
   o  removed ID references to PF_KEY and ARCFOUR
   o  updated Basic/Variable text to align with [IKE]
   o  updated document references and add intro pointer to [ARCH]
   o  updated Notification requirements; remove aggressive reference
   o  added clarification about protection for Notify payloads
   o  restored RESERVED to ESP transform ID namespace; moved ESP_NULL
   o  added requirement for ESP_NULL support and [ESPNULL] reference
   o  added clarification on Auth Alg use with AH/ESP
   o  added restriction against using conflicting AH/Auth combinations

7.4 Changes from V6

 The following changes were made relative to the IPSEC DOI V6:

Piper Standards Track [Page 28] RFC 2407 IP Security Domain of Interpretation November 1998

   o  added IANA Considerations section
   o  moved most IANA numbers to IANA Considerations section
   o  added prohibition on sending (V) encoding for (B) attributes
   o  added prohibition on sending Key Length attribute for fixed
      length ciphers (e.g. DES)
   o  replaced references to ISAKMP/Oakley with IKE
   o  renamed ESP_ARCFOUR to ESP_RC4
   o  updated Security Considerations section
   o  updated document references

7.5 Changes from V5

 The following changes were made relative to the IPSEC DOI V5:
   o  changed SPI size in Lifetime Notification text
   o  changed REPLAY-ENABLED to REPLAY-STATUS
   o  moved RESPONDER-LIFETIME payload definition from Section 4.5.4
      to Section 4.6.3.1
   o  added explicit payload layout for 4.6.3.3
   o  added Implementation Note to Section 4.6.3 introduction
   o  changed AH_SHA text to require SHA-1 in addition to MD5
   o  updated document references

7.6 Changes from V4

 The following changes were made relative to the IPSEC DOI V4:
   o  moved compatibility AH KPDK authentication method from AH
      transform ID to Authentication Algorithm identifier
   o  added REPLAY-ENABLED notification message type per Architecture
   o  added INITIAL-CONTACT notification message type per list
   o  added text to ensure protection for Notify Status messages
   o  added Lifetime qualification to attribute parsing section
   o  added clarification that Lifetime notification is optional
   o  removed private Group Description list (now points at [IKE])
   o  replaced Terminology with pointer to RFC-2119
   o  updated HMAC MD5 and SHA-1 ID references
   o  updated Section 1 (Abstract)
   o  updated Section 4.4 (IPSEC Assigned Numbers)
   o  added restriction for ID port/protocol values for Phase I

7.7 Changes from V3 to V4

 The following changes were made relative to the IPSEC DOI V3, that
 was posted to the IPSEC mailing list prior to the Munich IETF:
   o  added ESP transform identifiers for NULL and ARCFOUR

Piper Standards Track [Page 29] RFC 2407 IP Security Domain of Interpretation November 1998

   o  renamed HMAC Algorithm to Auth Algorithm to accommodate
      DES-MAC and optional authentication/integrity for ESP
   o  added AH and ESP DES-MAC algorithm identifiers
   o  removed KEY_MANUAL and KEY_KDC identifier definitions
   o  added lifetime duration MUST follow lifetype attribute to
      SA Life Type and SA Life Duration attribute definition
   o  added lifetime notification and IPSEC DOI message type table
   o  added optional authentication and confidentiality
      restrictions to MAC Algorithm attribute definition
   o  corrected attribute parsing example (used obsolete attribute)
   o  corrected several Internet Draft document references
   o  added ID_KEY_ID per ipsec list discussion (18-Mar-97)
   o  removed Group Description default for PFS QM ([IKE] MUST)

Acknowledgments

 This document is derived, in part, from previous works by Douglas
 Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,
 and Dave Carrel.  Matt Thomas, Roy Pereira, Greg Carter, and Ran
 Atkinson also contributed suggestions and, in many cases, text.

References

 [AH]      Kent, S., and R. Atkinson, "IP Authentication Header", RFC
           2402, November 1998.
 [ARCH]    Kent, S., and R. Atkinson, "Security Architecture for the
           Internet Protocol", RFC 2401, November 1998.
 [DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC
           2394, August 1998.
 [ESP]     Kent, S., and R. Atkinson, "IP Encapsulating Security
           Payload (ESP)", RFC 2406, November 1998.
 [ESPCBC]  Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher
           Algorithms", RFC 2451, November 1998.
 [ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and
           Its Use With IPsec", RFC 2410, November 1998.
 [DES]     Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
           Algorithm With Explicit IV", RFC 2405, November 1998.
 [HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP
           and AH", RFC 2403, November 1998.

Piper Standards Track [Page 30] RFC 2407 IP Security Domain of Interpretation November 1998

 [HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
           ESP and AH", RFC 2404, November 1998.
 [IKE]     Harkins, D., and D. Carrel, D., "The Internet Key Exchange
           (IKE)", RFC 2409, November 1998.
 [IPCOMP]  Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
           Payload Compression Protocol (IPComp)", RFC 2393, August
           1998.
 [ISAKMP]  Maughan, D., Schertler, M., Schneider, M., and J. Turner,
           "Internet Security Association and Key Management Protocol
           (ISAKMP)", RFC 2408, November 1998.
 [LZS]     Friend, R., and R. Monsour, "IP Payload Compression Using
           LZS", RFC 2395, August 1998.
 [OAKLEY]  Orman, H., "The OAKLEY Key Determination Protocol", RFC
           2412, November 1998.
 [X.501]   ISO/IEC 9594-2, "Information Technology - Open Systems
           Interconnection - The Directory:  Models", CCITT/ITU
           Recommendation X.501, 1993.
 [X.509]   ISO/IEC 9594-8, "Information Technology - Open Systems
           Interconnection - The Directory:  Authentication
           Framework", CCITT/ITU Recommendation X.509, 1993.

Author's Address

 Derrell Piper
 Network Alchemy
 1521.5 Pacific Ave
 Santa Cruz, California, 95060
 United States of America
 Phone: +1 408 460-3822
 EMail: ddp@network-alchemy.com

Piper Standards Track [Page 31] RFC 2407 IP Security Domain of Interpretation November 1998

Full Copyright Statement

 Copyright (C) The Internet Society (1998).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Piper Standards Track [Page 32]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2407.txt · Last modified: 1998/11/24 20:38 (external edit)