As per Relevance of the word specifies, we have this rfc below:
Network Working Group D.
Request for Comments: 2407 Network
Category: Standards Track November 1998
The Internet IP Security Domain of Interpretation for
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
IESG
Section 4.4.4.2 states, "All implememtations within the IPSEC
MUST support ESP_DES...". Recent work in the area of
suggests that DES may not be sufficiently strong for
applications. Therefore, it is very likely that the IETF
deprecate the use of ESP_DES as a mandatory cipher suite in the
future. It will remain as an optional use protocol. Although
IPsec working group and the IETF in general have not settled on
alternative algorithm (taking into account concerns of security
performance), implementers may want to heed the recommendations
section 4.4.4.3 on the use of ESP_3DES
1.
The Internet Security Association and Key Management
(ISAKMP) defines a framework for security association management
cryptographic key establishment for the Internet. This
consists of defined exchanges, payloads, and processing
that occur within a given Domain of Interpretation (DOI).
document defines the Internet IP Security DOI (IPSEC DOI),
instantiates ISAKMP for use with IP when IP uses ISAKMP to
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.
Within ISAKMP, a Domain of Interpretation is used to group
protocols using ISAKMP to negotiate security associations.
protocols sharing a DOI choose security protocol and
transforms from a common namespace and share key exchange
identifiers. They also share a common interpretation of DOI-
payload data content, including the Security Association
Identification payloads
Overall, ISAKMP places the following requirements on a
definition
o define the naming scheme for DOI-specific protocol
o define the interpretation for the Situation
o define the set of applicable security
o define the syntax for DOI-specific SA Attributes (Phase II
o define the syntax for DOI-specific payload
o define additional Key Exchange types, if
o define additional Notification Message types, if
The remainder of this document details the instantiation of
requirements for using the IP Security (IPSEC) protocols to
authentication, integrity, and/or confidentiality for IP packets
between cooperating host systems and/or firewalls
For a description of the overall IPSEC architecture, see [ARCH],
[AH], and [ESP].
3. Terms and
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [RFC 2119].
4.1 IPSEC Naming
Within ISAKMP, all DOI's must be registered with the IANA in
"Assigned Numbers" RFC [STD-2]. The IANA Assigned Number for
Internet IP Security DOI (IPSEC DOI) is one (1). Within the
DOI, all well-known identifiers MUST be registered with the
under the IPSEC DOI. Unless otherwise noted, all tables within
document refer to IANA Assigned Numbers for the IPSEC DOI.
Section 6 for further information relating to the IANA registry
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
Within ISAKMP, the Situation provides information that can be used
the responder to make a policy determination about how to process
incoming Security Association request. For the IPSEC DOI,
Situation field is a four (4) octet bitmask with the
values
Situation
--------- -----
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04
4.2.1 SIT_IDENTITY_
The SIT_IDENTITY_ONLY type specifies that the security
will be identified by source identity information present in
associated Identification Payload. See Section 4.6.2 for a
description of the various Identification types. All IPSEC
implementations MUST support SIT_IDENTITY_ONLY by including
Identification Payload in at least one of the Phase I
exchanges ([IKE], Section 5) and MUST abort any association
that does not include an Identification Payload
If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY,
situation consists only of the 4 octet situation bitmap and does
include the Labeled Domain Identifier field (Figure 1, Section 4.6.1)
or any subsequent label information. Conversely, if the
supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled
Identifier MUST be included in the situation payload
4.2.2 SIT_
The SIT_SECRECY type specifies that the security association is
negotiated in an environment that requires labeled secrecy.
SIT_SECRECY is present in the Situation bitmap, the Situation
will be followed by variable-length data that includes a
level and compartment bitmask. See Section 4.6.1 for a
description of the Security Association Payload format
If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT
set in the Situation bitmap and no secrecy level or category
shall be included
If a responder does not support SIT_SECRECY, a SITUATION-NOT
SUPPORTED Notification Payload SHOULD be returned and the
association setup MUST be aborted
Piper Standards Track [Page 3]
RFC 2407 IP Security Domain of Interpretation November 1998
4.2.3 SIT_
The SIT_INTEGRITY type specifies that the security association
being negotiated in an environment that requires labeled integrity
If SIT_INTEGRITY is present in the Situation bitmap, the
field will be followed by variable-length data that includes
integrity level and compartment bitmask. If SIT_SECRECY is also
use for the association, the integrity information
follows the variable-length secrecy level and categories.
section 4.6.1 for a complete description of the Security
Payload format
If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY
NOT be set in the Situation bitmap and no integrity level or
bitmaps shall be included
If a responder does not support SIT_INTEGRITY, a SITUATION-NOT
SUPPORTED Notification Payload SHOULD be returned and the
association setup MUST be aborted
4.3 IPSEC Security Policy
The IPSEC DOI does not impose specific security policy
on any implementation. Host system policy issues are outside of
scope of this document
However, the following sections touch on some of the issues that
be considered when designing an IPSEC DOI host implementation.
section should be considered only informational in nature
4.3.1 Key Management
It is expected that many systems choosing to implement ISAKMP
strive to provide a protected domain of execution for a combined
key management daemon. On protected-mode multiuser
systems, this key management daemon will likely exist as a
privileged process
In such an environment, a formalized API to introduce keying
into the TCP/IP kernel may be desirable. The IP
architecture does not place any requirements for structure or
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
Host systems that implement static keys, either for use directly
IPSEC, or for authentication purposes (see [IKE] Section 5.4),
take steps to protect the static keying material when it is
residing in a protected memory domain or actively in use by
TCP/IP kernel
For example, on a laptop, one might choose to store the static
in a configuration store that is, itself, encrypted under a
password
Depending on the operating system and utility software installed,
may not be possible to protect the static keys once they've
loaded into the TCP/IP kernel, however they should not be
recoverable on initial system startup without having to satisfy
additional form of authentication
4.3.3 Host Policy
It is not realistic to assume that the transition to IPSEC will
overnight. Host systems must be prepared to implement
policy lists that describe which systems they desire to
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,
masks, and a security required flag or flags
A more flexible implementation might consist of a list of
DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an
firewall address. The wildcard DNS name would be used to
incoming or outgoing IP addresses, the in/out bitmask would be
to determine whether or not security was to be applied and in
direction, and the optional firewall address would be used
indicate whether or not tunnel mode would be needed to talk to
target system though an intermediate firewall
4.3.4 Certificate
Host systems implementing a certificate-based authentication
will need a mechanism for obtaining and managing a database
certificates
Secure DNS is to be one certificate distribution mechanism,
the pervasive availability of secure DNS zones, in the short term,
doubtful for many reasons. What's far more likely is that hosts
Piper Standards Track [Page 5]
RFC 2407 IP Security Domain of Interpretation November 1998
need an ability to import certificates that they acquire
secure, out-of-band mechanisms, as well as an ability to export
own certificates for use by other systems
However, manual certificate management should not be done so as
preclude the ability to introduce dynamic certificate
mechanisms and/or protocols as they become available
4.4 IPSEC Assigned
The following sections list the Assigned Numbers for the IPSEC DOI
Situation Identifiers, Protocol Identifiers, Transform Identifiers
AH, ESP, and IPCOMP Transform Identifiers, Security
Attribute Type Values, Labeled Domain Identifiers, ID Payload
Values, and Notify Message Type Values
4.4.1 IPSEC Security Protocol
The ISAKMP proposal syntax was specifically designed to allow for
simultaneous negotiation of multiple Phase II security
suites within a single negotiation. As a result, the protocol
listed below form the set of protocols that can be negotiated at
same time. It is a host policy decision as to what protocol
might be negotiated together
The following table lists the values for the Security
Identifiers referenced in an ISAKMP Proposal Payload for the
DOI
Protocol ID
----------- -----
RESERVED 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
4.4.1.1 PROTO_
The PROTO_ISAKMP type specifies message protection required
Phase I of the ISAKMP protocol. The specific protection
used for the IPSEC DOI is described in [IKE]. All
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_
The PROTO_IPSEC_AH type specifies IP packet authentication.
default AH transform provides data origin authentication,
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_
The PROTO_IPSEC_ESP type specifies IP packet confidentiality
Authentication, if required, must be provided as part of the
transform. The default ESP transform includes data
authentication, integrity protection, replay detection,
confidentiality
4.4.1.4 PROTO_
The PROTO_IPCOMP type specifies IP payload compression as defined
[IPCOMP].
4.4.2 IPSEC ISAKMP Transform
As part of an ISAKMP Phase I negotiation, the initiator's choice
Key Exchange offerings is made using some host system
description. The actual selection of Key Exchange mechanism is
using the standard ISAKMP Proposal Payload. The following
lists the defined ISAKMP Phase I Transform Identifiers for
Proposal Payload for the IPSEC DOI
Transform
--------- -----
RESERVED 0
KEY_IKE 1
Within the ISAKMP and IPSEC DOI framework it is possible to
key establishment protocols other than IKE (Oakley).
versions of this document defined types both for manual keying
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
additional non-Oakley key establishment protocols for ISAKMP
IPSEC, such as Kerberos [RFC-1510] or the Group Key
Protocol (GKMP) [RFC-2093].
Piper Standards Track [Page 7]
RFC 2407 IP Security Domain of Interpretation November 1998
4.4.2.1 KEY_
The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-
key exchange (IKE) as defined in the [IKE] document.
implementations within the IPSEC DOI MUST support KEY_IKE
4.4.3 IPSEC AH Transform
The Authentication Header Protocol (AH) defines one mandatory
several optional transforms used to provide authentication
integrity, and replay detection. The following table lists
defined AH Transform Identifiers for the ISAKMP Proposal Payload
the IPSEC DOI
Note: the Authentication Algorithm attribute MUST be specified
identify the appropriate AH protection suite. For example, AH_MD
can best be thought of as a generic AH transform using MD5.
request the HMAC construction with AH, one specifies the AH_MD
transform ID along with the Authentication Algorithm attribute set
HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in
following sections
Transform ID
------------ -----
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
algorithms are optional and MAY be implemented in any
implementation
4.4.3.1 AH_MD
The AH_MD5 type specifies a generic AH transform using MD5.
actual protection suite is determined in concert with an
SA attribute list. A generic MD5 transform is currently undefined
All implementations within the IPSEC DOI MUST support AH_MD5
with the Auth(HMAC-MD5) attribute. This suite is defined as
HMAC-MD5-96 transform described in [HMACMD5].
The AH_MD5 type along with the Auth(KPDK) attribute specifies the
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
is currently undefined
4.4.3.2 AH_
The AH_SHA type specifies a generic AH transform using SHA-1.
actual protection suite is determined in concert with an
SA attribute list. A generic SHA transform is currently undefined
All implementations within the IPSEC DOI MUST support AH_SHA
with the Auth(HMAC-SHA) attribute. This suite is defined as
HMAC-SHA-1-96 transform described in [HMACSHA].
Use of AH_SHA with any other Authentication Algorithm attribute
is currently undefined
4.4.3.3 AH_
The AH_DES type specifies a generic AH transform using DES.
actual protection suite is determined in concert with an
SA attribute list. A generic DES transform is currently undefined
The IPSEC DOI defines AH_DES along with the Auth(DES-MAC)
to be a DES-MAC transform. Implementations are not required
support this mode
Use of AH_DES with any other Authentication Algorithm attribute
is currently undefined
4.4.4 IPSEC ESP Transform
The Encapsulating Security Payload (ESP) defines one mandatory
many optional transforms used to provide data confidentiality.
following table lists the defined ESP Transform Identifiers for
ISAKMP Proposal Payload for the IPSEC DOI
Note: when authentication, integrity protection, and replay
are required, the Authentication Algorithm attribute MUST
specified to identify the appropriate ESP protection suite.
example, to request HMAC-MD5 authentication with 3DES, one
the ESP_3DES transform ID with the Authentication Algorithm
set to HMAC-MD5. For additional processing requirements, see
4.5 (Authentication Algorithm).
Piper Standards Track [Page 9]
RFC 2407 IP Security Domain of Interpretation November 1998
Transform ID
------------ -----
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
algorithms are optional and MAY be implemented in any
implementation
4.4.4.1 ESP_DES_IV64
The ESP_DES_IV64 type specifies the DES-CBC transform defined
RFC-1827 and RFC-1829 using a 64-bit IV
4.4.4.2 ESP_
The ESP_DES type specifies a generic DES transform using DES-CBC
The actual protection suite is determined in concert with
associated SA attribute list. A generic transform is
undefined
All implementations within the IPSEC DOI MUST support ESP_DES
with the Auth(HMAC-MD5) attribute. This suite is defined as
[DES] transform, with authentication and integrity provided by
MD5 [HMACMD5].
4.4.4.3 ESP_3
The ESP_3DES type specifies a generic triple-DES transform.
actual protection suite is determined in concert with an
SA attribute list. The generic transform is currently undefined
All implementations within the IPSEC DOI are strongly encouraged
support ESP_3DES along with the Auth(HMAC-MD5) attribute. This
is defined as the [ESPCBC] transform, with authentication
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_RC
The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].
4.4.4.5 ESP_
The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].
4.4.4.6 ESP_
The ESP_CAST type specifies the CAST transform defined in [ESPCBC].
4.4.4.7 ESP_
The ESP_BLOWFISH type specifies the BLOWFISH transform defined
[ESPCBC].
4.4.4.8 ESP_3
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
RFC-1827 and RFC-1829 using a 32-bit IV
4.4.4.10 ESP_RC
The ESP_RC4 type is reserved for RC4.
4.4.4.11 ESP_
The ESP_NULL type specifies no confidentiality is to be provided
ESP. ESP_NULL is used when ESP is being used to tunnel packets
require only authentication, integrity protection, and
detection
All implementations within the IPSEC DOI MUST support ESP_NULL.
ESP NULL transform is defined in [ESPNULL]. See the
Algorithm attribute description in Section 4.5 for
requirements relating to the use of ESP_NULL
4.4.5 IPSEC IPCOMP Transform
The IP Compression (IPCOMP) transforms define optional
algorithms that can be negotiated to provide for IP
compression ([IPCOMP]). The following table lists the defined
Transform Identifiers for the ISAKMP Proposal Payload within
Piper Standards Track [Page 11]
RFC 2407 IP Security Domain of Interpretation November 1998
IPSEC DOI
Transform ID
------------ -----
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
4.4.5.1 IPCOMP_
The IPCOMP_OUI type specifies a proprietary compression transform
The IPCOMP_OUI type must be accompanied by an attribute which
identifies the specific vendor algorithm
4.4.5.2 IPCOMP_
The IPCOMP_DEFLATE type specifies the use of the "zlib"
algorithm as specified in [DEFLATE].
4.4.5.3 IPCOMP_
The IPCOMP_LZS type specifies the use of the Stac Electronics
algorithm as specified in [LZS].
4.5 IPSEC Security Association
The following SA attribute definitions are used in Phase II of an
negotiation. Attribute types can be either Basic (B) or Variable
Length (V). Encoding of these attributes is defined in the
ISAKMP specification
Attributes described as basic MUST NOT be encoded as variable
Variable length attributes MAY be encoded as basic attributes
their value can fit into two octets. See [IKE] for
information on attribute encoding in the IPSEC DOI. All
listed in [IKE] also apply to the IPSEC DOI
Piper Standards Track [Page 12]
RFC 2407 IP Security Domain of Interpretation November 1998
Attribute
class value
-------------------------------------------------
SA Life Type 1
SA Life Duration 2
Group Description 3
Encapsulation Mode 4
Authentication Algorithm 5
Key Length 6
Key Rounds 7
Compress Dictionary Size 8
Compress Private Algorithm 9
Class
SA Life
SA
Specifies the time-to-live for the overall
association. When the SA expires, all keys negotiated
the association (AH or ESP) must be renegotiated. The
type values are
RESERVED 0
seconds 1
kilobytes 2
Values 3-61439 are reserved to IANA. Values 61440-65535
for private use. For a given Life Type, the value of
Life Duration attribute defines the actual length of
component lifetime -- either a number of seconds, or a
of Kbytes that can be protected
If unspecified, the default value shall be assumed to
28800 seconds (8 hours).
An SA Life Duration attribute MUST always follow an SA
Type which describes the units of duration
See Section 4.5.4 for additional information relating
lifetime notification
Group
Specifies the Oakley Group to be used in a PFS
negotiation. For a list of supported values, see Appendix
of [IKE].
Piper Standards Track [Page 13]
RFC 2407 IP Security Domain of Interpretation November 1998
Encapsulation
RESERVED 0
Tunnel 1
Transport 2
Values 3-61439 are reserved to IANA. Values 61440-65535
for private use
If unspecified, the default value shall be assumed to
unspecified (host-dependent).
Authentication
RESERVED 0
HMAC-MD5 1
HMAC-SHA 2
DES-MAC 3
KPDK 4
Values 5-61439 are reserved to IANA. Values 61440-65535
for private use
There is no default value for Auth Algorithm, as it must
specified to correctly identify the applicable AH or
transform, except in the following case
When negotiating ESP without authentication, the
Algorithm attribute MUST NOT be included in the proposal
When negotiating ESP without confidentiality, the
Algorithm attribute MUST be included in the proposal and
ESP transform ID must be ESP_NULL
Key
RESERVED 0
There is no default value for Key Length, as it must
specified for transforms using ciphers with variable
lengths. For fixed length ciphers, the Key Length
MUST NOT be sent
Key
RESERVED 0
There is no default value for Key Rounds, as it must
specified for transforms using ciphers with varying
of rounds
Piper Standards Track [Page 14]
RFC 2407 IP Security Domain of Interpretation November 1998
Compression Dictionary
RESERVED 0
Specifies the log2 maximum size of the dictionary
There is no default value for dictionary size
Compression Private
Specifies a private vendor compression algorithm. The
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
To ensure basic interoperability, all implementations MUST
prepared to negotiate all of the following attributes
SA Life
SA
Auth
4.5.2 Attribute Parsing Requirement (Lifetime
To allow for flexible semantics, the IPSEC DOI requires that
conforming ISAKMP implementation MUST correctly parse an
list that contains multiple instances of the same attribute class,
long as the different attribute entries do not conflict with
another. Currently, the only attributes which requires
treatment are Life Type and Duration
To see why this is important, the following example shows the
encoding of a four entry attribute list that specifies an SA
of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for
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-
Notification Payload SHOULD be returned and the security
setup MUST be aborted
4.5.3 Attribute
If an implementation receives a defined IPSEC DOI attribute (
attribute value) which it does not support, an ATTRIBUTES-NOT-
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
range, an implementation MAY chose to continue based on local policy
4.5.4 Lifetime
When an initiator offers an SA lifetime greater than what
responder desires based on their local policy, the responder
three choices: 1) fail the negotiation entirely; 2) complete
negotiation but use a shorter lifetime than what was offered; 3)
complete the negotiation and send an advisory notification to
initiator indicating the responder's true lifetime. The choice
what the responder actually does is implementation specific and/
based on local policy
To ensure interoperability in the latter case, the IPSEC DOI
the following only when the responder wishes to notify the initiator
if the initiator offers an SA lifetime longer than the responder
willing to accept, the responder SHOULD include an
Notification Payload in the exchange that includes the responder'
IPSEC SA payload. Section 4.6.3.1 defines the payload layout for
RESPONDER-LIFETIME Notification Message type which MUST be used
this purpose
4.6 IPSEC Payload
The following sections describe those ISAKMP payloads whose
representations are dependent on the applicable DOI
4.6.1 Security Association
The following diagram illustrates the content of the
Association Payload for the IPSEC DOI. See Section 4.2 for
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
The Security Association Payload is defined as follows
o Next Payload (1 octet) - Identifier for the payload type
the next payload in the message. If the current payload is
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
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
of the Security Association Payload. See Section 4.2 for
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
to interpret the Secrecy and Integrity information
o Secrecy Length (2 octets) - Specifies the length, in octets,
the secrecy level identifier, excluding pad bits
o RESERVED (2 octets) - Unused, must be zero (0).
o Secrecy Level (variable length) - Specifies the
secrecy level required. The secrecy level MUST be padded
zero (0) to align on the next 32-bit boundary
o Secrecy Category Length (2 octets) - Specifies the length,
bits, of the secrecy category (compartment) bitmap,
pad bits
o RESERVED (2 octets) - Unused, must be zero (0).
o Secrecy Category Bitmap (variable length) - A bitmap used
designate secrecy categories (compartments) that are required
The bitmap MUST be padded with zero (0) to align on the
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
integrity level required. The integrity level MUST be
with zero (0) to align on the next 32-bit boundary
o Integrity Category Length (2 octets) - Specifies the length,
bits, of the integrity category (compartment) bitmap,
pad bits
o RESERVED (2 octets) - Unused, must be zero (0).
o Integrity Category Bitmap (variable length) - A bitmap used
designate integrity categories (compartments) that are required
The bitmap MUST be padded with zero (0) to align on the
32-bit boundary
4.6.1.1 IPSEC Labeled Domain
The following table lists the assigned values for the Labeled
Identifier field contained in the Situation field of the
Association Payload
Piper Standards Track [Page 18]
RFC 2407 IP Security Domain of Interpretation November 1998
Domain
------- -----
RESERVED 0
4.6.2 Identification Payload
The Identification Payload is used to identify the initiator of
Security Association. The identity of the initiator SHOULD be
by the responder to determine the correct host system security
requirement for the association. For example, a host might choose
require authentication and integrity without confidentiality (AH
from a certain set of IP addresses and full authentication
confidentiality (ESP) from another range of IP addresses.
Identification Payload provides information that can be used by
responder to make this decision
During Phase I negotiations, the ID port and protocol fields MUST
set to zero or to UDP port 500. If an implementation receives
other values, this MUST be treated as an error and the
association setup MUST be aborted. This event SHOULD be auditable
The following diagram illustrates the content of the
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
The Identification Payload fields are defined as follows
o Next Payload (1 octet) - Identifier for the payload type
the next payload in the message. If the current payload is
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
identification data, including the generic header
o Identification Type (1 octet) - Value describing the
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
protocol ID (e.g. UDP/TCP). A value of zero means that
Protocol ID field should be ignored
o Port (2 octets) - Value specifying an associated port. A
of zero means that the Port field should be ignored
o Identification Data (variable length) - Value, as indicated
the Identification Type
4.6.2.1 Identification Type
The following table lists the assigned values for the
Type field found in the Identification Payload
ID Type
------- -----
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
entity is computed from size in the ID payload header
When an IKE exchange is authenticated using certificates (of
format), any ID's used for input to local policy decisions SHOULD
contained in the certificate used in the authentication of
exchange
4.6.2.2 ID_IPV4_
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address
4.6.2.3 ID_
The ID_FQDN type specifies a fully-qualified domain name string.
example of a ID_FQDN is, "foo.bar.com". The string should
contain any terminators
Piper Standards Track [Page 20]
RFC 2407 IP Security Domain of Interpretation November 1998
4.6.2.4 ID_USER_
The ID_USER_FQDN type specifies a fully-qualified username string,
example of a ID_USER_FQDN is, "piper@foo.bar.com". The string
not contain any terminators
4.6.2.5 ID_IPV4_ADDR_
The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses
represented by two four (4) octet values. The first value is an IPv
address. The second is an IPv4 network mask. Note that ones (1s)
the network mask indicate that the corresponding bit in the
is fixed, while zeros (0s) indicate a "wildcard" bit
4.6.2.6 ID_IPV6_
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv
address
4.6.2.7 ID_IPV6_ADDR_
The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses
represented by two sixteen (16) octet values. The first value is
IPv6 address. The second is an IPv6 network mask. Note that
(1s) in the network mask indicate that the corresponding bit in
address is fixed, while zeros (0s) indicate a "wildcard" bit
4.6.2.8 ID_IPV4_ADDR_
The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses
represented by two four (4) octet values. The first value is
beginning IPv4 address (inclusive) and the second value is the
IPv4 address (inclusive). All addresses falling between the
specified addresses are considered to be within the list
4.6.2.9 ID_IPV6_ADDR_
The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses
represented by two sixteen (16) octet values. The first value is
beginning IPv6 address (inclusive) and the second value is the
IPv6 address (inclusive). All addresses falling between the
specified addresses are considered to be within the list
4.6.2.10 ID_DER_ASN1_
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
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_
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
being exchanged to establish the SA
4.6.2.12 ID_KEY_
The ID_KEY_ID type specifies an opaque byte stream which may be
to pass vendor-specific information necessary to identify which pre
shared key should be used to authenticate Aggressive
negotiations
4.6.3 IPSEC Notify Message
ISAKMP defines two blocks of Notify Message codes, one for errors
one for status messages. ISAKMP also allocates a portion of
block for private use within a DOI. The IPSEC DOI defines
following private message types for its own use
Notify Messages - Error Types
----------------------------- -----
RESERVED 8192
Notify Messages - Status Types
------------------------------ -----
RESPONDER-LIFETIME 24576
REPLAY-STATUS 24577
INITIAL-CONTACT 24578
Notification Status Messages MUST be sent under the protection of
ISAKMP SA: either as a payload in the last Main Mode exchange; in
separate Informational Exchange after Main Mode or Aggressive
processing is complete; or as a payload in any Quick Mode exchange
These messages MUST NOT be sent in Aggressive Mode exchange,
Aggressive Mode does not provide the necessary protection to bind
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
Mode, while the notify payload is encrypted, it is not
included in the HASH(n) digests. As a result, an active
attack on the Main Mode ciphertext could cause the notify
message type to be corrupted. (This is true, in general, for
last message of any Main Mode exchange.) While the risk is small,
corrupt notify message might cause the receiver to abort the
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
of Notification Status messages when sent in an ISAKMP
Exchange. To ensure receipt of any particular message, the
SHOULD include a Notification Payload in a defined Main Mode or
Mode exchange which is protected by a retransmission timer
4.6.3.1 RESPONDER-
The RESPONDER-LIFETIME status message may be used to communicate
IPSEC SA lifetime chosen by the responder
When present, the Notification Payload MUST have the
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
o SPI Size - set to either sixteen (16) (two eight-octet
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
IPSEC
o Notification Data - contains an ISAKMP attribute list with
responder's actual SA lifetime(s
Implementation Note: saying that the Notification Data field
an attribute list is equivalent to saying that the Notification
field has zero length and the Notification Payload has an
attribute list
4.6.3.2 REPLAY-
The REPLAY-STATUS status message may be used for
confirmation of the responder's election on whether or not he is
perform anti-replay detection
When present, the Notification Payload MUST have the
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
o SPI Size - set to either sixteen (16) (two eight-octet
cookies) or four (4) (one IPSEC SPI
o Notify Message Type - set to REPLAY-
o SPI - set to the two ISAKMP cookies or to the sender's
IPSEC
o Notification Data - a 4 octet value
Piper Standards Track [Page 23]
RFC 2407 IP Security Domain of Interpretation November 1998
0 = replay detection
1 = replay detection
4.6.3.3 INITIAL-
The INITIAL-CONTACT status message may be used when one side
to inform the other that this is the first SA being established
the remote system. The receiver of this Notification Message
then elect to delete any existing SA's it has for the sending
under the assumption that the sending system has rebooted and
longer has access to the original SA's and their associated
material. When used, the content of the Notification Data
SHOULD be null (i.e. the Payload Length should be set to the
length of Notification Payload).
When present, the Notification Payload MUST have the
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
o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies
o Notify Message Type - set to INITIAL-
o SPI - set to the two ISAKMP
o Notification Data - included
4.7 IPSEC Key Exchange
The IPSEC DOI introduces no additional Key Exchange types
5. Security
This entire memo pertains to the Internet Key Exchange
([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY])
provide for the derivation of cryptographic keying material in
secure and authenticated manner. Specific discussion of the
security protocols and transforms identified in this document can
found in the associated base documents and in the cipher references
6. IANA
This document contains many "magic" numbers to be maintained by
IANA. This section explains the criteria to be used by the IANA
assign additional numbers in each of these lists. All values
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
The Situation Definition is a 32-bit bitmask which represents
environment under which the IPSEC SA proposal and negotiation
carried out. Requests for assignments of new situations must
accompanied by an RFC which describes the interpretation for
associated bit
If the RFC is not on the standards-track (i.e., it is
informational or experimental RFC), it must be explicitly
and approved by the IESG before the RFC is published and
transform identifier is assigned
The upper two bits are reserved for private use amongst
systems
6.2 IPSEC Security Protocol
The Security Protocol Identifier is an 8-bit value which identifies
security protocol suite being negotiated. Requests for
of new security protocol identifiers must be accompanied by an
which describes the requested security protocol. [AH] and [ESP]
examples of security protocol documents
If the RFC is not on the standards-track (i.e., it is
informational or experimental RFC), it must be explicitly
and approved by the IESG before the RFC is published and
transform identifier is assigned
The values 249-255 are reserved for private use amongst
systems
6.3 IPSEC ISAKMP Transform
The IPSEC ISAKMP Transform Identifier is an 8-bit value
identifies a key exchange protocol to be used for the negotiation
Requests for assignments of new ISAKMP transform identifiers must
accompanied by an RFC which describes the requested key
protocol. [IKE] is an example of one such document
If the RFC is not on the standards-track (i.e., it is
informational or experimental RFC), it must be explicitly
and approved by the IESG before the RFC is published and
transform identifier is assigned
The values 249-255 are reserved for private use amongst
systems
Piper Standards Track [Page 25]
RFC 2407 IP Security Domain of Interpretation November 1998
6.4 IPSEC AH Transform
The IPSEC AH Transform Identifier is an 8-bit value which
a particular algorithm to be used to provide integrity protection
AH. Requests for assignments of new AH transform identifiers must
accompanied by an RFC which describes how to use the algorithm
the AH framework ([AH]).
If the RFC is not on the standards-track (i.e., it is
informational or experimental RFC), it must be explicitly
and approved by the IESG before the RFC is published and
transform identifier is assigned
The values 249-255 are reserved for private use amongst
systems
6.5 IPSEC ESP Transform
The IPSEC ESP Transform Identifier is an 8-bit value which
a particular algorithm to be used to provide secrecy protection
ESP. Requests for assignments of new ESP transform identifiers
be accompanied by an RFC which describes how to use the
within the ESP framework ([ESP]).
If the RFC is not on the standards-track (i.e., it is
informational or experimental RFC), it must be explicitly
and approved by the IESG before the RFC is published and
transform identifier is assigned
The values 249-255 are reserved for private use amongst
systems
6.6 IPSEC IPCOMP Transform
The IPSEC IPCOMP Transform Identifier is an 8-bit value
identifier a particular algorithm to be used to provide IP-
compression before ESP. Requests for assignments of new
transform identifiers must be accompanied by an RFC which
how to use the algorithm within the IPCOMP framework ([IPCOMP]).
addition, the requested algorithm must be published and in the
domain
If the RFC is not on the standards-track (i.e., it is
informational or experimental RFC), it must be explicitly
and approved by the IESG before the RFC is published and
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
approved for publication. The values 48-63 are reserved for
use amongst cooperating systems. The values 64-255 are reserved
future expansion
6.7 IPSEC Security Association
The IPSEC Security Association Attribute consists of a 16-bit
and its associated value. IPSEC SA attributes are used to
miscellaneous values between ISAKMP peers. Requests for
of new IPSEC SA attributes must be accompanied by an Internet
which describes the attribute encoding (Basic/Variable-Length)
its legal values. Section 4.5 of this document provides an
of such a description
The values 32001-32767 are reserved for private use
cooperating systems
6.8 IPSEC Labeled Domain
The IPSEC Labeled Domain Identifier is a 32-bit value
identifies a namespace in which the Secrecy and Integrity levels
categories values are said to exist. Requests for assignments of
IPSEC Labeled Domain Identifiers should be granted on demand.
accompanying documentation is required, though Internet Drafts
encouraged when appropriate
The values 0x80000000-0xffffffff are reserved for private use
cooperating systems
6.9 IPSEC Identification
The IPSEC Identification Type is an 8-bit value which is used as
discriminant for interpretation of the variable-length
Payload. Requests for assignments of new IPSEC Identification
must be accompanied by an RFC which describes how to use
identification type within IPSEC
If the RFC is not on the standards-track (i.e., it is
informational or experimental RFC), it must be explicitly
and approved by the IESG before the RFC is published and
transform identifier is assigned
The values 249-255 are reserved for private use amongst
systems
Piper Standards Track [Page 27]
RFC 2407 IP Security Domain of Interpretation November 1998
6.10 IPSEC Notify Message
The IPSEC Notify Message Type is a 16-bit value taken from the
of values reserved by ISAKMP for each DOI. There is one range
error messages (8192-16383) and a different range for status
(24576-32767). Requests for assignments of new Notify Message
must be accompanied by an Internet Draft which describes how to
the identification type within IPSEC
The values 16001-16383 and the values 32001-32767 are reserved
private use amongst cooperating systems
7. Change
7.1 Changes from V
o add explicit reference to [IPCOMP], [DEFLATE], and [LZS
o allow RESPONDER-LIFETIME and REPLAY-STATUS to be
at an IPSEC SPI in addition to the ISAKMP "SPI
o added padding exclusion to Secrecy and Integrity Length
o added forward reference to Section 4.5 in Section 4.4.4
o update document
7.2 Changes from V
o update IPCOMP identifier range to better reflect IPCOMP
o update IANA considerations per Jeff/Ted's suggested
o eliminate references to DES-MAC ID ([DESMAC])
o correct bug in Notify section; ISAKMP Notify values are 16-
7.3 Changes from V
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 