RFC 2408
Internet Security Association and Key Management Protocol (ISAKMP)
3 ISAKMP Payloads ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type Field located in the ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 through 3.15. The descriptions of the ISAKMP payloads, messages, and exchanges (see Section 4) are shown using network octet ordering. 3.1 ISAKMP Header Format An ISAKMP message has a fixed header format, shown in Figure 2, followed by a variable number of payloads. A fixed header simplifies parsing, providing the benefit of protocol parsing software that is less complex and easier to implement. The fixed header contains the information required by the protocol to maintain state, process payloads and possibly prevent denial of service or replay attacks. The ISAKMP Header fields are defined as follows: o Initiator Cookie (8 octets) - Cookie of entity that initiated SA establishment, SA notification, or SA deletion. o Responder Cookie (8 octets) - Cookie of entity that is responding to an SA establishment request, SA notification, or SA deletion.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Responder !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ISAKMP Header Format
o Next Payload (1 octet) - Indicates the type of the first payload
in the message. The format for each payload is defined in
sections 3.4 through 3.16. The processing for the payloads is
defined in section 5.
Next Payload Type Value
NONE 0
Security Association (SA) 1
Proposal (P) 2
Transform (T) 3
Key Exchange (KE) 4
Identification (ID) 5
Certificate (CERT) 6
Certificate Request (CR) 7
Hash (HASH) 8
Signature (SIG) 9
Nonce (NONCE) 10
Notification (N) 11
Delete (D) 12
Vendor ID (VID) 13
RESERVED 14 - 127
Private USE 128 - 255
o Major Version (4 bits) - indicates the major version of the ISAKMP
protocol in use. Implementations based on this version of the
ISAKMP Internet-Draft MUST set the Major Version to 1.
Implementations based on previous versions of ISAKMP Internet-
Drafts MUST set the Major Version to 0. Implementations SHOULD
never accept packets with a major version number larger than its
own.
o Minor Version (4 bits) - indicates the minor version of the
ISAKMP protocol in use. Implementations based on this version of
the ISAKMP Internet-Draft MUST set the Minor Version to 0.
Implementations based on previous versions of ISAKMP Internet-
Drafts MUST set the Minor Version to 1. Implementations SHOULD
never accept packets with a minor version number larger than its
own, given the major version numbers are identical.
o Exchange Type (1 octet) - indicates the type of exchange being
used. This dictates the message and payload orderings in the
ISAKMP exchanges.
Exchange Type Value
NONE 0
Base 1
Identity Protection 2
Authentication Only 3
Aggressive 4
Informational 5
ISAKMP Future Use 6 - 31
DOI Specific Use 32 - 239
Private Use 240 - 255
o Flags (1 octet) - indicates specific options that are set for the
ISAKMP exchange. The flags listed below are specified in the
Flags field beginning with the least significant bit, i.e the
Encryption bit is bit 0 of the Flags field, the Commit bit is bit
1 of the Flags field, and the Authentication Only bit is bit 2 of
the Flags field. The remaining bits of the Flags field MUST be
set to 0 prior to transmission.
-- E(ncryption Bit) (1 bit) - If set (1), all payloads following
the header are encrypted using the encryption algorithm
identified in the ISAKMP SA. The ISAKMP SA Identifier is the
combination of the initiator and responder cookie. It is
RECOMMENDED that encryption of communications be done as soon
as possible between the peers. For all ISAKMP exchanges
described in section 4.1, the encryption SHOULD begin after
both parties have exchanged Key Exchange payloads. If the
E(ncryption Bit) is not set (0), the payloads are not
encrypted.
-- C(ommit Bit) (1 bit) - This bit is used to signal key exchange
synchronization. It is used to ensure that encrypted material
is not received prior to completion of the SA establishment.
The Commit Bit can be set (at anytime) by either party
participating in the SA establishment, and can be used during
both phases of an ISAKMP SA establishment. However, the value
MUST be reset after the Phase 1 negotiation. If set(1), the
entity which did not set the Commit Bit MUST wait for an
Informational Exchange containing a Notify payload (with the
CONNECTED Notify Message) from the entity which set the Commit
Bit. In this instance, the Message ID field of the
Informational Exchange MUST contain the Message ID of the
original ISAKMP Phase 2 SA negotiation. This is done to
ensure that the Informational Exchange with the CONNECTED
Notify Message can be associated with the correct Phase 2 SA.
The receipt and processing of the Informational Exchange
indicates that the SA establishment was successful and either
entity can now proceed with encrypted traffic communication.
In addition to synchronizing key exchange, the Commit Bit can
be used to protect against loss of transmissions over
unreliable networks and guard against the need for multiple
re-transmissions.
NOTE: It is always possible that the final message of an
exchange can be lost. In this case, the entity expecting to
receive the final message of an exchange would receive the
Phase 2 SA negotiation message following a Phase 1 exchange or
encrypted traffic following a Phase 2 exchange. Handling of
this situation is not standardized, but we propose the
following possibilities. If the entity awaiting the
Informational Exchange can verify the received message (i.e.
Phase 2 SA negotiation message or encrypted traffic), then
they MAY consider the SA was established and continue
processing. The other option is to retransmit the last ISAKMP
message to force the other entity to retransmit the final
message. This suggests that implementations may consider
retaining the last message (locally) until they are sure the
SA is established.
-- A(uthentication Only Bit) (1 bit) - This bit is intended for
use with the Informational Exchange with a Notify payload and
will allow the transmission of information with integrity
checking, but no encryption (e.g. "emergency mode"). Section
4.8 states that a Phase 2 Informational Exchange MUST be sent
under the protection of an ISAKMP SA. This is the only
exception to that policy. If the Authentication Only bit is
set (1), only authentication security services will be applied
to the entire Notify payload of the Informational Exchange and
the payload will not be encrypted.
o Message ID (4 octets) - Unique Message Identifier used to
identify protocol state during Phase 2 negotiations. This value
is randomly generated by the initiator of the Phase 2
negotiation. In the event of simultaneous SA establishments
(i.e. collisions), the value of this field will likely be
different because they are independently generated and, thus, two
security associations will progress toward establishment.
However, it is unlikely there will be absolute simultaneous
establishments. During Phase 1 negotiations, the value MUST be
set to 0.
o Length (4 octets) - Length of total message (header + payloads)
in octets. Encryption can expand the size of an ISAKMP message.
3.2 Generic Payload Header
Each ISAKMP payload defined in sections 3.4 through 3.16 begins with
a generic header, shown in Figure 3, which provides a payload
"chaining" capability and clearly defines the boundaries of a
payload.
1 2 3
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Generic Payload Header
The Generic Payload Header 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, then this field will be 0. This field provides
the "chaining" capability.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
3.3 Data Attributes
There are several instances within ISAKMP where it is necessary to
represent Data Attributes. An example of this is the Security
Association (SA) Attributes contained in the Transform payload
(described in section 3.6). These Data Attributes are not an ISAKMP payload, but are contained within ISAKMP payloads. The format of the Data Attributes provides the flexibility for representation of many different types of information. There can be multiple Data Attributes within a payload. The length of the Data Attributes will either be 4 octets or defined by the Attribute Length field. This is done using the Attribute Format bit described below. Specific information about the attributes for each domain will be described in a DOI document, e.g. IPSEC DOI [IPDOI]. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ !A! Attribute Type ! AF=0 Attribute Length ! !F! ! AF=1 Attribute Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . AF=0 Attribute Value . . AF=1 Not Transmitted . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Data Attributes The Data Attributes fields are defined as follows: o Attribute Type (2 octets) - Unique identifier for each type of attribute. These attributes are defined as part of the DOI- specific information. The most significant bit, or Attribute Format (AF), indicates whether the data attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is a zero (0), then the Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit is a one (1), then the Data Attributes are of the Type/Value form. o Attribute Length (2 octets) - Length in octets of the Attribute Value. When the AF bit is a one (1), the Attribute Value is only 2 octets and the Attribute Length field is not present. o Attribute Value (variable length) - Value of the attribute associated with the DOI-specific Attribute Type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets.
3.4 Security Association Payload The Security Association Payload is used to negotiate security attributes and to indicate the Domain of Interpretation (DOI) and Situation under which the negotiation is taking place. Figure 5 shows the format of the Security Association payload. 1 2 3 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 (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Situation ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Security Association Payload 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, then this field will be 0. This field MUST NOT contain the values for the Proposal or Transform payloads as they are considered part of the security association negotiation. For example, this field would contain the value "10" (Nonce payload) in the first message of a Base Exchange (see Section 4.4) and the value "0" in the first message of an Identity Protect Exchange (see Section 4.5). o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the entire Security Association payload, including the SA payload, all Proposal payloads, and all Transform payloads associated with the proposed Security Association. o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this negotiation is taking place. The DOI is a 32-bit unsigned integer. A DOI value of 0 during a Phase 1 exchange specifies a Generic ISAKMP SA which can be used for any protocol during the Phase 2 exchange. The necessary SA Attributes are defined in A.4. A DOI value of 1 is assigned to the IPsec DOI [IPDOI]. All other DOI values are reserved to IANA for future use. IANA will not normally assign a DOI value without referencing some public specification, such as
an Internet RFC. Other DOI's can be defined using the description
in appendix B. This field MUST be present within the Security
Association payload.
o Situation (variable length) - A DOI-specific field that
identifies the situation under which this negotiation is taking
place. The Situation is used to make policy decisions regarding
the security attributes being negotiated. Specifics for the IETF
IP Security DOI Situation are detailed in [IPDOI]. This field
MUST be present within the Security Association payload.
3.5 Proposal Payload
The Proposal Payload contains information used during Security
Association negotiation. The proposal consists of security
mechanisms, or transforms, to be used to secure the communications
channel. Figure 6 shows the format of the Proposal Payload. A
description of its use can be found in section 4.2.
1 2 3
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal # ! Protocol-Id ! SPI Size !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI (variable) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Proposal Payload Format
The Proposal Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. This field MUST only contain the
value "2" or "0". If there are additional Proposal payloads in
the message, then this field will be 2. If the current Proposal
payload is the last within the security association proposal,
then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the entire
Proposal payload, including generic payload header, the Proposal
payload, and all Transform payloads associated with this
proposal. In the event there are multiple proposals with the
same proposal number (see section 4.2), the Payload Length field
only applies to the current Proposal payload and not to all
Proposal payloads.
o Proposal # (1 octet) - Identifies the Proposal number for the
current payload. A description of the use of this field is found
in section 4.2.
o Protocol-Id (1 octet) - Specifies the protocol identifier for the
current negotiation. Examples might include IPSEC ESP, IPSEC AH,
OSPF, TLS, etc.
o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. In the case of ISAKMP, the Initiator and
Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
therefore, the SPI Size is irrelevant and MAY be from zero (0) to
sixteen (16). If the SPI Size is non-zero, the content of the
SPI field MUST be ignored. If the SPI Size is not a multiple of
4 octets it will have some impact on the SPI field and the
alignment of all payloads in the message. The Domain of
Interpretation (DOI) will dictate the SPI Size for other
protocols.
o # of Transforms (1 octet) - Specifies the number of transforms
for the Proposal. Each of these is contained in a Transform
payload.
o SPI (variable) - The sending entity's SPI. In the event the SPI
Size is not a multiple of 4 octets, there is no padding applied
to the payload, however, it can be applied at the end of the
message.
The payload type for the Proposal Payload is two (2).
3.6 Transform Payload
The Transform Payload contains information used during Security
Association negotiation. The Transform payload consists of a
specific security mechanism, or transforms, to be used to secure the
communications channel. The Transform payload also contains the
security association attributes associated with the specific
transform. These SA attributes are DOI-specific. Figure 7 shows the
format of the Transform Payload. A description of its use can be
found in section 4.2.
1 2 3
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform # ! Transform-Id ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ SA Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Transform Payload Format
The Transform Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. This field MUST only contain the
value "3" or "0". If there are additional Transform payloads in
the proposal, then this field will be 3. If the current
Transform payload is the last within the proposal, then this
field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header, Transform values,
and all SA Attributes.
o Transform # (1 octet) - Identifies the Transform number for the
current payload. If there is more than one transform proposed
for a specific protocol within the Proposal payload, then each
Transform payload has a unique Transform number. A description
of the use of this field is found in section 4.2.
o Transform-Id (1 octet) - Specifies the Transform identifier for
the protocol within the current proposal. These transforms are
defined by the DOI and are dependent on the protocol being
negotiated.
o RESERVED2 (2 octets) - Unused, set to 0.
o SA Attributes (variable length) - This field contains the
security association attributes as defined for the transform
given in the Transform-Id field. The SA Attributes SHOULD be
represented using the Data Attributes format described in section
3.3. If the SA Attributes are not aligned on 4-byte boundaries,
then subsequent payloads will not be aligned and any padding will
be added at the end of the message to make the message 4-octet
aligned.
The payload type for the Transform Payload is three (3).
3.7 Key Exchange Payload
The Key Exchange Payload supports a variety of key exchange
techniques. Example key exchanges are Oakley [Oakley], Diffie-
Hellman, the enhanced Diffie-Hellman key exchange described in X9.42
[ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows
the format of the Key Exchange payload.
The Key Exchange Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
nextpayload in the message. If the current payload is the last
in the message, then this field will be 0.
1 2 3
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Exchange Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Key Exchange Payload Format
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Key Exchange Data (variable length) - Data required to generate a
session key. The interpretation of this data is specified by the
DOI and the associated Key Exchange algorithm. This field may
also contain pre-placed key indicators.
The payload type for the Key Exchange Payload is four (4).
3.8 Identification Payload The Identification Payload contains DOI-specific data used to exchange identification information. This information is used for determining the identities of communicating peers and may be used for determining authenticity of information. Figure 9 shows the format of the Identification Payload. 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, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o ID Type (1 octet) - Specifies the type of Identification being used. 1 2 3 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 ! DOI Specific ID Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Identification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Identification Payload Format This field is DOI-dependent. o DOI Specific ID Data (3 octets) - Contains DOI specific Identification data. If unused, then this field MUST be set to 0. o Identification Data (variable length) - Contains identity information. The values for this field are DOI-specific and the format is specified by the ID Type field. Specific details for the IETF IP Security DOI Identification Data are detailed in [IPDOI].
The payload type for the Identification Payload is five (5). 3.9 Certificate Payload The Certificate Payload provides a means to transport certificates or other certificate-related information via ISAKMP and can appear in any ISAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate payload MUST be accepted at any point during an exchange. Figure 10 shows the format of the Certificate Payload. NOTE: Certificate types and formats are not generally bound to a DOI - it is expected that there will only be a few certificate types, and that most DOIs will accept all of these types. The Certificate 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, then this field will be 0. 1 2 3 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cert Encoding ! ! +-+-+-+-+-+-+-+-+ ! ~ Certificate Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Certificate Payload Format o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field.
Certificate Type Value
NONE 0
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
X.509 Certificate - Signature 4
X.509 Certificate - Key Exchange 5
Kerberos Tokens 6
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8
SPKI Certificate 9
X.509 Certificate - Attribute 10
RESERVED 11 - 255
o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated by the
Certificate Encoding field.
The payload type for the Certificate Payload is six (6).
3.10 Certificate Request Payload
The Certificate Request Payload provides a means to request
certificates via ISAKMP and can appear in any message. Certificate
Request payloads SHOULD be included in an exchange whenever an
appropriate directory service (e.g. Secure DNS [DNSSEC]) is not
available to distribute certificates. The Certificate Request
payload MUST be accepted at any point during the exchange. The
responder to the Certificate Request payload MUST send its
certificate, if certificates are supported, based on the values
contained in the payload. If multiple certificates are required,
then multiple Certificate Request payloads SHOULD be transmitted.
Figure 11 shows the format of the Certificate Request Payload.
1 2 3
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert. Type ! !
+-+-+-+-+-+-+-+-+ !
~ Certificate Authority ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Certificate Request Payload Format
The Certificate 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, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Certificate Type (1 octet) - Contains an encoding of the type of
certificate requested. Acceptable values are listed in section
3.9.
o Certificate Authority (variable length) - Contains an encoding of
an acceptable certificate authority for the type of certificate
requested. As an example, for an X.509 certificate this field
would contain the Distinguished Name encoding of the Issuer Name
of an X.509 certificate authority acceptable to the sender of
this payload. This would be included to assist the responder in
determining how much of the certificate chain would need to be
sent in response to this request. If there is no specific
certificate authority requested, this field SHOULD not be
included.
The payload type for the Certificate Request Payload is seven (7).
3.11 Hash Payload The Hash Payload contains data generated by the hash function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload may be used to verify the integrity of the data in an ISAKMP message or for authentication of the negotiating entities. Figure 12 shows the format of the Hash Payload. 1 2 3 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Hash Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Hash Payload Format The Hash 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, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Hash Data (variable length) - Data that results from applying the hash routine to the ISAKMP message and/or state.
3.12 Signature Payload The Signature Payload contains data generated by the digital signature function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload is used to verify the integrity of the data in the ISAKMP message, and may be of use for non-repudiation services. Figure 13 shows the format of the Signature Payload. 1 2 3 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Signature Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Signature Payload Format The Signature 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, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. o Signature Data (variable length) - Data that results from applying the digital signature function to the ISAKMP message and/or state. The payload type for the Signature Payload is nine (9). 3.13 Nonce Payload The Nonce Payload contains random data used to guarantee liveness during an exchange and protect against replay attacks. Figure 14 shows the format of the Nonce Payload. If nonces are used by a particular key exchange, the use of the Nonce payload will be dictated by the key exchange. The nonces may be transmitted as part of the key exchange data, or as a separate payload. However, this is defined by the key exchange, not by ISAKMP.
1 2 3
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Nonce Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Nonce Payload Format
The Nonce 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, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity.
The payload type for the Nonce Payload is ten (10).
3.14 Notification Payload
The Notification Payload can contain both ISAKMP and DOI-specific
data and is used to transmit informational data, such as error
conditions, to an ISAKMP peer. It is possible to send multiple
Notification payloads in a single ISAKMP message. Figure 15 shows
the format of the Notification Payload.
Notification which occurs during, or is concerned with, a Phase 1
negotiation is identified by the Initiator and Responder cookie pair
in the ISAKMP Header. The Protocol Identifier, in this case, is
ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
Header identifies the ISAKMP SA. If the notification takes place
prior to the completed exchange of keying information, then the
notification will be unprotected.
Notification which occurs during, or is concerned with, a Phase 2
negotiation is identified by the Initiator and Responder cookie pair
in the ISAKMP Header and the Message ID and SPI associated with the
current negotiation. One example for this type of notification is to
indicate why a proposal was rejected.
1 2 3
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 (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Notification Payload Format
The Notification 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, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Domain of Interpretation (4 octets) - Identifies the DOI (as
described in Section 2.1) under which this notification is taking
place. For ISAKMP this value is zero (0) and for the IPSEC DOI
it is one (1). Other DOI's can be defined using the description
in appendix B.
o Protocol-Id (1 octet) - Specifies the protocol identifier for the
current notification. Examples might include ISAKMP, IPSEC ESP,
IPSEC AH, OSPF, TLS, etc.
o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. In the case of ISAKMP, the Initiator and
Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
therefore, the SPI Size is irrelevant and MAY be from zero (0) to
sixteen (16). If the SPI Size is non-zero, the content of the
SPI field MUST be ignored. The Domain of Interpretation (DOI)
will dictate the SPI Size for other protocols.
o Notify Message Type (2 octets) - Specifies the type of
notification message (see section 3.14.1). Additional text, if
specified by the DOI, is placed in the Notification Data field.
o SPI (variable length) - Security Parameter Index. The receiving
entity's SPI. The use of the SPI field is described in section
2.4. The length of this field is determined by the SPI Size
field and is not necessarily aligned to a 4 octet boundary.
o Notification Data (variable length) - Informational or error data
transmitted in addition to the Notify Message Type. Values for
this field are DOI-specific.
The payload type for the Notification Payload is eleven (11).
3.14.1 Notify Message Types
Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process.
For example, a secure front end or security gateway may use the
Notify message to synchronize SA communication. The table below
lists the Nofitication messages and their corresponding values.
Values in the Private Use range are expected to be DOI-specific
values.
NOTIFY MESSAGES - ERROR TYPES
Errors Value
INVALID-PAYLOAD-TYPE 1
DOI-NOT-SUPPORTED 2
SITUATION-NOT-SUPPORTED 3
INVALID-COOKIE 4
INVALID-MAJOR-VERSION 5
INVALID-MINOR-VERSION 6
INVALID-EXCHANGE-TYPE 7
INVALID-FLAGS 8
INVALID-MESSAGE-ID 9
INVALID-PROTOCOL-ID 10
INVALID-SPI 11
INVALID-TRANSFORM-ID 12
ATTRIBUTES-NOT-SUPPORTED 13
NO-PROPOSAL-CHOSEN 14
BAD-PROPOSAL-SYNTAX 15
PAYLOAD-MALFORMED 16
INVALID-KEY-INFORMATION 17
INVALID-ID-INFORMATION 18
INVALID-CERT-ENCODING 19
INVALID-CERTIFICATE 20
CERT-TYPE-UNSUPPORTED 21
INVALID-CERT-AUTHORITY 22
INVALID-HASH-INFORMATION 23
AUTHENTICATION-FAILED 24
INVALID-SIGNATURE 25
ADDRESS-NOTIFICATION 26
NOTIFY-SA-LIFETIME 27
CERTIFICATE-UNAVAILABLE 28
UNSUPPORTED-EXCHANGE-TYPE 29
UNEQUAL-PAYLOAD-LENGTHS 30
RESERVED (Future Use) 31 - 8191
Private Use 8192 - 16383
NOTIFY MESSAGES - STATUS TYPES
Status Value
CONNECTED 16384
RESERVED (Future Use) 16385 - 24575
DOI-specific codes 24576 - 32767
Private Use 32768 - 40959
RESERVED (Future Use) 40960 - 65535
3.15 Delete Payload
The Delete Payload contains a protocol-specific security association
identifier that the sender has removed from its security association
database and is, therefore, no longer valid. Figure 16 shows the
format of the Delete Payload. It is possible to send multiple SPIs
in a Delete payload, however, each SPI MUST be for the same protocol.
Mixing of Protocol Identifiers MUST NOT be performed with the Delete
payload.
Deletion which is concerned with an ISAKMP SA will contain a
Protocol-Id of ISAKMP and the SPIs are the initiator and responder
cookies from the ISAKMP Header. Deletion which is concerned with a
Protocol SA, such as ESP or AH, will contain the Protocol-Id of that
protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s).
NOTE: The Delete Payload is not a request for the responder to delete
an SA, but an advisory from the initiator to the responder. If the
responder chooses to ignore the message, the next communication from
the responder to the initiator, using that security association, will
fail. A responder is not expected to acknowledge receipt of a Delete
payload.
1 2 3
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 (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-Id ! SPI Size ! # of SPIs !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index(es) (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Delete Payload Format
The Delete 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, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Domain of Interpretation (4 octets) - Identifies the DOI (as
described in Section 2.1) under which this deletion is taking
place. For ISAKMP this value is zero (0) and for the IPSEC DOI
it is one (1). Other DOI's can be defined using the description
in appendix B.
o Protocol-Id (1 octet) - ISAKMP can establish security
associations for various protocols, including ISAKMP and IPSEC.
This field identifies which security association database to
apply the delete request.
o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. In the case of ISAKMP, the Initiator and
Responder cookie pair is the ISAKMP SPI. In this case, the SPI
Size would be 16 octets for each SPI being deleted.
o # of SPIs (2 octets) - The number of SPIs contained in the Delete
payload. The size of each SPI is defined by the SPI Size field.
o Security Parameter Index(es) (variable length) - Identifies the
specific security association(s) to delete. Values for this
field are DOI and protocol specific. The length of this field is
determined by the SPI Size and # of SPIs fields.
The payload type for the Delete Payload is twelve (12).
3.16 Vendor ID Payload
The Vendor ID Payload contains a vendor defined constant. The
constant is used by vendors to identify and recognize remote
instances of their implementations. This mechanism allows a vendor
to experiment with new features while maintaining backwards
compatibility. This is not a general extension facility of ISAKMP.
Figure 17 shows the format of the Vendor ID Payload.
The Vendor ID payload is not an announcement from the sender that it
will send private payload types. A vendor sending the Vendor ID MUST
not make any assumptions about private payloads that it may send
unless a Vendor ID is received as well. Multiple Vendor ID payloads
MAY be sent. An implementation is NOT REQUIRED to understand any
Vendor ID payloads. An implementation is NOT REQUIRED to send any
Vendor ID payload at all. If a private payload was sent without
prior agreement to send it, a compliant implementation may reject a
proposal with a notify message of type INVALID-PAYLOAD-TYPE.
If a Vendor ID payload is sent, it MUST be sent during the Phase 1
negotiation. Reception of a familiar Vendor ID payload in the Phase
1 negotiation allows an implementation to make use of Private USE
payload numbers (128-255), described in section 3.1 for vendor
specific extensions during Phase 2 negotiations. The definition of
"familiar" is left to implementations to determine. Some vendors may
wish to implement another vendor's extension prior to
standardization. However, this practice SHOULD not be widespread and
vendors should work towards standardization instead.
The vendor defined constant MUST be unique. The choice of hash and
text to hash is left to the vendor to decide. As an example, vendors
could generate their vendor id by taking a plain (non-keyed) hash of
a string containing the product name, and the version of the product.
A hash is used instead of a vendor registry to avoid local
cryptographic policy problems with having a list of "approved"
products, to keep away from maintaining a list of vendors, and to
allow classified products to avoid having to appear on any list. For
instance:
"Example Company IPsec. Version 97.1"
(not including the quotes) has MD5 hash:
48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may
include all of the hash, or just a portion of it, as the payload
length will bound the data. There are no security implications of
this hash, so its choice is arbitrary.
1 2 3
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Vendor ID (VID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Vendor ID Payload Format
The Vendor ID 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, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Vendor ID (variable length) - Hash of the vendor string plus
version (as described above).
The payload type for the Vendor ID Payload is thirteen (13).
(page 44 continued on part 3)
