    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]