Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4718

IKEv2 Clarifications and Implementation Guidelines

Pages: 58
Obsoleted by:  5996
Part 1 of 3 – Pages 1 to 14
None   None   Next

ToP   noToC   RFC4718 - Page 1
Network Working Group                                          P. Eronen
Request for Comments: 4718                                         Nokia
Category: Informational                                       P. Hoffman
                                                          VPN Consortium
                                                            October 2006


           IKEv2 Clarifications and Implementation Guidelines

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations.
ToP   noToC   RFC4718 - Page 2

Table of Contents

1. Introduction ....................................................4 2. Creating the IKE_SA .............................................4 2.1. SPI Values in IKE_SA_INIT Exchange .........................4 2.2. Message IDs for IKE_SA_INIT Messages .......................5 2.3. Retransmissions of IKE_SA_INIT Requests ....................5 2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6 2.5. Invalid Cookies ............................................8 3. Authentication ..................................................9 3.1. Data Included in AUTH Payload Calculation ..................9 3.2. Hash Function for RSA Signatures ...........................9 3.3. Encoding Method for RSA Signatures ........................10 3.4. Identification Type for EAP ...............................11 3.5. Identity for Policy Lookups When Using EAP ................11 3.6. Certificate Encoding Types ................................12 3.7. Shared Key Authentication and Fixed PRF Key Size ..........12 3.8. EAP Authentication and Fixed PRF Key Size .................13 3.9. Matching ID Payloads to Certificate Contents ..............13 3.10. Message IDs for IKE_AUTH Messages ........................14 4. Creating CHILD_SAs .............................................14 4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14 4.2. Creating an IKE_SA without a CHILD_SA .....................16 4.3. Diffie-Hellman for First CHILD_SA .........................16 4.4. Extended Sequence Numbers (ESN) Transform .................17 4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17 4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18 4.7. Semantics of Complex Traffic Selector Payloads ............18 4.8. ICMP Type/Code in Traffic Selector Payloads ...............19 4.9. Mobility Header in Traffic Selector Payloads ..............20 4.10. Narrowing the Traffic Selectors ..........................20 4.11. SINGLE_PAIR_REQUIRED .....................................21 4.12. Traffic Selectors Violating Own Policy ...................21 4.13. Traffic Selector Authorization ...........................22 5. Rekeying and Deleting SAs ......................................23 5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23 5.2. Rekeying the IKE_SA vs. Reauthentication ..................24 5.3. SPIs When Rekeying the IKE_SA .............................25 5.4. SPI When Rekeying a CHILD_SA ..............................25 5.5. Changing PRFs When Rekeying the IKE_SA ....................26 5.6. Deleting vs. Closing SAs ..................................26 5.7. Deleting a CHILD_SA Pair ..................................26 5.8. Deleting an IKE_SA ........................................27 5.9. Who is the original initiator of IKE_SA ...................27 5.10. Comparing Nonces .........................................27 5.11. Exchange Collisions ......................................28 5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36
ToP   noToC   RFC4718 - Page 3
   6. Configuration Payloads .........................................37
      6.1. Assigning IP Addresses ....................................37
      6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
      6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
      6.4. INTERNAL_IP4_NETMASK ......................................41
      6.5. Configuration Payloads for IPv6 ...........................42
      6.6. INTERNAL_IP6_NBNS .........................................43
      6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
      6.8. Address Assignment Failures ...............................44
   7. Miscellaneous Issues ...........................................45
      7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
      7.2. Relationship of IKEv2 to RFC 4301 .........................45
      7.3. Reducing the Window Size ..................................46
      7.4. Minimum Size of Nonces ....................................46
      7.5. Initial Zero Octets on Port 4500 ..........................46
      7.6. Destination Port for NAT Traversal ........................47
      7.7. SPI Values for Messages outside an IKE_SA .................47
      7.8. Protocol ID/SPI Fields in Notify Payloads .................48
      7.9. Which message should contain INITIAL_CONTACT ..............48
      7.10. Alignment of Payloads ....................................48
      7.11. Key Length Transform Attribute ...........................48
      7.12. IPsec IANA Considerations ................................49
      7.13. Combining ESP and AH .....................................50
   8. Implementation Mistakes ........................................50
   9. Security Considerations ........................................51
   10. Acknowledgments ...............................................51
   11. References ....................................................51
      11.1. Normative References .....................................51
      11.2. Informative References ...................................52
   Appendix A. Exchanges and Payloads ................................54
      A.1. IKE_SA_INIT Exchange ......................................54
      A.2. IKE_AUTH Exchange without EAP .............................54
      A.3. IKE_AUTH Exchange with EAP ................................55
      A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
           CHILD_SAs .................................................56
      A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
      A.6. INFORMATIONAL Exchange ....................................56
