tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4718


Pages: 58
Top     in Index     Prev     Next
 

IKEv2 Clarifications and Implementation Guidelines

Part 1 of 3, p. 1 to 14
None       Next RFC Part

Obsoleted by:    5996


Top       ToC       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       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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 RFC Part