RFC 4306
Internet Key Exchange (IKEv2) Protocol
Pages: 99
Obsoletes: 2407 2408 2409
Obsoleted by: 5996
Updated by: 5282
Obsoletes: 2407 2408 2409
Obsoleted by: 5996
Updated by: 5282
Part 3 of 5 – Pages 41 to 64
3. Header and Payload Formats
3.1. The IKE Header
IKE messages use UDP ports 500 and/or 4500, with one IKE message per UDP datagram. Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. When sent on UDP port 500, IKE messages begin immediately following the UDP header. When sent on UDP port 4500, IKE messages have prepended four octets of zero. These four octets of zero are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE. Each IKE message begins with the IKE header, denoted HDR in this memo. Following the header are one or more IKE payloads each identified by a "Next Payload" field in the preceding payload. Payloads are processed in the order in which they appear in an IKE message by invoking the appropriate processing routine according to the "Next Payload" field in the IKE header and subsequently according to the "Next Payload" field in the IKE payload itself until a "Next Payload" field of zero indicates that no payloads follow. If a payload of type "Encrypted" is found, that payload is decrypted and its contents parsed as additional payloads. An Encrypted payload MUST be the last payload in a packet and an Encrypted payload MUST NOT contain another Encrypted payload. The Recipient SPI in the header identifies an instance of an IKE security association. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers. All multi-octet fields representing integers are laid out in big endian order (aka most significant byte first, or network byte order). The format of the IKE header is shown in Figure 4.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IKE_SA Initiator's SPI ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IKE_SA Responder's SPI ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IKE Header Format o Initiator's SPI (8 octets) - A value chosen by the initiator to identify a unique IKE security association. This value MUST NOT be zero. o Responder's SPI (8 octets) - A value chosen by the responder to identify a unique IKE security association. This value MUST be zero in the first message of an IKE Initial Exchange (including repeats of that message including a cookie) and MUST NOT be zero in any other message. o Next Payload (1 octet) - Indicates the type of payload that immediately follows the header. The format and value of each payload are defined below. o Major Version (4 bits) - Indicates the major version of the IKE protocol in use. Implementations based on this version of IKE MUST set the Major Version to 2. Implementations based on previous versions of IKE and ISAKMP MUST set the Major Version to 1. Implementations based on this version of IKE MUST reject or ignore messages containing a version number greater than 2. o Minor Version (4 bits) - Indicates the minor version of the IKE protocol in use. Implementations based on this version of IKE MUST set the Minor Version to 0. They MUST ignore the minor version number of received messages. o Exchange Type (1 octet) - Indicates the type of exchange being used. This constrains the payloads sent in each message and orderings of messages in an exchange.
Exchange Type Value
RESERVED 0-33
IKE_SA_INIT 34
IKE_AUTH 35
CREATE_CHILD_SA 36
INFORMATIONAL 37
RESERVED TO IANA 38-239
Reserved for private use 240-255
o Flags (1 octet) - Indicates specific options that are set
for the message. Presence of options are indicated by the
appropriate bit in the flags field being set. The bits are
defined LSB first, so bit 0 would be the least significant
bit of the Flags octet. In the description below, a bit
being 'set' means its value is '1', while 'cleared' means
its value is '0'.
-- X(reserved) (bits 0-2) - These bits MUST be cleared
when sending and MUST be ignored on receipt.
-- I(nitiator) (bit 3 of Flags) - This bit MUST be set in
messages sent by the original initiator of the IKE_SA
and MUST be cleared in messages sent by the original
responder. It is used by the recipient to determine
which eight octets of the SPI were generated by the
recipient.
-- V(ersion) (bit 4 of Flags) - This bit indicates that
the transmitter is capable of speaking a higher major
version number of the protocol than the one indicated
in the major version number field. Implementations of
IKEv2 must clear this bit when sending and MUST ignore
it in incoming messages.
-- R(esponse) (bit 5 of Flags) - This bit indicates that
this message is a response to a message containing
the same message ID. This bit MUST be cleared in all
request messages and MUST be set in all responses.
An IKE endpoint MUST NOT generate a response to a
message that is marked as being a response.
-- X(reserved) (bits 6-7 of Flags) - These bits MUST be
cleared when sending and MUST be ignored on receipt.
o Message ID (4 octets) - Message identifier used to control
retransmission of lost packets and matching of requests and
responses. It is essential to the security of the protocol
because it is used to prevent message replay attacks.
See sections 2.1 and 2.2.
o Length (4 octets) - Length of total message (header + payloads)
in octets.
3.2. Generic Payload Header
Each IKE payload defined in sections 3.3 through 3.16 begins with a
generic payload header, shown in Figure 5. Figures for each payload
below will include the generic payload header, but for brevity the
description of each field will be omitted.
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: 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 a
"chaining" capability whereby additional payloads can be added to
a message by appending it to the end of the message and setting
the "Next Payload" field of the preceding payload to indicate the
new payload's type. An Encrypted payload, which must always be
the last payload of a message, is an exception. It contains data
structures in the format of additional payloads. In the header of
an Encrypted payload, the Next Payload field is set to the payload
type of the first contained payload (instead of 0).
Payload Type Values
Next Payload Type Notation Value
No Next Payload 0
RESERVED 1-32
Security Association SA 33
Key Exchange KE 34
Identification - Initiator IDi 35
Identification - Responder IDr 36
Certificate CERT 37
Certificate Request CERTREQ 38
Authentication AUTH 39
Nonce Ni, Nr 40
Notify N 41
Delete D 42
Vendor ID V 43
Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45
Encrypted E 46
Configuration CP 47
Extensible Authentication EAP 48
RESERVED TO IANA 49-127
PRIVATE USE 128-255
Payload type values 1-32 should not be used so that there is no
overlap with the code assignments for IKEv1. Payload type values
49-127 are reserved to IANA for future assignment in IKEv2 (see
section 6). Payload type values 128-255 are for private use among
mutually consenting parties.
o Critical (1 bit) - MUST be set to zero if the sender wants the
recipient to skip this payload if it does not understand the
payload type code in the Next Payload field of the previous
payload. MUST be set to one if the sender wants the recipient to
reject this entire message if it does not understand the payload
type. MUST be ignored by the recipient if the recipient
understands the payload type code. MUST be set to zero for
payload types defined in this document. Note that the critical
bit applies to the current payload rather than the "next" payload
whose type code appears in the first octet. The reasoning behind
not setting the critical bit for payloads defined in this document
is that all implementations MUST understand all payload types
defined in this document and therefore must ignore the Critical
bit's value. Skipped payloads are expected to have valid Next
Payload and Payload Length fields.
o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
receipt.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
3.3. Security Association Payload
The Security Association Payload, denoted SA in this memo, is used to negotiate attributes of a security association. Assembly of Security Association Payloads requires great peace of mind. An SA payload MAY contain multiple proposals. If there is more than one, they MUST be ordered from most preferred to least preferred. Each proposal may contain multiple IPsec protocols (where a protocol is IKE, ESP, or AH), each protocol MAY contain multiple transforms, and each transform MAY contain multiple attributes. When parsing an SA, an implementation MUST check that the total Payload Length is consistent with the payload's internal lengths and counts. Proposals, Transforms, and Attributes each have their own variable length encodings. They are nested such that the Payload Length of an SA includes the combined contents of the SA, Proposal, Transform, and Attribute information. The length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains. The syntax of Security Associations, Proposals, Transforms, and Attributes is based on ISAKMP; however, the semantics are somewhat different. The reason for the complexity and the hierarchy is to allow for multiple possible combinations of algorithms to be encoded in a single SA. Sometimes there is a choice of multiple algorithms, whereas other times there is a combination of algorithms. For example, an initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR (ESP w/MD5 and 3DES). One of the reasons the semantics of the SA payload has changed from ISAKMP and IKEv1 is to make the encodings more compact in common cases. The Proposal structure contains within it a Proposal # and an IPsec protocol ID. Each structure MUST have the same Proposal # as the previous one or be one (1) greater. The first Proposal MUST have a Proposal # of one (1). If two successive structures have the same Proposal number, it means that the proposal consists of the first structure AND the second. So a proposal of AH AND ESP would have two proposal structures, one for AH and one for ESP and both would have Proposal #1. A proposal of AH OR ESP would have two proposal structures, one for AH with Proposal #1 and one for ESP with Proposal #2. Each Proposal/Protocol structure is followed by one or more transform structures. The number of different transforms is generally determined by the Protocol. AH generally has a single transform: an integrity check algorithm. ESP generally has two: an encryption algorithm and an integrity check algorithm. IKE generally has four
transforms: a Diffie-Hellman group, an integrity check algorithm, a prf algorithm, and an encryption algorithm. If an algorithm that combines encryption and integrity protection is proposed, it MUST be proposed as an encryption algorithm and an integrity protection algorithm MUST NOT be proposed. For each Protocol, the set of permissible transforms is assigned transform ID numbers, which appear in the header of each transform. If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple Transforms with different Transform Types, the proposal is an AND of the different groups. For example, to propose ESP with (3DES or IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for IDEA) and two Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). This effectively proposes four combinations of algorithms. If the initiator wanted to propose only a subset of those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as multiple transforms within a single Proposal. Instead, the initiator would have to construct two different Proposals, each with two transforms. A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size. The transform would specify the algorithm and the attribute would specify the key size. Most transforms do not have attributes. A transform MUST NOT have multiple attributes of the same type. To propose alternate values for an attribute (for example, multiple key sizes for the AES encryption algorithm), and implementation MUST include multiple Transforms with the same Transform Type each with a single Attribute. Note that the semantics of Transforms and Attributes are quite different from those in IKEv1. In IKEv1, a single Transform carried multiple algorithms for a protocol with one carried in the Transform and the others carried in the Attributes. 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 !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ <Proposals> ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Security Association Payload
o Proposals (variable) - One or more proposal substructures.
The payload type for the Security Association Payload is thirty
three (33).
3.3.1. Proposal Substructure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 (last) or 2 ! RESERVED ! Proposal Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal # ! Protocol ID ! SPI Size !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ <Transforms> ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Proposal Substructure
o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the
last Proposal Substructure in the SA. This syntax is inherited
from ISAKMP, but is unnecessary because the last Proposal could
be identified from the length of the SA. The value (2)
corresponds to a Payload Type of Proposal in IKEv1, and the
first 4 octets of the Proposal structure are designed to look
somewhat like the header of a Payload.
o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
receipt.
o Proposal Length (2 octets) - Length of this proposal, including
all transforms and attributes that follow.
o Proposal # (1 octet) - When a proposal is made, the first
proposal in an SA payload MUST be #1, and subsequent proposals
MUST either be the same as the previous proposal (indicating an
AND of the two proposals) or one more than the previous
proposal (indicating an OR of the two proposals). When a
proposal is accepted, all of the proposal numbers in the SA
payload MUST be the same and MUST match the number on the
proposal sent that was accepted.
o Protocol ID (1 octet) - Specifies the IPsec protocol identifier
for the current negotiation. The defined values are:
Protocol Protocol ID
RESERVED 0
IKE 1
AH 2
ESP 3
RESERVED TO IANA 4-200
PRIVATE USE 201-255
o SPI Size (1 octet) - For an initial IKE_SA negotiation, this
field MUST be zero; the SPI is obtained from the outer header.
During subsequent negotiations, it is equal to the size, in
octets, of the SPI of the corresponding protocol (8 for IKE, 4
for ESP and AH).
o # of Transforms (1 octet) - Specifies the number of transforms
in this proposal.
o SPI (variable) - The sending entity's SPI. Even if the SPI Size
is not a multiple of 4 octets, there is no padding applied to
the payload. When the SPI Size field is zero, this field is
not present in the Security Association payload.
o Transforms (variable) - One or more transform substructures.
3.3.2. Transform Substructure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 (last) or 3 ! RESERVED ! Transform Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!Transform Type ! RESERVED ! Transform ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Transform Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Transform Substructure
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
last Transform Substructure in the Proposal. This syntax is
inherited from ISAKMP, but is unnecessary because the last
Proposal could be identified from the length of the SA. The
value (3) corresponds to a Payload Type of Transform in IKEv1,
and the first 4 octets of the Transform structure are designed
to look somewhat like the header of a Payload.
o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o Transform Length - The length (in octets) of the Transform
Substructure including Header and Attributes.
o Transform Type (1 octet) - The type of transform being
specified in this transform. Different protocols support
different transform types. For some protocols, some of the
transforms may be optional. If a transform is optional and the
initiator wishes to propose that the transform be omitted, no
transform of the given type is included in the proposal. If
the initiator wishes to make use of the transform optional to
the responder, it includes a transform substructure with
transform ID = 0 as one of the options.
o Transform ID (2 octets) - The specific instance of the
transform type being proposed.
Transform Type Values
Transform Used In
Type
RESERVED 0
Encryption Algorithm (ENCR) 1 (IKE and ESP)
Pseudo-random Function (PRF) 2 (IKE)
Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP)
Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP)
Extended Sequence Numbers (ESN) 5 (AH and ESP)
RESERVED TO IANA 6-240
PRIVATE USE 241-255
For Transform Type 1 (Encryption Algorithm), defined Transform IDs
are:
Name Number Defined In
RESERVED 0
ENCR_DES_IV64 1 (RFC1827)
ENCR_DES 2 (RFC2405), [DES]
ENCR_3DES 3 (RFC2451)
ENCR_RC5 4 (RFC2451)
ENCR_IDEA 5 (RFC2451), [IDEA]
ENCR_CAST 6 (RFC2451)
ENCR_BLOWFISH 7 (RFC2451)
ENCR_3IDEA 8 (RFC2451)
ENCR_DES_IV32 9
RESERVED 10
ENCR_NULL 11 (RFC2410)
ENCR_AES_CBC 12 (RFC3602)
ENCR_AES_CTR 13 (RFC3664)
values 14-1023 are reserved to IANA. Values 1024-65535 are
for private use among mutually consenting parties.
For Transform Type 2 (Pseudo-random Function), defined Transform IDs
are:
Name Number Defined In
RESERVED 0
PRF_HMAC_MD5 1 (RFC2104), [MD5]
PRF_HMAC_SHA1 2 (RFC2104), [SHA]
PRF_HMAC_TIGER 3 (RFC2104)
PRF_AES128_XCBC 4 (RFC3664)
values 5-1023 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties.
For Transform Type 3 (Integrity Algorithm), defined Transform IDs
are:
Name Number Defined In
NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404)
AUTH_DES_MAC 3
AUTH_KPDK_MD5 4 (RFC1826)
AUTH_AES_XCBC_96 5 (RFC3566)
values 6-1023 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties.
For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs
are:
Name Number
NONE 0
Defined in Appendix B 1 - 2
RESERVED 3 - 4
Defined in [ADDGROUP] 5
RESERVED TO IANA 6 - 13
Defined in [ADDGROUP] 14 - 18
RESERVED TO IANA 19 - 1023
PRIVATE USE 1024-65535
For Transform Type 5 (Extended Sequence Numbers), defined Transform
IDs are:
Name Number
No Extended Sequence Numbers 0
Extended Sequence Numbers 1
RESERVED 2 - 65535
3.3.3. Valid Transform Types by Protocol
The number and type of transforms that accompany an SA payload are
dependent on the protocol in the SA itself. An SA payload proposing
the establishment of an SA has the following mandatory and optional
transform types. A compliant implementation MUST understand all
mandatory and optional types for each protocol it supports (though it
need not accept proposals with unacceptable suites). A proposal MAY
omit the optional types if the only value for them it will accept is
NONE.
Protocol Mandatory Types Optional Types
IKE ENCR, PRF, INTEG, D-H
ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H
3.3.4. Mandatory Transform IDs
The specification of suites that MUST and SHOULD be supported for
interoperability has been removed from this document because they are
likely to change more rapidly than this document evolves.
An important lesson learned from IKEv1 is that no system should only
implement the mandatory algorithms and expect them to be the best
choice for all customers. For example, at the time that this
document was written, many IKEv1 implementers were starting to
migrate to AES in Cipher Block Chaining (CBC) mode for Virtual
Private Network (VPN) applications. Many IPsec systems based on
IKEv2 will implement AES, additional Diffie-Hellman groups, and
additional hash algorithms, and some IPsec customers already require
these algorithms in addition to the ones listed above.
It is likely that IANA will add additional transforms in the future,
and some users may want to use private suites, especially for IKE
where implementations should be capable of supporting different
parameters, up to certain size limits. In support of this goal, all
implementations of IKEv2 SHOULD include a management facility that
allows specification (by a user or system administrator) of Diffie-
Hellman (DH) parameters (the generator, modulus, and exponent lengths
and values) for new DH groups. Implementations SHOULD provide a
management interface via which these parameters and the associated transform IDs may be entered (by a user or system administrator), to enable negotiating such groups. All implementations of IKEv2 MUST include a management facility that enables a user or system administrator to specify the suites that are acceptable for use with IKE. Upon receipt of a payload with a set of transform IDs, the implementation MUST compare the transmitted transform IDs against those locally configured via the management controls, to verify that the proposed suite is acceptable based on local policy. The implementation MUST reject SA proposals that are not authorized by these IKE suite controls. Note that cryptographic suites that MUST be implemented need not be configured as acceptable to local policy.3.3.5. Transform Attributes
Each transform in a Security Association payload may include attributes that modify or complete the specification of the transform. These attributes are type/value pairs and are defined below. For example, if an encryption algorithm has a variable-length key, the key length to be used may be specified as an attribute. Attributes can have a value with a fixed two octet length or a variable-length value. For the latter, the attribute is encoded as type/length/value. 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 9: Data Attributes o Attribute Type (2 octets) - Unique identifier for each type of attribute (see below). The most significant bit of this field is the Attribute Format bit (AF). It indicates whether the data attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is 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 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.
Note that only a single attribute type (Key Length) is defined, and
it is fixed length. The variable-length encoding specification is
included only for future extensions. The only algorithms defined in
this document that accept attributes are the AES-based encryption,
integrity, and pseudo-random functions, which require a single
attribute specifying key width.
Attributes described as basic MUST NOT be encoded using the
variable-length encoding. Variable-length attributes MUST NOT be
encoded as basic even if their value can fit into two octets. NOTE:
This is a change from IKEv1, where increased flexibility may have
simplified the composer of messages but certainly complicated the
parser.
Attribute Type Value Attribute Format
--------------------------------------------------------------
RESERVED 0-13 Key Length (in bits)
14 TV RESERVED 15-17
RESERVED TO IANA 18-16383 PRIVATE USE
16384-32767
Values 0-13 and 15-17 were used in a similar context in IKEv1 and
should not be assigned except to matching values. Values 18-16383
are reserved to IANA. Values 16384-32767 are for private use among
mutually consenting parties.
- Key Length
When using an Encryption Algorithm that has a variable-length key,
this attribute specifies the key length in bits (MUST use network
byte order). This attribute MUST NOT be used when the specified
Encryption Algorithm uses a fixed-length key.
3.3.6. Attribute Negotiation
During security association negotiation, initiators present offers to responders. Responders MUST select a single complete set of parameters from the offers (or reject all offers if none are acceptable). If there are multiple proposals, the responder MUST choose a single proposal number and return all of the Proposal substructures with that Proposal number. If there are multiple Transforms with the same type, the responder MUST choose a single one. Any attributes of a selected transform MUST be returned unmodified. The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not that response MUST be rejected. Negotiating Diffie-Hellman groups presents some special challenges. SA offers include proposed attributes and a Diffie-Hellman public number (KE) in the same message. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and include a KE corresponding to that group. If the guess turns out to be wrong, the responder will indicate the correct group in the response and the initiator SHOULD pick an element of that group for its KE value when retrying the first message. It SHOULD, however, continue to propose its full supported set of groups in order to prevent a man-in-the-middle downgrade attack. Implementation Note: Certain negotiable attributes can have ranges or could have multiple acceptable values. These include the key length of a variable key length symmetric cipher. To further interoperability and to support upgrading endpoints independently, implementers of this protocol SHOULD accept values that they deem to supply greater security. For instance, if a peer is configured to accept a variable-length cipher with a key length of X bits and is offered that cipher with a larger key length, the implementation SHOULD accept the offer if it supports use of the longer key. Support of this capability allows an implementation to express a concept of "at least" a certain level of security -- "a key length of _at least_ X bits for cipher Y".
3.4. Key Exchange Payload
The Key Exchange Payload, denoted KE in this memo, is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The Key Exchange Payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself. 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 !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! DH Group # ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Key Exchange Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Key Exchange Payload Format A key exchange payload is constructed by copying one's Diffie-Hellman public value into the "Key Exchange Data" portion of the payload. The length of the Diffie-Hellman public value MUST be equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary. The DH Group # identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see section 3.3.2). If the selected proposal uses a different Diffie-Hellman group, the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. The payload type for the Key Exchange payload is thirty four (34).3.5. Identification Payloads
The Identification Payloads, denoted IDi and IDr in this memo, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. NOTE: In IKEv1, two ID payloads were used in each direction to hold Traffic Selector (TS) information for data passing over the SA. In IKEv2, this information is carried in TS payloads (see section 3.13).
The Identification Payload consists of the IKE generic payload header followed by identification fields as follows: 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 !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Identification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Identification Payload Format o ID Type (1 octet) - Specifies the type of Identification being used. o RESERVED - MUST be sent as zero; MUST be ignored on receipt. o Identification Data (variable length) - Value, as indicated by the Identification Type. The length of the Identification Data is computed from the size in the ID payload header. The payload types for the Identification Payload are thirty five (35) for IDi and thirty six (36) for IDr. The following table lists the assigned values for the Identification Type field, followed by a description of the Identification Data which follows: ID Type Value ------- ----- RESERVED 0 ID_IPV4_ADDR 1 A single four (4) octet IPv4 address. ID_FQDN 2 A fully-qualified domain name string. An example of a ID_FQDN is, "example.com". The string MUST not contain any terminators (e.g., NULL, CR, etc.).
ID_RFC822_ADDR 3
A fully-qualified RFC822 email address string, An example of
a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST
not contain any terminators.
Reserved to IANA 4
ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address.
Reserved to IANA 6 - 8
ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [X.501].
ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.500 GeneralName
[X.509].
ID_KEY_ID 11
An opaque octet stream which may be used to pass vendor-
specific information necessary to do certain proprietary
types of identification.
Reserved to IANA 12-200
Reserved for private use 201-255
Two implementations will interoperate only if each can generate a
type of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be configurable to send at
least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these types. Implementations
SHOULD be capable of generating and accepting all of these types.
IPv6-capable implementations MUST additionally be configurable to
accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable
to send only ID_IPV6_ADDR.
3.6. Certificate Payload
The Certificate Payload, denoted CERT in this memo, provides a means to transport certificates or other authentication-related information via IKE. Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the term "Certificate Payload" is somewhat misleading, because not all authentication mechanisms use certificates and data other than certificates may be passed in this payload. The Certificate Payload is defined as follows: 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 !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cert Encoding ! ! +-+-+-+-+-+-+-+-+ ! ~ Certificate Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Certificate Payload Format o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. Certificate Encoding Value -------------------- ----- RESERVED 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 Kerberos Token 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate - Attribute 10 Raw RSA Key 11 Hash and URL of X.509 certificate 12 Hash and URL of X.509 bundle 13 RESERVED to IANA 14 - 200 PRIVATE USE 201 - 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 thirty seven (37).
Specific syntax is for some of the certificate type codes above is
not defined in this document. The types whose syntax is defined in
this document are:
X.509 Certificate - Signature (4) contains a DER encoded X.509
certificate whose public key is used to validate the sender's AUTH
payload.
Certificate Revocation List (7) contains a DER encoded X.509
certificate revocation list.
Raw RSA Key (11) contains a PKCS #1 encoded RSA key (see [RSA] and
[PKCS1]).
Hash and URL encodings (12-13) allow IKE messages to remain short
by replacing long data structures with a 20 octet SHA-1 hash (see
[SHA]) of the replaced value followed by a variable-length URL
that resolves to the DER encoded data structure itself. This
improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to denial of service attacks
that become easier to mount when IKE messages are large enough to
require IP fragmentation [KPS03].
Use the following ASN.1 definition for an X.509 bundle:
CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cert-bundle(34) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
Certificate, CertificateList
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
CertificateOrCRL ::= CHOICE {
cert [0] Certificate,
crl [1] CertificateList }
CertificateBundle ::= SEQUENCE OF CertificateOrCRL
END
Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication,
and also MUST be capable of being configured to send and accept the
first two Hash and URL formats (with HTTP URLs). Implementations
SHOULD be capable of being configured to send and accept Raw RSA
keys. If multiple certificates are sent, the first certificate MUST
contain the public key used to sign the AUTH payload. The other
certificates may be sent in any order.
3.7. Certificate Request Payload
The Certificate Request Payload, denoted CERTREQ in this memo,
provides a means to request preferred certificates via IKE and can
appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
Certificate Request payloads MAY be included in an exchange when the
sender needs to get the certificate of the receiver. If multiple CAs
are trusted and the cert encoding does not allow a list, then
multiple Certificate Request payloads SHOULD be transmitted.
The Certificate Request Payload is defined as follows:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding ! !
+-+-+-+-+-+-+-+-+ !
~ Certification Authority ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Certificate Request Payload Format
o Certificate Encoding (1 octet) - Contains an encoding of the type
or format of certificate requested. Values are listed in section
3.6.
o Certification Authority (variable length) - Contains an encoding
of an acceptable certification authority for the type of
certificate requested.
The payload type for the Certificate Request Payload is thirty eight
(38).
The Certificate Encoding field has the same values as those defined
in section 3.6. The Certification Authority field contains an
indicator of trusted authorities for this certificate type. The
Certification Authority value is a concatenated list of SHA-1 hashes
of the public keys of trusted Certification Authorities (CAs). Each
is encoded as the SHA-1 hash of the Subject Public Key Info element
(see section 4.1.2.7 of [RFC3280]) from each Trust Anchor
certificate. The twenty-octet hashes are concatenated and included
with no other formatting.
Note that the term "Certificate Request" is somewhat misleading, in
that values other than certificates are defined in a "Certificate"
payload and requests for those values can be present in a Certificate
Request Payload. The syntax of the Certificate Request payload in
such cases is not defined in this document.
The Certificate Request Payload is processed by inspecting the "Cert
Encoding" field to determine whether the processor has any
certificates of this type. If so, the "Certification Authority"
field is inspected to determine if the processor has any certificates
that can be validated up to one of the specified certification
authorities. This can be a chain of certificates.
If an end-entity certificate exists that satisfies the criteria
specified in the CERTREQ, a certificate or certificate chain SHOULD
be sent back to the certificate requestor if the recipient of the
CERTREQ:
- is configured to use certificate authentication,
- is allowed to send a CERT payload,
- has matching CA trust policy governing the current negotiation, and
- has at least one time-wise and usage appropriate end-entity
certificate chaining to a CA provided in the CERTREQ.
Certificate revocation checking must be considered during the
chaining process used to select a certificate. Note that even if two
peers are configured to use two different CAs, cross-certification
relationships should be supported by appropriate selection logic.
The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs, or other out- of-band configured means. Thus, the processing of a CERTREQ should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist, then the CERTREQ is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator).3.8. Authentication Payload
The Authentication Payload, denoted AUTH in this memo, contains data used for authentication purposes. The syntax of the Authentication data varies according to the Auth Method as specified below. The Authentication Payload is defined as follows: 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 !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Auth Method ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Authentication Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Authentication Payload Format o Auth Method (1 octet) - Specifies the method of authentication used. Values defined are: RSA Digital Signature (1) - Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash (see [RSA] and [PKCS1]). Shared Key Message Integrity Code (2) - Computed as specified in section 2.15 using the shared key associated with the identity in the ID payload and the negotiated prf function DSS Digital Signature (3) - Computed as specified in section 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash.
The values 0 and 4-200 are reserved to IANA. The values 201-255
are available for private use.
o Authentication Data (variable length) - see section 2.15.
The payload type for the Authentication Payload is thirty nine (39).
3.9. Nonce Payload
The Nonce Payload, denoted Ni and Nr in this memo for the initiator's
and responder's nonce respectively, contains random data used to
guarantee liveness during an exchange and protect against replay
attacks.
The Nonce Payload is defined as follows:
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Nonce Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Nonce Payload Format
o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity.
The payload type for the Nonce Payload is forty (40).
The size of a Nonce MUST be between 16 and 256 octets inclusive.
Nonce values MUST NOT be reused.
(page 64 continued on part 4)