ToP   noToC   RFC4718 - Page 4

1. Introduction

This document clarifies many areas of the IKEv2 specification that may be difficult to understand to developers not intimately familiar with the specification and its history. The clarifications in this document come from the discussion on the IPsec WG mailing list, from experience in interoperability testing, and from implementation issues that have been brought to the editors' attention. IKEv2/IPsec can be used for several different purposes, including IPsec-based remote access (sometimes called the "road warrior" case), site-to-site virtual private networks (VPNs), and host-to-host protection of application traffic. While this document attempts to consider all of these uses, the remote access scenario has perhaps received more attention here than the other uses. This document does not place any requirements on anyone and does not use [RFC2119] keywords such as "MUST" and "SHOULD", except in quotations from the original IKEv2 documents. The requirements are given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic algorithms document [IKEv2ALG]. In this document, references to a numbered section (such as "Section 2.15") mean that section in [IKEv2]. References to mailing list messages or threads refer to the IPsec WG mailing list at ipsec@ietf.org. Archives of the mailing list can be found at <http://www.ietf.org/mail-archive/web/ipsec/index.html>.

2. Creating the IKE_SA

2.1. SPI Values in IKE_SA_INIT Exchange

Normal IKE messages include the initiator's and responder's Security Parameter Indexes (SPIs), both of which are non-zero, in the IKE header. However, there are some corner cases where the IKEv2 specification is not fully consistent about what values should be used. First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero in any other message" (than the first message of the IKE_SA_INIT exchange). However, the figure in Section 2.6 shows the second IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text in 3.1. Since the responder's SPI identifies security-related state held by the responder, and in this case no state is created, sending a zero value seems reasonable.
ToP   noToC   RFC4718 - Page 5
   Second, in addition to cookies, there are several other cases when
   the IKE_SA_INIT exchange does not result in the creation of an IKE_SA
   (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN).  What
   responder SPI value should be used in the IKE_SA_INIT response in
   this case?

   Since the IKE_SA_INIT request always has a zero responder SPI, the
   value will not be actually used by the initiator.  Thus, we think
   sending a zero value is correct also in this case.

   If the responder sends a non-zero responder SPI, the initiator should
   not reject the response only for that reason.  However, when retrying
   the IKE_SA_INIT request, the initiator will use a zero responder SPI,
   as described in Section 3.1: "Responder's SPI [...]  This value MUST
   be zero in the first message of an IKE Initial Exchange (including
   repeats of that message including a cookie) [...]".  We believe the
   intent was to cover repeats of that message due to other reasons,
   such as INVALID_KE_PAYLOAD, as well.

   (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
   Sep-Oct 2005.)

2.2. Message IDs for IKE_SA_INIT Messages

The Message ID for IKE_SA_INIT messages is always zero. This includes retries of the message due to responses such as COOKIE and INVALID_KE_PAYLOAD. This is because Message IDs are part of the IKE_SA state, and when the responder replies to IKE_SA_INIT request with N(COOKIE) or N(INVALID_KE_PAYLOAD), the responder does not allocate any state. (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD) combination" thread, Oct 2004. Tero Kivinen's mail "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)

2.3. Retransmissions of IKE_SA_INIT Requests

