doc: Add RFC documents

1 files changed, 1851 insertions, 0 deletions

diff --git a/doc/rfc/rfc5106.txt b/doc/rfc/rfc5106.txt
new file mode 100644
index 0000000..91558fc
--- /dev/null
+++ b/doc/rfc/rfc5106.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group                                      H. Tschofenig
+Request for Comments: 5106                                D. Kroeselberg
+Category: Experimental                            Nokia Siemens Networks
+                                                           A. Pashalidis
+                                                                     NEC
+                                                                 Y. Ohba
+                                                                 Toshiba
+                                                              F. Bersani
+                                                          France Telecom
+                                                           February 2008
+
+
+ The Extensible Authentication Protocol-Internet Key Exchange Protocol
+                     version 2 (EAP-IKEv2) Method
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies EAP-IKEv2, an Extensible Authentication
+   Protocol (EAP) method that is based on the Internet Key Exchange
+   (IKEv2) protocol.  EAP-IKEv2 provides mutual authentication and
+   session key establishment between an EAP peer and an EAP server.  It
+   supports authentication techniques that are based on passwords,
+   high-entropy shared keys, and public key certificates.  EAP-IKEv2
+   further provides support for cryptographic ciphersuite negotiation,
+   hash function agility, identity confidentiality (in certain modes of
+   operation), fragmentation, and an optional "fast reconnect" mode.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                      [Page 1]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................4
+   3. Protocol Overview ...............................................6
+   4. Fast Reconnect ..................................................9
+   5. Key Derivation .................................................12
+   6. Session ID, Peer ID, and Server ID .............................13
+   7. Error Handling .................................................13
+   8. Specification of Protocol Fields ...............................16
+      8.1. The Flags, Message Length, and Integrity Checksum
+           Data Fields ...............................................17
+      8.2. EAP-IKEv2 Header ..........................................19
+      8.3. Security Association Payload ..............................19
+      8.4. Key Exchange Payload ......................................20
+      8.5. Nonce Payload .............................................20
+      8.6. Identification Payload ....................................20
+      8.7. Certificate Payload .......................................20
+      8.8. Certificate Request Payload ...............................20
+      8.9. Encrypted Payload .........................................20
+      8.10. Authentication Payload ...................................20
+      8.11. Notify Payload ...........................................21
+      8.12. Next Fast-ID Payload .....................................21
+   9. Payload Types and Extensibility ................................22
+   10. Security Considerations .......................................22
+      10.1. Protected Ciphersuite Negotiation ........................23
+      10.2. Mutual Authentication ....................................23
+      10.3. Integrity Protection .....................................23
+      10.4. Replay Protection ........................................23
+      10.5. Confidentiality ..........................................23
+      10.6. Key Strength .............................................24
+      10.7. Dictionary Attack Resistance .............................24
+      10.8. Fast Reconnect ...........................................25
+      10.9. Cryptographic Binding ....................................25
+      10.10. Session Independence ....................................25
+      10.11. Fragmentation ...........................................26
+      10.12. Channel Binding .........................................26
+      10.13. Summary .................................................26
+   11. IANA Considerations ...........................................27
+   12. Contributors ..................................................28
+   13. Acknowledgements ..............................................28
+   14. References ....................................................29
+      14.1. Normative References .....................................29
+      14.2. Informative References ...................................29
+   Appendix A ........................................................30
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                      [Page 2]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+1.  Introduction
+
+   This document specifies EAP-IKEv2, an EAP method that is based on the
+   Internet Key Exchange Protocol version 2 (IKEv2) [1].  EAP-IKEv2
+   provides mutual authentication and session key establishment between
+   an EAP peer and an EAP server.  It supports authentication techniques
+   that are based on the following types of credentials:
+
+   o  Asymmetric key pairs: these are public/private key pairs where the
+      public key is embedded into a digital certificate, and the
+      corresponding private key is known only to a single party.
+
+   o  Passwords: these are low-entropy bit strings that are known to
+      both the server and the peer.
+
+   o  Symmetric keys: these are high-entropy bit strings that are known
+      to both the server and the peer.
+
+   It is possible to use a different authentication credential (and
+   thereby technique) for each direction, e.g., the EAP server may
+   authenticate itself using a public/private key pair and the EAP
+   client may authenticate itself using a symmetric key.  In particular,
+   the following combinations are expected to be used in practice; these
+   are referred to as "use cases" or "modes" in the remainder of this
+   document:
+
+   1.  EAP server: asymmetric key pair, EAP peer: asymmetric key pair
+
+   2.  EAP server: asymmetric key pair, EAP peer: symmetric key
+
+   3.  EAP server: asymmetric key pair, EAP peer: password
+
+   4.  EAP server: symmetric key, EAP peer: symmetric key
+
+   Note that in use cases 2 and 4, a symmetric key is assumed to be
+   chosen uniformly at random from its key space; it is therefore
+   assumed that symmetric keys are not derived from passwords.  Deriving
+   a symmetric key from a password is insecure when used with mode 4
+   since the exchange is vulnerable to dictionary attacks, as described
+   in more detail in Section 10.7.  Also note that in use case 3, the
+   EAP server must either have access to all passwords in plaintext, or,
+   alternatively, for each password store, the value prf(password,"Key
+   Pad for EAP-IKEv2") for all supported pseudorandom functions (also
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                      [Page 3]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   see Section 8.10 below and Section 2.15 of [1]).  Other conceivable
+   use cases are not expected to be used in practice due to key
+   management issues, and have not been considered in this document.
+
+   Note that the IKEv2 protocol is able to carry EAP exchanges.  By
+   contrast, EAP-IKEv2 does not inherit this capability.  That is, it is
+   not possible to tunnel EAP methods inside EAP-IKEv2.  Also note that
+   the set of functionality provided by EAP-IKEv2 is similar, but not
+   identical, to that provided by other EAP methods such as, for
+   example, EAP-TLS [6].
+
+   The remainder of this document is structured as follows:
+
+   o  Section 2 provides an overview of the terminology and the
+      abbreviations used in this document.
+
+   o  Section 3 provides an overview of the full EAP-IKEv2 exchange and
+      thereby specifies the protocol message composition.
+
+   o  Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode
+      of operation.
+
+   o  Section 5 specifies how exportable session keys are derived.
+
+   o  Section 6 specifies how the Session-ID, Peer-ID, and Server-ID
+      elements are derived.
+
+   o  Section 7 specifies how errors that may potentially occur during
+      protocol execution are handled.
+
+   o  Section 8 specifies the format of the EAP-IKEv2 data fields.
+      Section 8.1 describes how fragmentation is handled in EAP-IKEv2.
+
+   o  Section 9 specifies the payload type values and describes protocol
+      extensibility.
+
+   o  Section 10 provides a list of claimed security properties.
+
+2.  Terminology
+
+   This document makes use of terms defined in [2] and [1].  In
+   addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
+   SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear
+   in this document, are to be interpreted as described in [3].
+
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                      [Page 4]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   A list of abbreviations that are used in this document follows.
+
+   AUTH:
+
+      Denotes a data field containing either a Message Authentication
+      Code (MAC) or a signature.  This field is embedded into an
+      Authentication payload, defined in Section 8.10.
+
+   CERT:
+
+      Public key certificate or similar structure.
+
+   CERTREQ:
+
+      Certificate Request.
+
+   NFID:
+
+      Next Fast-ID payload (see Sections 4 and 8.12)
+
+   EMSK:
+
+      Extended Master Session Key, defined in [2].
+
+   HDR:
+
+      EAP-IKEv2 header, defined in Section 8.2.
+
+   I:
+
+      Initiator, the party that sends the first message of an EAP-IKEv2
+      protocol run.  This is always the EAP server.
+
+   MAC:
+
+      Message Authentication Code.  The result of a cryptographic
+      operation that involves a symmetric key.
+
+   MSK:
+
+      Master Session Key, defined in [2].
+
+   prf:
+
+      Pseudorandom function: a cryptographic function whose output is
+      assumed to be indistinguishable from that of a truly random
+      function.
+
+
+
+
+Tschofenig, et al.            Experimental                      [Page 5]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   R:
+
+      Responder, the party that sends the second message of an EAP-IKEv2
+      protocol run.  This is always the EAP peer.
+
+   SA:
+
+      Security Association.  In this document, SA denotes a type of
+      payload that is used for the negotiation of the cryptographic
+      algorithms that are to be used within an EAP-IKEv2 protocol run.
+      Specifically, SAi denotes a set of choices that are accepted by an
+      initiator, and SAr denotes the choice of the responder.
+
+   Signature:
+
+      The result of a cryptographic operation that involves an
+      asymmetric key.  In particular, it involves the private part of a
+      public/private key pair.
+
+   SK:
+
+      Session Key.  In this document, the notation SK{x} denotes that x
+      is embedded within an Encrypted payload, i.e., that x is encrypted
+      and integrity-protected using EAP-IKEv2 internal keys.  These keys
+      are different in each direction.
+
+   SK_xx:
+
+      EAP-IKEv2 internal key, defined in Section 2.14 of [1].
+
+   SKEYSEED:
+
+      Keying material, defined in Section 2.14 of [1].
+
+3.  Protocol Overview
+
+   In this section, the full EAP-IKEv2 protocol run is specified.  All
+   messages are sent between two parties, namely an EAP peer and an EAP
+   server.  In EAP-IKEv2, the EAP server always assumes the role of the
+   initiator (I), and the EAP peer that of the responder (R) of an
+   exchange.
+
+   The semantics and formats of EAP-IKEv2 messages are similar, albeit
+   not identical, to those specified in IKEv2 [1] for the establishment
+   of an IKE Security Association.  The full EAP-IKEv2 protocol run
+   consists of two roundtrips that are followed by either an EAP-Success
+   or an EAP-Failure message.  An optional roundtrip for exchanging EAP
+   identities may precede the two exchanges.
+
+
+
+Tschofenig, et al.            Experimental                      [Page 6]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   1. R<-I: EAP-Request/Identity
+
+   2. R->I: EAP-Response/Identity(Id)
+
+   3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
+
+   4. R->I: EAP-Res (HDR, SAr, KEr, Nr, [CERTREQ], [SK{IDr}])
+
+   5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH})
+
+   6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH})
+
+   7. R<-I: EAP-Success
+
+             Figure 1: EAP-IKEv2 Full, Successful Protocol Run
+
+   Figure 1 shows the full EAP-IKEv2 protocol run, including the
+   optional EAP identity exchange (messages 1 and 2).  A detailed
+   specification of the message composition follows.
+
+   Messages 1 and 2 are a standard EAP Identity Request and Response, as
+   defined in [2].  Message 3 is the first EAP-IKEv2-specific message.
+   With this, the server starts the actual EAP authentication exchange.
+   It contains the initiator Security Parameter Index (SPI) in the EAP-
+   IKEv2 header (HDR) (the initiator selects a new SPI for each protocol
+   run), the set of cryptographic algorithms the server is willing to
+   accept for the protection of EAP-IKEv2 traffic (encryption and
+   integrity protection), and the derivation of the session key.  This
+   set is encoded in the Security Association payload (SAi).  It also
+   contains a Diffie-Hellman payload (KEi), and a Nonce payload (Ni).
+
+   When the peer receives message 3, it selects a set of cryptographic
+   algorithms from the ones that are proposed in the message.  In this
+   overview, it is assumed that an acceptable such set exists (and is
+   thus selected), and that the Diffie-Hellman value KEi belongs to an
+   acceptable group.  The peer then generates a non-zero Responder SPI
+   value for this protocol run, its own Diffie-Hellman value (KEr) and
+   nonce (Nr), and calculates the keys SKEYSEED, SK_d, SK_ai, SK_ar,
+   SK_ei, SK_er, SK_pi, and SK_pr, according to Section 2.14 of [1].
+   The peer then constructs message 4.  In the context of use cases 1,
+   2, and 3, the peer's local policy MAY dictate the inclusion of the
+   optional CERTREQ payload in that message, which gives a hint to the
+   server to include a certificate for its public key in its next
+   message.  In the context of use case 4, the peer MUST include the
+   optional SK{IDr} payload, which contains its EAP-IKEv2 identifier,
+   encrypted and integrity-protected within an Encrypted payload.  The
+   keys used to construct this Encrypted payload are SK_er (for
+   encryption) and SK_ar (for integrity protection), in accordance with
+
+
+
+Tschofenig, et al.            Experimental                      [Page 7]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   [1].  The responder's EAP-IKEv2 identifier (IDr) is likely to be
+   needed in these use cases by the server in order to select the
+   correct symmetric key or password for the construction of the AUTH
+   payload of message 5.
+
+   Upon reception of message 4, the server also computes SKEYSEED, SK_d,
+   SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, according to Section
+   2.14 of [1].  If an SK{IDr} payload is included, the server decrypts
+   it and verifies its integrity with the corresponding keys.  In this
+   overview, decryption and verification is assumed to succeed.  The
+   server then constructs message 5, which contains only the EAP-IKEv2
+   header followed by a single Encrypted payload.  The keys used to
+   generate the encrypted payload MUST be SK_ei (for encryption) and
+   SK_ai (for integrity protection), in accordance with [1].  The
+   initiator MUST embed at least two payloads in the Encrypted Payload,
+   as follows.  An Identification payload with the initiator's EAP-IKEv2
+   identifier MUST be embedded in the Encrypted payload.  The
+   Authentication payload MUST be embedded in the Encrypted payload.  A
+   Certificate payload, and/or a Certificate Request payload, MAY also
+   be embedded in the Encrypted payload.  Moreover, a Next Fast-
+   Reconnect Identifier payload MAY also be embedded in the Encrypted
+   payload.  Message 5 is sent to the responder.
+
+   Upon reception of message 5, the responder (EAP peer) authenticates
+   the initiator (EAP server).  The checks that are performed to this
+   end depend on the use case, local policies, and are specified in [1].
+   These checks include (but may not be limited to) decrypting the
+   Encrypted payload, verifying its integrity, and checking that the
+   Authentication payload contains the expected value.  If all checks
+   succeed (which is assumed in this overview), then the responder
+   constructs message 6.  That message MUST contain the EAP-IKEv2 header
+   followed by a single Encrypted payload, in which at least two further
+   payloads MUST be embedded, as shown in Figure 1.
+
+   Upon reception of message 6, the initiator (EAP server) authenticates
+   the responder (EAP peer).  As above, the checks that are performed to
+   this end depend on the use case, local policies, and MUST include
+   decryption and verification of the Encrypted payload, as well as
+   checking that the Authentication payload contains the expected value.
+   If the optional SK{IDr} payload was included in message 4, the EAP
+   server MUST also ensure that the IDr payload in message 6 is
+   identical to that in message 4.
+
+   If authentication succeeds, an EAP-Success message is sent to the
+   responder as message 7.  The EAP server and the EAP peer generate a
+   Master Session Key (MSK) and an Extended Master Session Key (EMSK)
+   after a successful EAP-IKEv2 protocol run, according to Section 5.
+
+
+
+
+Tschofenig, et al.            Experimental                      [Page 8]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+4.  Fast Reconnect
+
+   This section specifies a "fast reconnect" mode of operation for EAP-
+   IKEv2.  This mode is mandatory to implement, but optional to use.
+   The purpose of fast reconnect is to enable an efficient re-
+   authentication procedure that also results in a fresh MSK and EMSK.
+   The "fast reconnect" mode can only be used where an EAP-IKEv2
+   security context already exists at both the server and the peer, and
+   its usage is subject to the local policies.  In other words, it can
+   only be used by an EAP server/EAP peer pair that has already
+   performed mutual authentication in a previous EAP-IKEv2 protocol run.
+
+   The fast reconnect mode makes use of dedicated "fast reconnect EAP
+   identifiers".  The idea is that the server indicates its willingness
+   to engage in "fast reconnect" protocol runs in the future by
+   including the optional "Next Fast-ID" (NFID) payload in message 5 of
+   a "full" protocol run (see Figure 1), or in message 3 of a "fast
+   reconnect" protocol run (see Figure 2).  This NFID payload contains a
+   special EAP identity, denoted Fast Reconnect Identity (FRID) as the
+   Network Access Identifier (NAI) in the EAP-Response/Identity message.
+   The FRID contains an obfuscated username part and a realm part.  When
+   generating a FRID, the following aspects should be considered:
+
+      The FRID and therefore the pseudonym usernames are generated by
+      the EAP server.  The EAP server produces pseudonym usernames in an
+      implementation-dependent manner.  Only the EAP server needs to be
+      able to map the pseudonym username to the permanent identity.
+
+      EAP-IKEv2 includes no provisions to ensure that the same EAP
+      server that generated a pseudonym username will be used on the
+      authentication exchange when the pseudonym username is used.  It
+      is recommended that the EAP servers implement some centralized
+      mechanism to allow all EAP servers of the home operator to map
+      pseudonyms generated by other severs to the permanent identity.
+      If no such mechanism is available, then the EAP server, failing to
+      understand a pseudonym issued by another server, can request the
+      peer to send the permanent identity.
+
+      When generating FRIDs, the server SHOULD choose a fresh and unique
+      FRID that is different from the previous ones that were used after
+      the same full authentication exchange.  The FRID SHOULD include a
+      random component in the username part.  The random component works
+      as a reference to the security context.  Regardless of the
+      construction method, the pseudonym username MUST conform to the
+      grammar specified for the username portion of an NAI.  Also, the
+      FRID MUST conform to the NAI grammar [4].  The EAP servers, which
+      subscribers of an operator can use, MUST ensure that the username
+      part of a FRIDs that they generate are unique.
+
+
+
+Tschofenig, et al.            Experimental                      [Page 9]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   The peer MAY use the FRID to indicate to start a "fast reconnect"
+   protocol run.  The EAP Identity Response MUST be sent at the
+   beginning of a "fast reconnect" protocol run.  If, in the previous
+   successful "full" (resp. "fast reconnect") EAP-IKEv2 protocol
+   execution, the server had not included an NFID payload in message 5
+   (resp. 3), then the peer MUST NOT start a fast reconnect protocol
+   run.  On reception of FRID, the server maps it to an existing EAP-
+   IKEv2 security context.  Depending on local policy, the server either
+   proceeds with the "fast reconnect" protocol run, or proceeds with
+   message 3 of a "full" protocol run.  If the server had advertised the
+   FRID in the previous EAP-IKEv2 protocol execution, it SHOULD proceed
+   with a "fast reconnect" protocol run.  The peer MUST be able to
+   correctly handle a message 3 of a "full" protocol run, even if it
+   indicated a FRID in its EAP Identity Response.
+
+   Because the peer may fail to save a FRID that was sent in the NFID
+   payload (for example, due to malfunction), the EAP server SHOULD
+   maintain, at least, the most recently used FRID in addition to the
+   most recently issued FRID.  If the authentication exchange is not
+   completed successfully, then the server MUST NOT overwrite the FRID
+   that was issued during the most recent successful authentication
+   exchange.
+
+   The EAP-IKEv2 fast reconnect exchange is similar to the IKE-SA
+   rekeying procedure, as specified in Section 2.18 of [1].  Thus, it
+   uses a CREATE_CHILD_SA request and response.  The SPIs on those two
+   messages would be the SPIs negotiated on the previous exchange.
+   During fast reconnect, the server and the peer MAY exchange fresh
+   Diffie-Hellman values.
+
+   1. R<-I: EAP-Request/Identity
+
+   2. R->I: EAP-Response/Identity(FRID)
+
+   3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi], [NFID]})
+
+   4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]})
+
+   5. R<-I: EAP-Success
+
+                   Figure 2: Fast Reconnect Protocol Run
+
+   Figure 2 shows the message exchange for the EAP-IKEv2 fast reconnect
+   mode.  As in the full mode, the EAP server is the initiator and the
+   EAP peer is the responder.  The first two messages constitute the
+   standard EAP identity exchange.  Note that, in order to use the "fast
+   reconnect" mode, message 2 MUST be sent.  This is in order to enable
+   the peer to indicate its "fast reconnect" identity FRID in message 2.
+
+
+
+Tschofenig, et al.            Experimental                     [Page 10]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   If the server can map the FRID to an existing EAP-IKEv2 context it
+   proceeds with message 3.  Note that, in this message, the server MAY
+   embed an NFID payload into the encrypted payload to provide a new
+   FRID to the peer.  The server MAY choose to perform a full EAP-IKEv2
+   run, in which case, it would respond with a message that conforms to
+   the format of message 3 in Figure 1.
+
+   Messages 3 and 4 establish a new EAP-IKEv2 security context.  In
+   message 3, the initiator MUST select a new (non-zero) value for the
+   SPI field in each proposal substructure in the SA payload (see
+   Section 3.3 of [1]).  The value of the IKE_SA Responder's SPI field
+   in HDR MUST be the one from the previous successful EAP-IKEv2
+   protocol run.  The nonce inside the Nonce payload (Ni) MUST be fresh,
+   and the Diffie-Hellman value inside the Diffie-Hellman payload (if
+   present, KEi) MUST also be fresh.  If present, the Diffie-Hellman
+   value MUST be drawn from the same group as the Diffie-Hellman value
+   in the previous successful full EAP-IKEv2 protocol run.  Note that
+   the algorithms and keys that are used to construct the Encrypted
+   payload in message 3 are the same as in the previous successful EAP-
+   IKEv2 protocol run.
+
+   Upon reception of message 3, the responder (EAP peer) decrypts and
+   verifies the Encrypted payload.  If successful (as assumed in Figure
+   2), it constructs message 4 in a fashion similar to the construction
+   of message 3.  The responder MUST choose a new (non-zero) value for
+   the SPI field in each proposal substructure.  Upon reception of
+   message 4, the initiator (EAP server) decrypts and verifies the
+   Encrypted payload.  If a correct message 4 is received, then this
+   protocol run is deemed successful, and the server responds with an
+   EAP-Success message (message 5).
+
+   After successful EAP-IKEv2 fast reconnect protocol run, both the
+   initiator and the responder generate fresh keying material that is
+   used for the protection of subsequent EAP-IKEv2 traffic.
+   Furthermore, both the initiator and the responder MUST generate a
+   fresh MSK and EMSK and export them.
+
+   The new EAP-IKEv2-specific keying material is computed in the same
+   way as in the full EAP-IKEv2 protocol run, and in accordance with
+   Section 2.18 of [1].  That is, SKEYSEED is computed as SKEYSEED =
+   prf(SK_d (old), [g^ir (new)] | Ni | Nr), where SK_d (old) is the key
+   SK_d from the previous successful EAP-IKEv2 protocol run, Ni and Nr
+   are the nonces (without the Nonce payload headers) that were
+   exchanged in messages 3 and 4, and g^ir (new) is the newly computed
+   Diffie-Hellman key, if both the values KEi and KEr were present in
+   messages 3 and 4.  The remaining EAP-IKEv2-specific keys (SK_d,
+   SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr) are generated as in the
+   full EAP-IKEv2 protocol run.
+
+
+
+Tschofenig, et al.            Experimental                     [Page 11]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   The generation of a fresh MSK and EMSK follows the generation of the
+   EAP-IKEv2-specific keys and adheres to the rules in Section 5.
+
+   Note 1: In EAP-IKEv2, the EAP server initiates the fast reconnect
+   mode and thereby causes fresh session keys to be established.
+
+   Note 2: It is conceivable that an adversary tries to launch a replay
+   attack against the EAP-IKEv2 fast reconnect mode of operation.  In
+   particular, the adversary may try to send a previously captured
+   message 3 in a subsequent fast reconnect protocol run.  This replay
+   attempt will, however, fail because the keys that the responder will
+   use to verify and decrypt the Encrypted payload are changed with
+   every successful reconnect protocol run.
+
+5.  Key Derivation
+
+   This section describes how the Master Session Key (MSK) and the
+   Extended Master Session Key (EMSK) are derived in EAP-IKEv2.  It is
+   expected that the MSK and the EMSK are exported by the EAP-IKEv2
+   process and be used in accordance with the EAP keying framework [7].
+
+   During an EAP-IKEv2 protocol run, the initiator and the responder
+   generate a number of keys, as described above and in accordance with
+   Section 2.14 of [1].  The generation of these keys is based on a
+   pseudorandom function (prf) that both parties have agreed to use and
+   that is applied in an iterative fashion.  This iterative fashion is
+   specified in Section 2.13 of [1] and is denoted by prf+.
+
+   In particular, following a successful EAP-IKEv2 protocol run, both
+   parties generate 128 octets of keying material, denoted KEYMAT, as
+   KEYMAT = prf+(SK_d, Ni | Nr), where Ni and Nr are the nonces (just
+   payload without headers) from messages 3 and 4 shown in Figure 1 (in
+   the context of a full EAP-IKEv2 protocol run) or Figure 2 (in the
+   context of a fast reconnect EAP-IKEv2 protocol run).  Note that only
+   the nonces are used, i.e., not the entire Nonce payload that contains
+   them.
+
+   The first 64 octets of KEYMAT are exported as the EAP MSK, and the
+   second 64 octets are exported as the EMSK.
+
+   The MSK and EMSK MUST NOT be generated unless an EAP-IKEv2 protocol
+   run completes successfully.  Note that the EAP-IKEv2 method does not
+   produce an initialisation vector [7].
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 12]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+6.  Session ID, Peer ID, and Server ID
+
+   The EAP key management framework [7] requires that EAP methods export
+   three information elements, called the Session-ID, the Peer-ID, and
+   the Server-ID.  In EAP-IKEv2, these elements are derived as follows:
+
+   o  The Session-ID is constructed and exported as the concatenation of
+      the following three elements, in this order: (a) the EAP Code Type
+      for EAP-IKEv2 (to be defined by IANA), (b) the contents of the
+      Nonce Data field of the Nonce Payload Ni from message 3, (c) the
+      contents of the Nonce Data field of the Nonce Payload Nr from
+      message 4.
+
+   o  In case of a full EAP-IKEv2 protocol run, the Peer-ID is
+      constructed and exported as the content of the Identification Data
+      field of the Identification Payload IDr from message 6.  Note that
+      only the "actual" identification data is exported, as indicated in
+      the Payload Length field; if the Identification Data field
+      contains any padding, this padding is ignored.  In case of a "fast
+      reconnect" protocol run, the Peer-ID field is constructed in
+      exactly the same manner, where message 6 refers to the full EAP-
+      IKEv2 protocol run that originally established the security
+      context between the EAP peer and EAP server.
+
+   o  In case of a full EAP-IKEv2 protocol run, the Server-ID is
+      constructed and exported as the contents of the Identification
+      Data field of the Identification Payload IDi from message 5.  Note
+      that only the "actual" identification data is exported, as
+      indicated in the Payload Length field; if the Identification Data
+      field contains any padding, this padding is ignored.  In case of a
+      "fast reconnect" protocol run, the Server-ID field is constructed
+      in exactly the same manner, where message 5 refers to the full
+      EAP-IKEv2 protocol run that originally established the security
+      context between the EAP peer and EAP server.
+
+7.  Error Handling
+
+   This section specifies how errors are handled within EAP-IKEv2.  For
+   conveying error information from one party to the other, the Notify
+   payload is defined and used (see Section 8.11).
+
+   If, in a full EAP-IKEv2 protocol run, authentication fails (i.e., the
+   verification of the AUTH field fails at the server or the peer), but
+   no other errors have occurred, the message flow deviates from that
+   described in Section 3.  The message flows in the presence of
+   authentication failures are specified in Appendix A.
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 13]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   If, in message 3 of a full EAP-IKEv2 protocol run (see Figure 1), the
+   responder receives a Diffie-Hellman value (KEi) that belongs to a
+   group that is not supported (and in the absence of other errors),
+   then the responder MUST send a message of the form shown in Figure 3
+   to the initiator.  This effectively becomes message 4 in the full
+   protocol run.
+
+   1. R<-I: EAP-Request/Identity
+
+   2. R->I: EAP-Response/Identity(Id)
+
+   3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
+
+   4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD))
+
+         Figure 3: Error Handling in Case of Unsupported D-H Value
+
+   The above message consists of the EAP-IKEv2 header and a Notification
+   payload with the value of the Notify Message Type field value set to
+   17 (INVALID_KE_PAYLOAD).  There is a two-octet value associated with
+   this notification: the number of the selected DH Group in big endian
+   order, as specified in Section 3.10.1 of [1].  This number MUST
+   represent a DH group that is supported by both the initiator and the
+   responder.
+
+   If, during a full EAP-IKEv2 protocol run (see Figure 1), the
+   initiator receives a message conforming to Figure 3 instead of the
+   usual message 4, then it MUST check whether or not the indicated DH
+   group was proposed in message 3.  If it was not, then the initiator
+   MUST silently discard the message.  Otherwise, the protocol continues
+   with a new message 3 that the initiator sends to the peer.  In this
+   new message 3, the initiator MUST use a Diffie-Hellman value that is
+   drawn from the group that is indicated in the Notify payload of
+   message 4 in Figure 3.
+
+   If, in the context of use case 4 and during a full EAP-IKEv2 protocol
+   run (see Figure 1), the initiator receives, in message 4, an SK{IDr}
+   payload that decrypts to a non-existent or unauthorised EAP-IKEv2
+   responder identifier IDr*, then the server SHOULD continue the
+   protocol with a message conforming to the format of message 5.  The
+   AUTH payload in that message SHOULD contain a value that is
+   computationally indistinguishable from a value that it would contain
+   if IDr* was valid and authorised.  This can be accomplished, for
+   example, by generating a random key and calculating AUTH as usual
+   (however, this document does not mandate a specific mechanism).  Only
+   after receiving message 6, the server SHOULD respond with an
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 14]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   authentication failure notification, i.e., a message conforming to
+   message 6 in Figure 10.  The purpose of this behaviour is to prevent
+   an adversary from probing the EAP-IKEv2 peer identifier space.
+
+   If, in the context of use cases 1, 2, or 3 and during a full EAP-
+   IKEv2 protocol run (see Figure 1), the initiator receives, in message
+   4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder
+   identifier IDr*, then the server MUST continue the protocol as usual
+   (note that such a payload would not be required in these use cases).
+   The server MUST compare IDr* with the IDr received in message 6 and,
+   in case of a mismatch, MUST respond with an authentication failure
+   notification, i.e., a message conforming to message 6 in Figure 10.
+   If no mismatch is detected, normal processing applies.
+
+   Other errors do not trigger messages with Notification payloads to be
+   sent, and MUST be treated as if nothing happened (i.e., the erroneous
+   EAP-IKEv2 packet MUST be silently discarded).  This includes
+   situations where at least one of the following conditions is met,
+   with respect to an incoming EAP-IKEv2 packet.
+
+   o  The packet contains an Encrypted payload that, when decrypted with
+      the appropriate key, yields an invalid decryption.
+
+   o  The packet contains an Encrypted payload with a Checksum field
+      that does not verify with the appropriate key.
+
+   o  The packet contains an Integrity Checksum Data field (see *Figure
+      4) that is incorrect.
+
+   o  The packet does not contain a compulsory field.
+
+   o  A field in the packet contains an invalid value (e.g., an invalid
+      combination of flags, a length field that is inconsistent with the
+      real length of the field or packet, or the responder's choice of a
+      cryptographic algorithm is different to NONE and any of those that
+      were offered by the initiator).
+
+   o  The packet contains an invalid combination of fields (e.g., it
+      contains two or more Notify payloads with the same Notify Message
+      Type value, or two or more Transform substructures with the same
+      Transform Type and Transform ID value).
+
+   o  The packet causes a defragmentation error.
+
+   o  The format of the packet is invalid.
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 15]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   o  The identity provided by the EAP peer in the EAP-Response/Identity
+      cannot be associated with either an established security context
+      (in case of a fast reconnect) or with a real user account (in case
+      of a full protocol exchange).  In that case, the packet is
+      silently discarded.  With an outstanding message from the EAP
+      server, the client may either retransmit the previous request or,
+      in case of a fast reconnect, assume that state information was
+      deleted (e.g., due to garbage collection) at the EAP server and
+      fall back to a previously used FRID or to the full protocol
+      exchange.
+
+   If an incoming packet contains an error for which a behaviour is
+   specified in this section, and an error that, in the absence of the
+   former error, would cause the packet to be silently discarded, then
+   the packet MUST be silently discarded.
+
+8.  Specification of Protocol Fields
+
+   In this section, the format of the EAP-IKEv2 data fields and
+   applicable processing rules are specified.  Figure 4 shows the
+   general packet format of EAP-IKEv2 messages, and the embedding of
+   EAP-IKEv2 into EAP.  The EAP-IKEv2 messages are embedded in the Data
+   field of the standard EAP Request/Response packets.  The Code,
+   Identifier, Length, and Type fields are described in [2].  The EAP
+   Type for this EAP method is 49.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Code      |   Identifier  |            Length             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |   Flags       |       Message Length          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       Message Length          |       HDR + payloads          ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    Integrity Checksum Data                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+               Figure 4: General Packet Format of EAP-IKEv2
+
+   The Flags field is always present and is used for fragmentation
+   support, as described in Section 8.1.  The Message Length field is
+   not always present; its presence is determined by a certain flag in
+   the Flags field, as described in Section 8.1.  The field denoted as
+   "HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see
+   Section 8.2), followed by the number of payloads, in accordance with
+   the composition of EAP-IKEv2 messages, as described in the previous
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 16]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   sections.  Note that each payload begins with a generic payload
+   header that is specified in Section 3.2 of [1].
+
+   The Integrity Checksum Data field is not always present; its presence
+   is determined by a certain flag in the Flags field, as described in
+   Section 8.1.
+
+   In the remainder of this section, the protocol fields that are used
+   in EAP-IKEv2 are specified.  This specification heavily relies on the
+   IKEv2 specification [1], and many fields are constructed, formatted,
+   and processed in way that is almost identical to that in IKEv2.
+   However, certain deviations from standard IKEv2 formatting and
+   processing exist.  These deviations are highlighted in the remainder
+   of this section.
+
+8.1.  The Flags, Message Length, and Integrity Checksum Data Fields
+
+   This section describes EAP-IKEv2 fragmentation, and specifies the
+   encoding and processing rules for the Flags, Message Length, and
+   Integrity Checksum Data field shown in Figure 4.
+
+   Fragmentation support in EAP-IKEv2 is provided by the Flags and
+   Message Length fields shown in Figure 4.  These are encoded and used
+   as follows:
+
+    0 1 2 3 4 5 6 7
+   +-+-+-+-+-+-+-+-+
+   |L M I 0 0 0 0 0|
+   +-+-+-+-+-+-+-+-+
+
+   L = Length included
+   M = More fragments
+   I = Integrity Checksum Data included
+
+                           Figure 5: Flags Field
+
+   The Flags field is defined in Figure 5.  Only the first three bits
+   (0-2) are used; all remaining bits MUST be set to zero and ignored on
+   receipt.  The L flag indicates the presence of a Message Length
+   field, and the M flag indicates whether or not the current EAP
+   message has more fragments.  In particular, if the L bit is set, then
+   a Message Length field MUST be present in the EAP message, as shown
+   in Figure 4.  The Message Length field is four octets long and
+   contains the length of the entire message (i.e., the length of the
+   EAP Data field.).  Note that, in contrast, the Length field shown in
+   Figure 4 contains the length of only the current fragment.  (Note
+   that there exist two fields that are related to length: the Length
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 17]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   field, which is a generic EAP field, and the Message Length field,
+   which is an EAP-IKEv2-specific field.)  If the L bit is not set, then
+   the Message Length field MUST NOT be present.
+
+   The M flag MUST be set on all fragments except the last one.  In the
+   last fragment, the M flag MUST NOT be set.  Reliable fragment
+   delivery is provided by the retransmission mechanism of EAP as
+   described below.
+
+   When an EAP-IKEv2 peer receives an EAP-Request packet with the M bit
+   set, it MUST respond with an EAP-Response with EAP-Type=EAP-IKEv2 and
+   no data.  This serves as a fragment ACK.  The EAP server MUST wait
+   until it receives the EAP-Response before sending another fragment.
+   In order to prevent errors in processing of fragments, the EAP server
+   MUST increment the Identifier field for each fragment contained
+   within an EAP-Request, and the peer MUST include this Identifier
+   value in the fragment ACK contained within the EAP-Response.
+   Retransmitted fragments will contain the same Identifier value.
+
+   Similarly, when the EAP server receives an EAP-Response with the M
+   bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-IKEv2
+   and no data.  This serves as a fragment ACK. The EAP peer MUST wait
+   until it receives the EAP-Request before sending another fragment.
+   In order to prevent errors in the processing of fragments, the EAP
+   server MUST increment the Identifier value for each fragment ACK
+   contained within an EAP-Request, and the peer MUST include this
+   Identifier value in the subsequent fragment contained within an EAP-
+   Response.
+
+   The Integrity Checksum Data field contains a cryptographic checksum
+   that covers the entire EAP message, starting with the Code field, and
+   ending at the end of the EAP Data field.  This field, shown in Figure
+   4, is present only if the I bit is set in the Flags field.  The
+   Integrity Checksum Data field immediately follows the EAP Data field
+   without padding.
+
+   Whenever possible, the Integrity Checksum Data field MUST be present
+   (and the I bit set) for each fragment, including the case where the
+   entire EAP-IKEv2 message is carried in a single fragment.  The
+   algorithm and keys that are used to compute the Integrity Checksum
+   Data field MUST be identical to those used to compute the Integrity
+   Checksum Data field of the Encrypted Payload (see Section 8.9).  That
+   is, the algorithm and keys that were negotiated and established
+   during this EAP-IKEv2 protocol run are used.  Note that this means
+   that different keys are used to compute the Integrity Checksum Data
+   field in each direction.  Also note that, for messages where this
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 18]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   algorithm and the keys are not yet established, the Integrity
+   Checksum Data field cannot be computed and is therefore not included.
+   This applies, for example, to messages 3 and 4 in Figure 1.
+
+   In order to minimize the exposure to denial-of-service attacks on
+   fragmented packets, messages that are not protected with an Integrity
+   Checksum Data field SHOULD NOT be fragmented.  Note, however, that
+   those packets are not likely to be fragmented anyway since they do
+   not carry certificates.
+
+8.2.  EAP-IKEv2 Header
+
+   The EAP-IKEv2 header, denoted HDR in this specification, is
+   constructed and formatted according to the rules specified in Section
+   3.1 of [1].
+
+   In the first EAP-IKEv2 message that is sent by the initiator (message
+   3 in Figure 1), the IKE_SA Responder's SPI field is set to zero.
+   This is because, at this point in time, the initiator does not know
+   what SPI value the responder will choose for this protocol run.  In
+   all other messages, both SPI fields MUST contain non-zero values that
+   reflect the initiator- and responder-chosen SPI values.
+
+   In accordance with [1], for this version of EAP-IKEv2, the MjVer
+   (major version) and MnVer (minor version) fields in the header MUST
+   be 2 and 0 respectively.  The value of the Exchange Type field MUST
+   be set to 34 (IKE_SA_INIT) in messages 3 and 4, and to 35
+   (IKE_SA_AUTH) in messages 5 and 6 in Figure 1.  In messages 3 and 4
+   in Figure 2, this value MUST be set to 36 (CREATE_CHILD_SA).
+
+   The Flags field of the EAP-IKEv2 header is also constructed according
+   to Section 3.1 of [1].  Note that this is not the same field as the
+   Flags field shown in Figure 4.
+
+   The Message ID field is constructed as follows.  Messages 3 and 4 in
+   a full protocol run MUST carry Message ID value 0.  Messages 5 and 6
+   in a full protocol run (see Figure 1) MUST carry Message ID value 1.
+   Messages 3 and 4 in a fast reconnect protocol run MUST carry Message
+   ID value 2.
+
+8.3.  Security Association Payload
+
+   The SA payload is used for the negotiation of cryptographic
+   algorithms between the initiator and the responder.  The rules for
+   its construction adhere to [1]; in particular, Sections 2.7 and 3.3.
+
+   In EAP-IKEv2, all Proposal Substructures in the SA payload MUST carry
+   Protocol ID value 1 (IKE).
+
+
+
+Tschofenig, et al.            Experimental                     [Page 19]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+8.4.  Key Exchange Payload
+
+   The Key Exchange payload, denoted KEi if constructed by the initiator
+   and KEr if constructed by the responder, is formatted according to
+   the rules specified in Section 3.4 of [1].
+
+8.5.  Nonce Payload
+
+   The Nonce payload, denoted Ni if constructed by the initiator and Nr
+   if constructed by the responder, is constructed and formatted
+   according to the rules specified in Section 3.9 of [1].
+
+8.6.  Identification Payload
+
+   The Identification payload, denoted IDi if it contains an identifier
+   for the initiator and IDr if it contains an identifier for the
+   responder, is constructed and formatted according to the rules
+   specified in Section 3.5 of [1].
+
+8.7.  Certificate Payload
+
+   The Certificate payload, denoted CERT, is constructed and formatted
+   according to the rules specified in Section 3.6 of [1].  Note that
+   certain certificate encodings for the EAP server certificate, e.g.,
+   those that need to be resolved via another network protocol, cannot
+   be used in some typical EAP-IKEv2 deployment scenarios.  A user, for
+   example, that authenticates himself by means of EAP-IKEv2 in order to
+   obtain network access, cannot resolve the server certificate at the
+   time of EAP-IKEv2 protocol execution.
+
+8.8.  Certificate Request Payload
+
+   The Certificate Request payload, denoted CERTREQ, is constructed and
+   formatted according to the rules specified in Section 3.7 of [1].
+
+8.9.  Encrypted Payload
+
+   The Encrypted payload, denoted SK{...}, is constructed and formatted
+   according to the rules specified in Section 3.14 of [1].
+
+8.10.  Authentication Payload
+
+   The Authentication payload, denoted AUTH, is constructed and
+   formatted according to the rules specified in Sections 2.15 and 3.8
+   of [1].
+
+   The contents of the Authentication payload depend on which party
+   generates this field, the use case, and the algorithm that
+
+
+
+Tschofenig, et al.            Experimental                     [Page 20]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   corresponds to the credential (asymmetric key, symmetric key, or
+   password) that this party uses to authenticate itself.  The
+   Authentication payload contains either a MAC or a signature.
+
+   If the party that generates the Authentication payload authenticates
+   itself based on a shared secret (i.e., a password or a symmetric
+   key), then the Authentication payload MUST contain a MAC.  This MAC
+   is calculated using a key that is derived from the shared secret,
+   according to Section 2.15 of [1].  According to that section, the
+   shared secret is padded with the string "Key Pad for IKEv2" as part
+   of this key derivation.  For the EAP-IKEv2 method, this rule is
+   overridden, in that the padding string is redefined as "Key Pad for
+   EAP-IKEv2".  The latter padding string MUST be used for the
+   derivation of the MAC key from a shared secret in the context of EAP-
+   IKEv2.  This is done in order to avoid the same MAC key to be used
+   for both IKEv2 and EAP-IKEv2 in scenarios where the same shared
+   secret is used for both.  Note that using a shared secret (e.g., a
+   password) in the context EAP-IKEv2 that is identical or similar to a
+   shared secret that is used in another context (including IKEv2) is
+   nevertheless NOT RECOMMENDED.
+
+8.11.  Notify Payload
+
+   The Notify payload, denoted N(...), is constructed and formatted
+   according to the rules specified in Section 3.10 of [1].  The
+   Protocol ID field of this payload MUST be set to 1 (IKE_SA).
+
+8.12.  Next Fast-ID Payload
+
+   The Next Fast-ID 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        !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                                                               !
+      ~                     Fast-Reconnect-ID (FRID)                  ~
+      !                                                               !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 6: NFID Payload Format
+
+   The Next Fast-ID payload, denoted NFID, does not have an equivalent
+   in IKEv2.  Nevertheless, the Next Payload, C, RESERVED, and Payload
+   Length fields of this payload are constructed according to Section
+   3.2 of [1].  The payload ID is registered in Section 11.  The Fast-
+   Reconnect-ID field contains a fast reconnect identifier that the peer
+
+
+
+Tschofenig, et al.            Experimental                     [Page 21]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   can use in the next fast reconnect protocol run, as described in
+   Section 4.  In environments where a realm portion is required, Fast-
+   Reconnect-ID includes both a username portion and a realm name
+   portion.  The Fast-Reconnect-ID MUST NOT include any terminating null
+   characters.  The encoding of the Fast-Reconnect-ID field MUST follow
+   the NAI format [4].
+
+9.  Payload Types and Extensibility
+
+   In EAP-IKEv2, each payload is identified by means of a type field,
+   which, as specified in [1], is indicated in the "Next Payload" field
+   of the preceding payload.  However, the identifier space from which
+   EAP-IKEv2 payload types are drawn is independent from the payload
+   type space of IKEv2.  This is because EAP-IKEv2 and IKEv2 may evolve
+   in a different way and, as such, payload types that appear in one
+   protocol do not necessary appear in the other.  An example of this is
+   the "Next Fast-ID" (NFID) payload, which does not exist in IKEv2.
+
+   The values for the payload types defined in this document are listed
+   in Section 11.  Payload type values 13-127 are reserved to IANA for
+   future assignment in EAP-IKEv2.  Payload type values 128-255 are for
+   private use among mutually consenting parties.
+
+10.  Security Considerations
+
+   As mentioned in Section 3, in EAP-IKEv2, the EAP server always
+   assumes the role of the initiator (I), and the EAP peer takes on the
+   role of the responder (R) of an exchange.  This is in order to ensure
+   that, in scenarios where the peer authenticates itself based on a
+   password (i.e., in use case 3), operations that involve this password
+   only take place after the server has been successfully authenticated.
+   In other words, this assignment of initiator and responder roles
+   results in protection against offline dictionary attacks on the
+   password that is used by the peer to authenticate itself (see Section
+   10.7).
+
+   In order for two EAP-IKEv2 implementations to be interoperable, they
+   must support at least one common set of cryptographic algorithms.  In
+   order to promote interoperability, EAP-IKEv2 implementations MUST
+   support the following algorithms based on the "MUST/MUST-"
+   recommendations given in [5]:
+
+      Diffie-Hellman Groups: 1024 MODP Group
+      IKEv2 Transform Type 1 Algorithms: ENCR_3DES
+      IKEv2 Transform Type 2 Algorithms: PRF_HMAC_SHA1
+      IKEv2 Transform Type 3 Algorithms: AUTH_HMAC_SHA1_96
+
+   All other options of [5] MAY be implemented.
+
+
+
+Tschofenig, et al.            Experimental                     [Page 22]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   The remainder of this section describes EAP-IKEv2 in terms of
+   specific security terminology as required by [2].  The discussion
+   makes reference to the use cases defined in Section 1.
+
+10.1.  Protected Ciphersuite Negotiation
+
+   In message 3, the EAP server provides the set of ciphersuites it is
+   willing to accept in an EAP-IKEv2 protocol run.  Hence, the server is
+   in control of the ciphersuite.  An EAP peer that does not support any
+   of the indicated ciphersuites is not able to authenticate.  The local
+   security policy of the peer MUST specify the set of ciphersuites that
+   the peer accepts.  The server MUST verify that the ciphersuite that
+   is indicated as being chosen by the peer in message 4, belongs to the
+   set of ciphersuites that were offered in message 3.  If this
+   verification fails, the server MUST silently discard the packet.
+
+10.2.  Mutual Authentication
+
+   EAP-IKEv2 supports mutual authentication.
+
+10.3.  Integrity Protection
+
+   EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic.  This
+   protection is offered after authentication is completed and it is
+   facilitated by inclusion of two Integrity Checksum Data fields: one
+   at the end of the EAP packet (see Figure 4), and one as part of an
+   Encrypted payload (see Section 8.9).
+
+10.4.  Replay Protection
+
+   EAP-IKEv2 provides protection against replay attacks by a variety of
+   means.  This includes the requirement that the Authentication payload
+   is computed as a function of, among other things, a server-provided
+   nonce and a peer-provided nonce.  These nonces are required to be
+   practically unpredictable by an adversary.  Assuming that the
+   algorithm that is used to compute the Authentication payload does not
+   contain cryptographic weaknesses, the probability that an
+   Authentication payload that is valid in a particular protocol run
+   will also be valid in a subsequent run is therefore negligible.
+
+10.5.  Confidentiality
+
+   EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields,
+   namely those included in Encrypted payloads.  With respect to
+   identity confidentiality, the following claims are made.  Note that
+   identity confidentiality refers to the EAP-IKEv2 identity of the EAP
+   peer.
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 23]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   Identity confidentiality is provided in the face of a passive
+   adversary, i.e., an adversary that does not modify traffic as it is
+   in transit.  Whenever the optional SK{IDr} payload in message 4 of a
+   full EAP-IKEv2 protocol (see Figure 1) is not included, identity
+   confidentiality is also provided in the face of an active adversary.
+   This payload MUST NOT be included in use cases 1, 2, and 3.  In use
+   case 4, this payload MUST be included.  Therefore, in use case 4,
+   EAP- IKEv2 does not provide identity confidentiality in the face of
+   an active adversary.
+
+   Note, however, that the EAP peer provides its identity in message 2
+   in Figure 1 in cleartext.  In order to provide identity
+   confidentiality as discussed in the previous paragraphs, it is
+   necessary to obfuscate the username part of the identity (the realm
+   part must stay intact to allow correct message routing by the
+   Authentication, Authorization, and Accounting (AAA) infrastructure).
+   The EAP server then uses the identity information in message 4.  The
+   same mechanism is also used by other EAP methods to provide identity
+   confidentiality, for example, EAP-TTLS [8].
+
+10.6.  Key Strength
+
+   EAP-IKEv2 supports the establishment of session keys (MSK and EMSK)
+   of a variety of key strengths, with the theoretical maximum at 512
+   bits per key (since this is the size of the MSK and the EMSK).
+   However, in practice, the effective key strength is likely to be
+   significantly lower, and depends on the authentication credentials
+   used, the negotiated ciphersuite (including the output size of the
+   pseudorandom function), the Diffie-Hellman group used, and on the
+   extent to which the assumptions on which the underlying cryptographic
+   algorithms depend really hold.  Of the above mechanisms, the one that
+   offers the lowest key strength can be regarded as a measure of the
+   effective key strength of the resulting session keys.  Note that this
+   holds for other EAP methods, too.
+
+   Due to the large variety of possible combinations, no indication of a
+   practical effective key strength for MSK or EMSK is given here.
+   However, those responsible for the deployment of EAP-IKEv2 in a
+   particular environment should consider the threats this environment
+   may be exposed to, and configure the EAP-IKEv2 server and peer
+   policies and authentication credentials such that the established
+   session keys are of a sufficiently high effective key strength.
+
+10.7.  Dictionary Attack Resistance
+
+   EAP-IKEv2 can be used in a variety of use cases, as explained in
+   Section 1.  In some of these uses cases, namely use case 1, 2, and 4,
+   dictionary attacks cannot be launched since no passwords are used.
+
+
+
+Tschofenig, et al.            Experimental                     [Page 24]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   In use case 3, EAP-IKEv2 provides protection against offline
+   dictionary attacks, since operations that involve the password are
+   executed only after the server has authenticated itself (based on a
+   credential other than a password).
+
+   In order to reduce exposure against online dictionary attacks, in use
+   case 3, the server SHOULD provide the capability to log failed peer
+   authentication events, and SHOULD implement a suitable policy in case
+   of consecutive failed peer authentication attempts within a short
+   period of time (such as responding with an EAP-Failure instead of
+   message 5 for a predetermined amount of time).
+
+   When passwords are used with method 4 (instead of using a key with
+   high entropy), dictionary attacks are possible, as described in
+   Section 8 of [1]:
+
+      "When using pre-shared keys, a critical consideration is how to
+      assure the randomness of these secrets.  The strongest practice is
+      to ensure that any pre-shared key contain as much randomness as
+      the strongest key being negotiated.  Deriving a shared secret from
+      a password, name, or other low-entropy source is not secure.
+      These sources are subject to dictionary and social engineering
+      attacks, among others."
+
+   Hence, the usage of passwords with mode 4 where the EAP peer and the
+   EAP server rely on a shared secret that was derived from a password
+   is insecure.  It is strongly recommended to use mode 3 when passwords
+   are used by the EAP peer.
+
+10.8.  Fast Reconnect
+
+   EAP-IKEv2 supports a "fast reconnect" mode of operation, as described
+   in Section 4.
+
+10.9.  Cryptographic Binding
+
+   EAP-IKEv2 is not a tunnel EAP method.  Thus, cryptographic binding
+   does not apply to EAP-IKEv2.
+
+10.10.  Session Independence
+
+   EAP-IKEv2 provides session independence in a number of ways, as
+   follows:
+
+   Firstly, knowledge of captured EAP-IKEv2 conversations (i.e., the
+   information that a passive adversary may obtain) does not enable the
+   adversary to compute the Master Session Key (MSK) and Extended Master
+   Session Key (EMSK) that resulted from these conversations.  This
+
+
+
+Tschofenig, et al.            Experimental                     [Page 25]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   holds even in the case where the adversary later obtains access to
+   the server and/or the peer's long-term authentication credentials
+   that were used in these conversations.  That is, EAP-IKEv2 provides
+   support for "perfect forward secrecy".  However, whether or not this
+   support is made use of in a particular EAP-IKEv2 protocol run,
+   depends on when the peer and the server delete the Diffie-Hellman
+   values that they used in that run, and on whether or not they use
+   fresh Diffie-Hellman values in each protocol run.  The discussion in
+   Section 2.12 of [1] applies.
+
+   Secondly, an active adversary that does not know the peer's and
+   server's long-term authentication credentials cannot learn the MSK
+   and EMSK that were established in a particular protocol run of EAP-
+   IKEv2, even if it obtains access to the MSK and EMSK that were
+   established in other protocol runs of EAP-IKEv2.  This is because the
+   MSK and the EMSK are a function of, among other things, data items
+   that are assumed to be generated independently at random in each
+   protocol run.
+
+10.11.  Fragmentation
+
+   EAP-IKEv2 provides support for fragmentation, as described in Section
+   8.1.
+
+10.12.  Channel Binding
+
+   Channel binding is not supported in EAP-IKEv2.
+
+10.13.  Summary
+
+   EAP security claims are defined in Section 7.2.1 of [2].  The
+   security claims for EAP-IKEv2 are as follows:
+
+               Ciphersuite negotiation:   Yes
+               Mutual authentication:     Yes
+               Integrity protection:      Yes
+               Replay protection:         Yes
+               Confidentiality:           Yes
+               Key derivation:            Yes; see Section 5
+               Key strength:              Variable
+               Dictionary attack prot.:   Yes; see Section 10.7
+               Fast reconnect:            Yes; see Section 4
+               Crypt. binding:            N/A
+               Session independence:      Yes; see Section 10.10
+               Fragmentation:             Yes; see Section 10.11
+               Channel binding:           No
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 26]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+11.  IANA Considerations
+
+   IANA has allocated value 49 for the EAP method type indicating EAP-
+   IKEv2.  EAP-IKEv2 has already earlier successfully passed Designated
+   Expert Review as mandated by RFC 3748 for IANA allocations.
+
+   In addition, IANA has created a new registry for "EAP-IKEv2
+   Payloads", and populated it with the following initial entries listed
+   below.
+
+   The following payload type values are used by this document.
+
+  Next Payload Type                 | Value
+  ----------------------------------+----------------------------------
+  No Next payload                   | 0
+  Security Association payload      | 33
+  Key Exchange payload              | 34
+  Identification payload            |
+      (when sent by initiator, IDi) | 35
+  Identification payload            |
+      (when sent by responder, IDr) | 36
+  Certificate payload               | 37
+  Certificate Request payload       | 38
+  Authentication payload            | 39
+  Nonce payload                     | 40
+  Notification payload              | 41
+  Vendor ID payload                 | 43
+  Encrypted payload                 | 46
+  Next Fast-ID payload              | 121
+  RESERVED TO IANA                  | 1-32, 42, 44-45, 47-120, 122-127
+  PRIVATE USE                       | 128-255
+
+   Payload type values 1-120 match the corresponding payloads in the
+   IKEv2 IANA registry.  That is, the EAP-IKEv2 payloads that have been
+   assigned a type value in the range 1-120 have a semantically
+   equivalent payload type in IKEv2, with an identical payload type
+   value.  However, there exist payloads types in IKEv2 that do not have
+   a semantically equivalent payload in EAP-IKEv2; this explains the
+   fact that the payload type values 42, 44, and 45 have not been
+   assigned in EAP-IKEv2; these values remain RESERVED TO IANA for this
+   version of EAP-IKEv2.
+
+   Payload type values 121-127 are used for EAP-IKEv2 specific payloads,
+   i.e., for payloads that do not have a semantically equivalent payload
+   in IKEv2.  Note that this range has been reserved for this purpose in
+   the IKEv2 IANA registry too.  This means that the same payload type
+   values will not be used for different things in IKEv2 and EAP-IKEv2
+   protocols.
+
+
+
+Tschofenig, et al.            Experimental                     [Page 27]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   Payload type values 122-127 are reserved to IANA for future
+   assignment to EAP-IKEv2-specific payloads.  Payload type values
+   128-255 are for private use among mutually consenting parties.
+
+   The semantics of the above-listed payloads is provided in this
+   document (0-127) and refer to IKEv2 when necessary (1-120).
+
+   New payload type values with a description of their semantic will be
+   assigned after Expert Review.  The expert is chosen by the IESG in
+   consultation with the Security Area Directors and the EMU working
+   group chairs (or the working group chairs of a designated successor
+   working group).  Updates can be provided based on expert approval
+   only.  A designated expert will be appointed by the Security Area
+   Directors.  Based on expert approval it is possible to delete entries
+   from the registry or to mark entries as "deprecated".
+
+   Each registration must include the payload type value and the
+   semantic of the payload.
+
+12.  Contributors
+
+   The authors are grateful to Krzysztof Rzecki, Rafal Mijal, Piotr
+   Marnik, and Pawel Matejski, who, during their implementation of EAP-
+   IKEv2 (see http://eap-ikev2.sourceforge.net/), provided invaluable
+   feedback and identified a number of errors in previous versions of
+   this document.
+
+13.  Acknowledgements
+
+   The authors also thank Pasi Eronen for his invaluable comments as
+   expert reviewer assigned by the EAP working group chairs Jari Arkko
+   and Bernard Aboba.  The authors would also like to thank Guenther
+   Horn, Thomas Otto, Paulo Pagliusi, and John Vollbrecht for their
+   insightful comments and suggestions.  The members of the PANA design
+   team; in particular, D. Forsberg and A. Yegin, also provided comments
+   on the initial version of this document.  We would like to thank Hugo
+   Krawczyk for his feedback regarding the usage of the password-based
+   authentication.
+
+   The authors are grateful to the members of the EAP keying design team
+   for their discussion in the area of the EAP Key Management Framework.
+
+   We would like to thank Jari Arkko for his support and for his
+   comments.  Finally, we would like to thank Charlie Kaufman, Bernard
+   Aboba, and Paul Hoffman for their comments during IETF Last Call.
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 28]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+14.  References
+
+14.1.  Normative References
+
+   [1]  Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
+        4306, December 2005.
+
+   [2]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+        Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC
+        3748, June 2004.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119, March 1997.
+
+   [4]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
+        Access Identifier", RFC 4282, December 2005.
+
+   [5]  Schiller, J., "Cryptographic Algorithms for Use in the Internet
+        Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
+
+14.2.  Informative References
+
+   [6]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
+        RFC 2716, October 1999.
+
+   [7]  Aboba, B., "Extensible Authentication Protocol (EAP) Key
+        Management Framework", Work in Progress, February 2007.
+
+   [8]  Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
+        Protocol (EAP-TTLS)", Work in Progress, July 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 29]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+Appendix A.  EAP-IKEv2 Protocol Runs with Failed Authentication
+
+   This appendix illustrates how authentication failures are handled
+   within EAP-IKEv2.  Note that authentication failures only occur in
+   full EAP-IKEv2 protocol runs.
+
+   Figure 10 shows the message flow in case the EAP peer fails to
+   authenticate the EAP server.
+
+   1. R<-I: EAP-Request/Identity
+
+   2. R->I: EAP-Response/Identity(Id)
+
+   3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
+
+   4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
+
+   5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH})
+
+   6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)})
+
+   7. R<-I: EAP-Failure
+
+          Figure 10: EAP-IKEv2 with Failed Server Authentication
+
+   The difference in the full successful exchange described in Section 3
+   is that, in message 6, the EAP peer MUST answer the EAP server with
+   an Encrypted payload that contains a Notify payload with the Notify
+   Message Type value set to 24 (AUTHENTICATION_FAILED).  In that
+   message, the Message ID field in the EAP-IKEv2 header (HDR) MUST
+   carry Message ID value 2.  In message 7, an EAP-Failure message MUST
+   be returned by the EAP server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 30]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+   Figure 11 shows the message flow in case the EAP server fails to
+   authenticate the EAP peer.
+
+   1. R<-I: EAP-Request/Identity
+
+   2. R->I: EAP-Response/Identity(Id)
+
+   3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
+
+   4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
+
+   5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH})
+
+   6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH})
+
+   7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)})
+
+   8. R->I: EAP-Res (HDR, SK {})
+
+   9. R<-I: EAP-Failure
+
+           Figure 11: EAP-IKEv2 with Failed Peer Authentication
+
+   Compared to the full successful exchange, one additional roundtrip is
+   required.  In message 7, the EAP server MUST send an EAP request with
+   Encrypted payload that contains a Notify payload with the Notify
+   Message Type value set to 24 (AUTHENTICATION_FAILED), instead of
+   sending an EAP-Success message.  The EAP peer, upon receiving message
+   7, MUST send an empty EAP-IKEv2 (informational) message in reply to
+   the EAP server's error indication, as shown in message 8.  In
+   messages 7 and 8, the Message ID field in the EAP-IKEv2 header (HDR)
+   MUST carry Message ID value 2.  Finally, by means of message 9, the
+   EAP server answers with an EAP-Failure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 31]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+Authors' Addresses
+
+   Hannes Tschofenig
+   Nokia Siemens Networks
+   Otto-Hahn-Ring 6
+   Munich, Bavaria  81739
+   Germany
+
+   EMail: Hannes.Tschofenig@nsn.com
+   URI:   http://www.tschofenig.com
+
+
+   Dirk Kroeselberg
+   Nokia Siemens Networks
+   Otto-Hahn-Ring 6
+   Munich, Bavaria  81739
+   Germany
+
+   EMail: Dirk.Kroeselberg@nsn.com
+
+
+   Andreas Pashalidis
+   NEC
+   Kurfuersten-Anlage 36
+   Heidelberg  69115
+   Germany
+
+   EMail: pashalidis@nw.neclab.eu
+
+
+   Yoshihiro Ohba
+   Toshiba America Research, Inc.
+   1 Telcordia Drive
+   Piscataway, NJ  08854
+   USA
+
+   EMail: yohba@tari.toshiba.com
+
+
+   Florent Bersani
+   France Telecom R&D
+   38, rue du General Leclerc
+   Issy-Les-Moulineaux, Cedex  92794
+   France
+
+   EMail: florent.ftrd@gmail.com
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 32]
+
+RFC 5106                    EAP-IKEv2 Method               February 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Experimental                     [Page 33]
+