RFC 7296
Internet Key Exchange Protocol Version 2 (IKEv2)
Pages: 142
Internet Standard: 79
→ Errata
Obsoletes: 5996
Updated by: 7427 7670 8247 8983 9370
Internet Standard: 79
→ Errata
Obsoletes: 5996
Updated by: 7427 7670 8247 8983 9370
Part 4 of 6 – Pages 72 to 99
3. Header and Payload Formats
In the tables in this section, some cryptographic primitives and configuration attributes are marked as "UNSPECIFIED". These are items for which there are no known specifications and therefore interoperability is currently impossible. A future specification may describe their use, but until such specification is made, implementations SHOULD NOT attempt to use items marked as "UNSPECIFIED" in implementations that are meant to be interoperable.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 zeros. These four octets of zeros 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 document. Following the header are one or more IKE payloads each identified by a Next Payload field in the preceding payload. Payloads are identified in the order in which they appear in an IKE message by looking in 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 responder's 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, including multiple sessions per peer. All multi-octet fields representing integers are laid out in big endian order (also known as "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). 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 document's version (version 2) of IKE MUST reject or ignore messages containing a version number greater than 2 with an INVALID_MAJOR_VERSION notification message as described in Section 2.5. 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 in an
exchange. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest
values.
Exchange Type Value
----------------------------------
IKE_SA_INIT 34
IKE_AUTH 35
CREATE_CHILD_SA 36
INFORMATIONAL 37
o Flags (1 octet) - Indicates specific options that are set for the
message. Presence of options is indicated by the appropriate bit
in the flags field being set. The bits are as follows:
+-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+
In the description below, a bit being 'set' means its value is
'1', while 'cleared' means its value is '0'. 'X' bits MUST be
cleared when sending and MUST be ignored on receipt.
* R (Response) - 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 (with one exception;
see Section 2.21.2).
* V (Version) - 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.
* I (Initiator) - 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. This bit changes to reflect who
initiated the last rekey of the IKE SA.
o Message ID (4 octets, unsigned integer) - 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, unsigned integer) - Length of the 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 each one 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);
conversely, the Next Payload field of the last contained payload
is set to zero. The payload type values are listed here. The
values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added
since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest
values.
Next Payload Type Notation Value
--------------------------------------------------
No Next Payload 0
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 and Authenticated SK 46
Configuration CP 47
Extensible Authentication EAP 48
(Payload type values 1-32 should not be assigned in the
future so that there is no overlap with the code assignments
for IKEv1.)
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. See Section 2.5 for more
information on this bit.
o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
receipt.
o Payload Length (2 octets, unsigned integer) - Length in octets of
the current payload, including the generic payload header.
Many payloads contain fields marked as "RESERVED". Some payloads in IKEv2 (and historically in IKEv1) are not aligned to 4-octet boundaries.3.3. Security Association Payload
The Security Association payload, denoted SA in this document, 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 contains a single IPsec protocol (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 ESP with either (3DES and HMAC_MD5) or (AES and HMAC_SHA1). One of the reasons the semantics of the SA payload have changed from ISAKMP and IKEv1 is to make the encodings more compact in common cases. The Proposal structure contains within it a Proposal Num and an IPsec protocol ID. Each structure MUST have a proposal number one (1) greater than the previous structure. The first Proposal in the initiator's SA payload MUST have a Proposal Num of one (1). One reason to use multiple proposals is to propose both standard crypto ciphers and combined-mode ciphers. Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and MUST either offer no integrity algorithm or a single integrity algorithm of "NONE", with no integrity algorithm being the RECOMMENDED method. If an initiator wants to propose both combined- mode ciphers and normal ciphers, it must include two proposals: one will have all the combined-mode ciphers, and the other will have all
the normal ciphers with the integrity algorithms. For example, one
such proposal would have two proposal structures. Proposal 1 is ESP
with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining
(CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity
algorithm; Proposal 2 is AES-128 or AES-256 in GCM mode with an
8-octet Integrity Check Value (ICV). Both proposals allow but do not
require the use of ESNs (Extended Sequence Numbers). This can be
illustrated as:
SA Payload
|
+--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
| | 7 transforms, SPI = 0x052357bb )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 128 )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 192 )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 256 )
| |
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
| +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
| +-- Transform ESN ( Name = ESNs )
| +-- Transform ESN ( Name = No ESNs )
|
+--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
| 4 transforms, SPI = 0x35a1d6f2 )
|
+-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
| +-- Attribute ( Key Length = 128 )
|
+-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform ESN ( Name = ESNs )
+-- Transform ESN ( Name = No ESNs )
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 two transforms:
Extended Sequence Numbers (ESNs) and an integrity check algorithm.
ESP generally has three: ESN, 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. 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 AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and two Transform Type 3 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), an 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Substruc | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ <Transforms> ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Proposal Substructure o Last Substruc (1 octet) - Specifies whether or not this is the last Proposal Substructure in the SA. This field has a value of 0 if this was the last Proposal Substructure, and a value of 2 if there are more Proposal Substructures. 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 four 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, unsigned integer) - Length of this proposal, including all transforms and attributes that follow. o Proposal Num (1 octet) - When a proposal is made, the first proposal in an SA payload MUST be 1, and subsequent proposals MUST be one more than the previous proposal (indicating an OR of the two proposals). When a proposal is accepted, the proposal number in the SA payload 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 values in the following table
are only current as of the publication date of RFC 4306. Other
values may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.
Protocol Protocol ID
-----------------------------------
IKE 1
AH 2
ESP 3
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 Num 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Substruc | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Transform Substructure
o Last Substruc (1 octet) - Specifies whether or not this is the
last Transform Substructure in the Proposal. This field has a
value of 0 if this was the last Transform Substructure, and a
value of 3 if there are more Transform Substructures. This syntax
is inherited from ISAKMP, but is unnecessary because the last
transform could be identified from the length of the proposal.
The value (3) corresponds to a payload type of Transform in IKEv1,
and the first four 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.
The Transform Type values are listed below. The values in the
following table are only current as of the publication date of
RFC 4306. Other values may have been added since then or will be
added after the publication of this document. Readers should refer
to [IKEV2IANA] for the latest values.
Description Trans. Used In
Type
------------------------------------------------------------------
Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudorandom 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
(*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. For example,
[AEAD] specifies additional formats based on authenticated
encryption, in which a separate integrity algorithm is not
negotiated.
For Transform Type 1 (Encryption Algorithm), the Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Name Number Defined In --------------------------------------------------- ENCR_DES_IV64 1 (UNSPECIFIED) 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 (UNSPECIFIED) ENCR_DES_IV32 9 (UNSPECIFIED) ENCR_NULL 11 [RFC2410] ENCR_AES_CBC 12 [RFC3602] ENCR_AES_CTR 13 [RFC3686] For Transform Type 2 (Pseudorandom Function), the Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Name Number Defined In ------------------------------------------------------------------ PRF_HMAC_MD5 1 [RFC2104], [MD5] PRF_HMAC_SHA1 2 [RFC2104], [FIPS.180-4.2012] PRF_HMAC_TIGER 3 (UNSPECIFIED) For Transform Type 3 (Integrity Algorithm), defined Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Name Number Defined In ---------------------------------------- NONE 0 AUTH_HMAC_MD5_96 1 [RFC2403] AUTH_HMAC_SHA1_96 2 [RFC2404] AUTH_DES_MAC 3 (UNSPECIFIED) AUTH_KPDK_MD5 4 (UNSPECIFIED) AUTH_AES_XCBC_96 5 [RFC3566]
For Transform Type 4 (Diffie-Hellman group), defined Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Name Number Defined In ------------------------------------------ NONE 0 768-bit MODP Group 1 Appendix B 1024-bit MODP Group 2 Appendix B 1536-bit MODP Group 5 [ADDGROUP] 2048-bit MODP Group 14 [ADDGROUP] 3072-bit MODP Group 15 [ADDGROUP] 4096-bit MODP Group 16 [ADDGROUP] 6144-bit MODP Group 17 [ADDGROUP] 8192-bit MODP Group 18 [ADDGROUP] Although ESP and AH do not directly include a Diffie-Hellman exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange, providing perfect forward secrecy for the generated Child SA keys. Note that the MODP Diffie-Hellman groups listed above do not need any special validity tests to be performed, but other types of groups (elliptic curve groups, and MODP groups with small subgroups) need to have some additional tests performed on them to use them securely. See "Additional Diffie-Hellman Tests for IKEv2" ([RFC6989]) for more information. For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are listed below. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Name Number -------------------------------------------- No Extended Sequence Numbers 0 Extended Sequence Numbers 1 Note that an initiator who supports ESNs will usually include two ESN transforms, with values "0" and "1", in its proposals. A proposal containing a single ESN transform with value "1" means that using normal (non-extended) sequence numbers is not acceptable.
Numerous additional Transform Types have been defined since the publication of RFC 4306. Please refer to the IANA "Internet Key Exchange Version 2 (IKEv2) Parameters" registry for details.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 (*) Negotiating an integrity algorithm is mandatory for the Encrypted payload format specified in this document. For example, [AEAD] specifies additional formats based on authenticated encryption, in which a separate integrity algorithm is not negotiated.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. At the time of publication of this document, [RFC4307] specifies these suites, but note that it might be updated in the future, and other RFCs might specify different sets of suites. 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. 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 parameters (the generator, modulus, and exponent lengths and values) for new Diffie-Hellman groups. Implementations SHOULD
provide a management interface through 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. The set of valid attributes depends on the transform. Currently, only a single attribute type is defined: the Key Length attribute is used by certain encryption transforms with variable- length keys (see below for details). The attributes are type/value pairs and are defined below. 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 Format (AF) (1 bit) - Indicates whether the data attribute follows the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is zero (0), then the attribute uses TLV format; if the AF bit is one (1), the TV format (with two-byte value) is used.
o Attribute Type (15 bits) - Unique identifier for each type of
attribute (see below).
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.
The only currently defined attribute type (Key Length) is fixed
length; the variable-length encoding specification is included only
for future extensions. Attributes described as fixed length MUST NOT
be encoded using the variable-length encoding unless that length
exceeds two bytes. Variable-length attributes MUST NOT be encoded as
fixed-length 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.
The values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added since
then or will be added after the publication of this document.
Readers should refer to [IKEV2IANA] for the latest values.
Attribute Type Value Attribute Format
------------------------------------------------------------
Key Length (in bits) 14 TV
Values 0-13 and 15-17 were used in a similar context in IKEv1, and
should not be assigned except to matching values.
The Key Length attribute specifies the key length in bits (MUST use
network byte order) for certain transforms as follows:
o The Key Length attribute MUST NOT be used with transforms that use
a fixed-length key. For example, this includes ENCR_DES,
ENCR_IDEA, and all the Type 2 (Pseudorandom Function) and Type 3
(Integrity Algorithm) transforms specified in this document. It
is recommended that future Type 2 or 3 transforms do not use this
attribute.
o Some transforms specify that the Key Length attribute MUST be
always included (omitting the attribute is not allowed, and
proposals not containing it MUST be rejected). For example, this
includes ENCR_AES_CBC and ENCR_AES_CTR.
o Some transforms allow variable-length keys, but also specify a
default key length if the attribute is not included. For example,
these transforms include ENCR_RC5 and ENCR_BLOWFISH.
Implementation note: 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 for this capability allows a responder to express a concept
of "at least" a certain level of security -- "a key length of _at
least_ X bits for cipher Y". However, as the attribute is always
returned unchanged (see the next section), an initiator willing to
accept multiple key lengths has to include multiple transforms with
the same Transform Type, each with a different Key Length attribute.
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. If the selected proposal has 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
MUST terminate the exchange.
If the responder receives a proposal that contains a Transform Type
it does not understand, or a proposal that is missing a mandatory
Transform Type, it MUST consider this proposal unacceptable; however,
other proposals in the same SA payload are processed as usual.
Similarly, if the responder receives a transform that it does not
understand, or one that contains a Transform Attribute it does not
understand, it MUST consider this transform unacceptable; other
transforms with the same Transform Type are processed as usual. This
allows new Transform Types and Transform Attributes to be defined in
the future.
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 responder selects a proposal using a different Diffie-Hellman group (other than NONE), 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. If one of the proposals offered is for the Diffie-Hellman group of NONE, and the responder selects that Diffie-Hellman group, then it MUST ignore the initiator's KE payload and omit the KE payload from the response.3.4. Key Exchange Payload
The Key Exchange payload, denoted KE in this document, 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diffie-Hellman Group Num | 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 for MODP groups 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 Diffie-Hellman Group Num identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). This Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified in a proposal in the SA payload that is sent in the same message, and SHOULD match the Diffie-Hellman group in the first group in the first proposal, if such exists. If none of the proposals in that SA payload specifies a Diffie-Hellman group, the KE payload MUST NOT be
present. If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. See also Sections 1.2 and 2.7. 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 document, 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. When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr are used purely to fetch the policy and authentication data related to the other party. 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 Peer Authorization Database (PAD) as described in RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement. The PAD is intended to provide a link between the SPD and the IKE Security Association management. See Section 4.4.3 of RFC 4301 for more details. 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 semantics for the
Identification Type field. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the publication
of this document. Readers should refer to [IKEV2IANA] for the latest
values.
ID Type Value
-------------------------------------------------------------------
ID_IPV4_ADDR 1
A single four (4) octet IPv4 address.
ID_FQDN 2
A fully-qualified domain name string. An example of an ID_FQDN
is "example.com". The string MUST NOT contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined
in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net".
ID_RFC822_ADDR 3
A fully-qualified RFC 822 email address string. An example of a
ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT
contain any terminators. Because of [EAI], implementations would
be wise to treat this field as UTF-8 encoded text, not as
pure ASCII.
ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address.
ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [PKIX].
ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX].
ID_KEY_ID 11
An opaque octet stream that may be used to pass vendor-
specific information necessary to do certain proprietary
types of identification.
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 four 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 instead of ID_IPV4_ADDR for
IP addresses.
EAP [EAP] does not mandate the use of any particular type of
identifier, but often EAP is used with Network Access Identifiers
(NAIs) defined in [NAI]. Although NAIs look a bit like email
addresses (e.g., "joe@example.com"), the syntax is not exactly the
same as the syntax of email address in [MAILFORMAT]. For those NAIs
that include the realm component, the ID_RFC822_ADDR identification
type SHOULD be used. Responder implementations should not attempt to
verify that the contents actually conform to the exact syntax given
in [MAILFORMAT], but instead should accept any reasonable-looking
NAI. For NAIs that do not include the realm component, the ID_KEY_ID
identification type SHOULD be used.
See "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and
PKIX" ([RFC4945]) for more information about matching Identification
payloads and the contents of the PKIX Certificates.
3.6. Certificate Payload
The Certificate payload, denoted CERT in this document, 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. The Hash and
URL formats of the Certificate payloads should be used in case 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. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Certificate Encoding Value ---------------------------------------------------- PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED PGP Certificate 2 UNSPECIFIED DNS Signed Key 3 UNSPECIFIED X.509 Certificate - Signature 4 Kerberos Token 6 UNSPECIFIED Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 UNSPECIFIED SPKI Certificate 9 UNSPECIFIED X.509 Certificate - Attribute 10 UNSPECIFIED Deprecated (was Raw RSA Key) 11 DEPRECATED Hash and URL of X.509 certificate 12 Hash and URL of X.509 bundle 13 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 for some of the certificate type codes above is not
defined in this document. The types whose syntax is defined in this
document are:
o "X.509 Certificate - Signature" contains a DER-encoded X.509
certificate whose public key is used to validate the sender's AUTH
payload. Note that with this encoding, if a chain of certificates
needs to be sent, multiple CERT payloads are used, only the first
of which holds the public key used to validate the sender's AUTH
payload.
o "Certificate Revocation List" contains a DER-encoded X.509
certificate revocation list.
o Hash and URL encodings allow IKE messages to remain short by
replacing long data structures with a 20-octet SHA-1 hash (see
[FIPS.180-4.2012]) 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 DoS attacks that become
easier to mount when IKE messages are large enough to require IP
fragmentation [DOSUDPPROT].
The "Hash and URL of a bundle" type uses the following ASN.1
definition for the 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 two Hash and URL formats (with HTTP URLs). If multiple certificates are sent, the first certificate MUST contain the public key associated with the private key used to sign the AUTH payload. The other certificates may be sent in any order. Implementations MUST support the "http:" scheme for hash-and-URL lookup. The behavior of other URL schemes [URLS] is not currently specified, and such schemes SHOULD NOT be used in the absence of a document specifying them.3.7. Certificate Request Payload
The Certificate Request payload, denoted CERTREQ in this document, 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. 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 [PKIX]) from each Trust Anchor certificate. The 20-octet hashes are concatenated and included with no other formatting. The contents of the Certification Authority field are defined only for X.509 certificates, which are types 4, 12, and 13. Other values SHOULD NOT be used until Standards-Track specifications that specify their use are published. 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: o is configured to use certificate authentication, o is allowed to send a CERT payload, o has matching CA trust policy governing the current negotiation, and o 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). The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format).3.8. Authentication Payload
The Authentication payload, denoted AUTH in this document, 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. The types of signatures are listed here. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to [IKEV2IANA] for the latest values.
Mechanism Value
-----------------------------------------------------------------
RSA Digital Signature 1
Computed as specified in Section 2.15 using an RSA private key
with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1]
(implementers should note that IKEv1 used a different method for
RSA signatures). To promote interoperability, implementations
that support this type SHOULD support signatures that use SHA-1
as the hash function and SHOULD use SHA-1 as the default hash
function when generating signatures. Implementations can use the
certificates received from a given peer as a hint for selecting a
mutually understood hash function for the AUTH payload signature.
Note, however, that the hash algorithm used in the AUTH payload
signature doesn't have to be the same as any hash algorithm(s)
used in the certificate(s).
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.
DSS Digital Signature 3
Computed as specified in Section 2.15 using a DSS private key
(see [DSS]) over a SHA-1 hash.
o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
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 as Ni and Nr in this document 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 the Nonce Data MUST be between 16 and 256 octets, inclusive. Nonce values MUST NOT be reused.
(page 99 continued on part 5)