When a responder receives an IKE_SA_INIT request, it has to determine whether the packet is a retransmission belonging to an existing "half-open" IKE_SA (in which case the responder retransmits the same response), or a new request (in which case the responder creates a new IKE_SA and sends a fresh response). The specification does not describe in detail how this determination is done. In particular, it is not sufficient to use the initiator's SPI and/or IP address for this purpose: two different peers behind a single NAT could choose the same initiator SPI (and the probability
ToP   noToC   RFC4718 - Page 6
   of this happening is not necessarily small, since IKEv2 does not
   require SPIs to be chosen randomly).  Instead, the responder should
   do the IKE_SA lookup using the whole packet or its hash (or at the
   minimum, the Ni payload which is always chosen randomly).

   For all other packets than IKE_SA_INIT requests, looking up right
   IKE_SA is of course done based on the recipient's SPI (either the
   initiator or responder SPI depending on the value of the Initiator
   bit in the IKE header).

2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD

There are two common reasons why the initiator may have to retry the IKE_SA_INIT exchange: the responder requests a cookie or wants a different Diffie-Hellman group than was included in the KEi payload. Both of these cases are quite simple alone, but it is not totally obvious what happens when they occur at the same time, that is, the IKE_SA_INIT exchange is retried several times. The main question seems to be the following: if the initiator receives a cookie from the responder, should it include the cookie in only the next retry of the IKE_SA_INIT request, or in all subsequent retries as well? Section 3.10.1 says that: "This notification MUST be included in an IKE_SA_INIT request retry if a COOKIE notification was included in the initial response." This could be interpreted as saying that when a cookie is received in the initial response, it is included in all retries. On the other hand, Section 2.6 says that: "Initiators who receive such responses MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE containing the responder supplied cookie data as the first payload and all other payloads unchanged." Including the same cookie in later retries makes sense only if the "all other payloads unchanged" restriction applies only to the first retry, but not to subsequent retries. It seems that both interpretations can peacefully coexist. If the initiator includes the cookie only in the next retry, one additional roundtrip may be needed in some cases:
ToP   noToC   RFC4718 - Page 7
      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), SAi1, KEi', Ni -->
                              <-- HDR(A,0), N(COOKIE')
      HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   An additional roundtrip is needed also if the initiator includes the
   cookie in all retries, but the responder does not support this
   functionality.  For instance, if the responder includes the SAi1 and
   KEi payloads in cookie calculation, it will reject the request by
   sending a new cookie (see also Section 2.5 of this document for more
   text about invalid cookies):


      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
                              <-- HDR(A,0), N(COOKIE')
      HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   If both peers support including the cookie in all retries, a slightly
   shorter exchange can happen:

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   This document recommends that implementations should support this
   shorter exchange, but it must not be assumed the other peer also
   supports the shorter exchange.
ToP   noToC   RFC4718 - Page 8
   In theory, even this exchange has one unnecessary roundtrip, as both
   the cookie and Diffie-Hellman group could be checked at the same
   time:

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE),
                                            N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   However, it is clear that this case is not allowed by the text in
   Section 2.6, since "all other payloads" clearly includes the KEi
   payload as well.

   (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
   Sep-Oct 2005.)

2.5. Invalid Cookies

There has been some confusion what should be done when an IKE_SA_INIT request containing an invalid cookie is received ("invalid" in the sense that its contents do not match the value expected by the responder). The correct action is to ignore the cookie and process the message as if no cookie had been included (usually this means sending a response containing a new cookie). This is shown in Section 2.6 when it says "The responder in that case MAY reject the message by sending another response with a new cookie [...]". Other possible actions, such as ignoring the whole request (or even all requests from this IP address for some time), create strange failure modes even in the absence of any malicious attackers and do not provide any additional protection against DoS attacks. (References: "Invalid Cookie" thread, Sep-Oct 2005.)
ToP   noToC   RFC4718 - Page 9

3. Authentication

3.1. Data Included in AUTH Payload Calculation

Section 2.15 describes how the AUTH payloads are calculated; this calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The text describes the method in words, but does not give clear definitions of what is signed or MACed (i.e., protected with a message authentication code). The initiator's signed octets can be described as: InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage1 = RealIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfIDPayload RestOfInitIDPayload = IDType | RESERVED | InitIDData MACedIDForI = prf(SK_pi, RestOfInitIDPayload) The responder's signed octets can be described as: ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage2 = RealIKEHDR | RestOfMessage2 NonceIPayload = PayloadHeader | NonceIData ResponderIDPayload = PayloadHeader | RestOfIDPayload RestOfRespIDPayload = IDType | RESERVED | InitIDData MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

3.2. Hash Function for RSA Signatures

Section 3.8 says that RSA digital signature is "Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash." Unlike IKEv1, IKEv2 does not negotiate a hash function for the IKE_SA. The algorithm for signatures is selected by the signing party who, in general, may not know beforehand what algorithms the verifying party supports. Furthermore, [IKEv2ALG] does not say what algorithms implementations are required or recommended to support. This clearly has a potential for causing interoperability problems, since authentication will fail if the signing party selects an algorithm that is not supported by the verifying party, or not acceptable according to the verifying party's policy.
ToP   noToC   RFC4718 - Page 10
   This document recommends that all implementations support SHA-1 and
   use SHA-1 as the default hash function when generating the
   signatures, unless there are good reasons (such as explicit manual
   configuration) to believe that the peer supports something else.

   Note that hash function collision attacks are not important for the
   AUTH payloads, since they are not intended for third-party
   verification, and the data includes fresh nonces.  See [HashUse] for
   more discussion about hash function attacks and IPsec.

   Another reasonable choice would be to use the hash function that was
   used by the CA when signing the peer certificate.  However, this does
   not guarantee that the IKEv2 peer would be able to validate the AUTH
   payload, because the same code might not be used to validate
   certificate signatures and IKEv2 message signatures, and these two
   routines may support a different set of hash algorithms.  The peer
   could be configured with a fingerprint of the certificate, or
   certificate validation could be performed by an external entity using
   [SCVP].  Furthermore, not all CERT payloads types include a
   signature, and the certificate could be signed with some algorithm
   other than RSA.

   Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
   signature encoding method (see next section for details), which
   includes the algorithm identifier for the hash algorithm.  Thus, when
   the verifying party receives the AUTH payload it can at least
   determine which hash function was used.

   (References: Magnus Alstrom's mail "RE:", 2005-01-03.  Pasi Eronen's
   reply, 2005-01-04.  Tero Kivinen's reply, 2005-01-04.  "First draft
   of IKEv2.1" thread, Dec 2005/Jan 2006.)

3.3. Encoding Method for RSA Signatures

Section 3.8 says that the RSA digital signature is "Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash." The PKCS#1 specification [PKCS1v21] defines two different encoding methods (ways of "padding the hash") for signatures. However, the Internet-Draft approved by the IESG had a reference to the older PKCS#1 v2.0 [PKCS1v20]. That version has only one encoding method for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity.
ToP   noToC   RFC4718 - Page 11
   Note that this encoding method is different from the encoding method
   used in IKEv1.  If future revisions of IKEv2 provide support for
   other encoding methods (such as EMSA-PSS), they will be given new
   Auth Method numbers.

   (References: Pasi Eronen's mail "RE:", 2005-01-04.)

3.4. Identification Type for EAP

Section 3.5 defines several different types for identification payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID. 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 [RFC822]. This raises the question of which identification type should be used. This document recommends that ID_RFC822_ADDR identification type is used for those NAIs that include the realm component. Therefore, responder implementations should not attempt to verify that the contents actually conform to the exact syntax given in [RFC822] or [RFC2822], but instead should accept any reasonable looking NAI. For NAIs that do not include the realm component, this document recommends using the ID_KEY_ID identification type. (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2 identifier issue with EAP" threads, Aug 2004.)

3.5. Identity for Policy Lookups When Using EAP

When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method (see [EAP], Sections 5.1 and 7.3). It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder using, e.g., RADIUS [RADEAP]. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. (References: Pasi Eronen's mail "RE: Reauthentication in IKEv2", 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748, Section 7.3.)
ToP   noToC   RFC4718 - Page 12

3.6. Certificate Encoding Types

Section 3.6 defines a total of twelve different certificate encoding types, and continues that "Specific syntax is for some of the certificate type codes above is not defined in this document." However, the text does not provide references to other documents that would contain information about the exact contents and use of those values. Without this information, it is not possible to develop interoperable implementations. Therefore, this document recommends that the following certificate encoding values should not be used before new specifications that specify their use are available. PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 Kerberos Token 6 SPKI Certificate 9 This document recommends that most implementations should use only those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e., "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle" (13). Furthermore, Section 3.7 says that the "Certificate Encoding" field for the Certificate Request payload uses the same values as for Certificate payload. However, the contents of the "Certification Authority" field are defined only for X.509 certificates (presumably covering at least types 4, 10, 12, and 13). This document recommends that other values should not be used before new specifications that specify their use are available. The "Raw RSA Key" type needs one additional clarification. Section 3.6 says it contains "a PKCS #1 encoded RSA key". What this means is a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].

3.7. Shared Key Authentication and Fixed PRF Key Size

Section 2.15 says that "If the negotiated prf takes a fixed-size key, the shared secret MUST be of that fixed size". This statement is correct: the shared secret must be of the correct size. If it is not, it cannot be used; there is no padding, truncation, or other processing involved to force it to that correct size.
ToP   noToC   RFC4718 - Page 13
   This requirement means that it is difficult to use these pseudo-
   random functions (PRFs) with shared key authentication.  The authors
   think this part of the specification was very poorly thought out, and
   using PRFs with a fixed key size is likely to result in
   interoperability problems.  Thus, we recommend that such PRFs should
   not be used with shared key authentication.  PRF_AES128_XCBC
   [RFC3664] originally used fixed key sizes; that RFC has been updated
   to handle variable key sizes in [RFC4434].

   Note that Section 2.13 also contains text that is related to PRFs
   with fixed key size: "When the key for the prf function has fixed
   length, the data provided as a key is truncated or padded with zeros
   as necessary unless exceptional processing is explained following the
   formula".  However, this text applies only to the prf+ construction,
   so it does not contradict the text in Section 2.15.

   (References: Paul Hoffman's mail "Re: ikev2-07: last nits",
   2003-05-02.  Hugo Krawczyk's reply, 2003-05-12.  Thread "Question
   about PRFs with fixed size key", Jan 2005.)

3.8. EAP Authentication and Fixed PRF Key Size

As described in the previous section, PRFs with a fixed key size require a shared secret of exactly that size. This restriction applies also to EAP authentication. For instance, a PRF that requires a 128-bit key cannot be used with EAP since [EAP] specifies that the MSK is at least 512 bits long. (References: Thread "Question about PRFs with fixed size key", Jan 2005.)

3.9. Matching ID Payloads to Certificate Contents

In IKEv1, there was some confusion about whether or not the identities in certificates used to authenticate IKE were required to match the contents of the ID payloads. The PKI4IPsec Working Group produced the document [PKI4IPsec] which covers this topic in much more detail. However, Section 3.5 of [IKEv2] explicitly says that the ID payload "does not necessarily have to match anything in the CERT payload".
ToP   noToC   RFC4718 - Page 14

3.10. Message IDs for IKE_AUTH Messages

According to Section 2.2, "The IKE_SA initial setup messages will always be numbered 0 and 1." That is true when the IKE_AUTH exchange does not use EAP. When EAP is used, each pair of messages has their message numbers incremented. The first pair of AUTH messages will have an ID of 1, the second will be 2, and so on. (References: "Question about MsgID in AUTH exchange" thread, April 2005.)


(page 14 continued on part 2)

Next Section