RFC 5106

The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method

📅 published February 2008, from ietf

RFC 5106: The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method 🎀

Okay bestie, this is RFC 5106 💖. It's part of the Network Working Group series, dated February 2008, and its category is Experimental 🧪. The authors are H. Tschofenig, D. Kroeselberg (Nokia Siemens Networks), A. Pashalidis (NEC), Y. Ohba (Toshiba), and F. Bersani (France Telecom). Their whole job was defining EAP-IKEv2, which is a method that rides on top of IKEv2 ✨.

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 🦋

Okay so this document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method built on the Internet Key Exchange (IKEv2) protocol 🔐. It gives you mutual authentication and session key establishment between an EAP peer and an EAP server, which is seriously iconic 👑. It works with authentication techniques based on passwords, high-entropy shared keys, and public key certificates 💅. On top of that, it supports cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode 🚀.

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

1. Introduction 🧚

Okay, the main event: this document specifies EAP-IKEv2, an EAP method based on the Internet Key Exchange Protocol version 2 (IKEv2) [1] 💜. EAP-IKEv2 gives you mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques based on these types of credentials:

  • 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 🔑.
  • Passwords: these are low-entropy bit strings that are known to both the server and the peer 🙈.
  • Symmetric keys: these are high-entropy bit strings that are known to both the server and the peer 💎.

Here's the fun part: you can use a different credential (and therefore a different technique) for each direction ✨. For example, the EAP server could authenticate itself with a public/private key pair, while the EAP client authenticates itself with a symmetric key. The following combinations are expected to be used in practice. The document calls these "use cases" or "modes" from here on 🦋:

  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. So it's 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. There's more detail on that in Section 10.7 😭.

Also, in use case 3, the EAP server must either have access to all passwords in plaintext, or, for each password store, hold the value prf(password,"Key Pad for EAP-IKEv2") for all supported pseudorandom functions. See also 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, so they haven't been considered in this document 💀.

Heads up bestie: IKEv2 is able to carry EAP exchanges, but EAP-IKEv2 does NOT inherit this capability. That means it is not possible to tunnel EAP methods inside EAP-IKEv2 🚫.

The set of functionality EAP-IKEv2 provides is similar to other EAP methods, like EAP-TLS [6], but it's not identical 🌈.

The rest of the document is structured like this:

  • Section 2 provides an overview of the terminology and the abbreviations used in this document 📖.
  • Section 3 provides an overview of the full EAP-IKEv2 exchange and thereby specifies the protocol message composition 🧩.
  • Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode of operation ⚡.
  • Section 5 specifies how exportable session keys are derived 🗝️.
  • Section 6 specifies how the Session-ID, Peer-ID, and Server-ID elements are derived 🆔.
  • Section 7 specifies how errors that may potentially occur during protocol execution are handled 🛠️.
  • Section 8 specifies the format of the EAP-IKEv2 data fields. Section 8.1 describes how fragmentation is handled in EAP-IKEv2 🍓.
  • Section 9 specifies the payload type values and describes protocol extensibility 🌸.
  • 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] 📚✨.

Here's the abbreviation list, bestie 🫶:

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 🎲.

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 used for negotiating the cryptographic algorithms used within an EAP-IKEv2 protocol run. Specifically, SAi denotes a set of choices 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 ✨

okay bestie, this is where the whole EAP-IKEv2 protocol run gets laid out 💅. every message goes between two parties, an EAP peer and an EAP server 🫶. in EAP-IKEv2 the EAP server always takes the initiator (I) role and the EAP peer takes the responder (R) role of an exchange 👑. it's giving clear roles, no notes.

the semantics and formats of EAP-IKEv2 messages are similar to IKEv2 [1] for setting up an IKE Security Association 🦋, but not identical, so don't copy-paste blindly 🙈. the full run is two roundtrips, and then it ends with either an EAP-Success or an EAP-Failure ✨. there's also an optional roundtrip for swapping EAP identities that can come before the two main exchanges 🌸.

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 whole EAP-IKEv2 run 🎀, including the optional EAP identity exchange (messages 1 and 2) 💜. the detailed message breakdown comes right after, so let's go 🔥.

Messages 1 and 2 are a standard EAP Identity Request and Response, defined in [2] 🍓. message 3 is the first EAP-IKEv2-specific one, and it's when the server kicks off the real EAP authentication exchange 🧚. it carries the initiator Security Parameter Index (SPI) in the EAP-IKEv2 header (HDR), and the initiator picks a fresh SPI for every protocol run 🦋. it also lists the cryptographic algorithms the server is willing to accept for protecting EAP-IKEv2 traffic, meaning encryption and integrity protection, plus how the session key gets derived ✨. all of that lives in the Security Association payload (SAi) 💅. it also has a Diffie-Hellman payload (KEi) and a Nonce payload (Ni) 💖.

when the peer gets message 3, it picks one set of cryptographic algorithms out of the ones proposed 🌈. for this overview, we just assume an acceptable set exists (and gets picked), and that the Diffie-Hellman value KEi belongs to an acceptable group 🫶. then the peer makes a non-zero Responder SPI for this run, along with its own Diffie-Hellman value (KEr) and nonce (Nr) 🌸. it works out the keys SKEYSEED, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr following Section 2.14 of [1] 🧚. next up, it builds message 4 💅. for use cases 1, 2, and 3, the peer's local policy MAY dictate including the optional CERTREQ payload in that message 🎀. that's basically a hint telling the server to attach a certificate for its public key in the next message 🦋. for use case 4, though, the peer MUST include the optional SK{IDr} payload 🔥. that payload holds its EAP-IKEv2 identifier, encrypted and integrity-protected inside an Encrypted payload 🔐. the keys for that Encrypted payload are SK_er (for encryption) and SK_ar (for integrity protection), per [1] 💜. the responder's EAP-IKEv2 identifier (IDr) probably matters in these use cases, because the server needs it to pick the right symmetric key or password for building the AUTH payload of message 5 🙈.

once message 4 arrives, the server also computes SKEYSEED, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, following Section 2.14 of [1] 🍓. if an SK{IDr} payload is in there, the server decrypts it and checks its integrity with the matching keys 🔍. for this overview, we assume decryption and verification both work out 💖. then the server builds message 5, which is just the EAP-IKEv2 header plus one Encrypted payload 🎀. the keys for that encrypted payload MUST be SK_ei (for encryption) and SK_ai (for integrity protection), per [1] 🔥. the initiator MUST embed at least two payloads in that Encrypted payload 👑. first, an Identification payload with the initiator's EAP-IKEv2 identifier MUST be in there 🫶. second, the Authentication payload MUST be in there too 🔐. a Certificate payload and/or a Certificate Request payload MAY also be embedded in the Encrypted payload 🌈. a Next Fast-Reconnect Identifier payload MAY also be embedded there ✨. message 5 then goes to the responder 🦋.

when the responder gets message 5, it (the EAP peer) authenticates the initiator (the EAP server) 💅. the exact checks depend on the use case and local policies, and they're spelled out in [1] 🌸. these checks include (but may not be limited to) decrypting the Encrypted payload, verifying its integrity, and making sure the Authentication payload has the expected value 🧚. if every check passes (which we assume here) 🎀, the responder builds message 6. that message MUST contain the EAP-IKEv2 header plus a single Encrypted payload, and at least two more payloads MUST be embedded in that Encrypted payload, as shown in Figure 1 💖.

when the initiator (the EAP server) gets message 6, it authenticates the responder (the EAP peer) 🔥. same deal as before: the checks depend on the use case and local policies 🫶. they MUST include decrypting and verifying the Encrypted payload, plus checking that the Authentication payload has the expected value 💜. if the optional SK{IDr} payload was in message 4, the EAP server MUST also make sure the IDr payload in message 6 matches the one in message 4 🍓.

if authentication succeeds, an EAP-Success message goes to the responder as message 7 🎉. after a successful EAP-IKEv2 run, the EAP server and the EAP peer both generate a Master Session Key (MSK) and an Extended Master Session Key (EMSK), following Section 5 ✨👑.

4. Fast Reconnect ✨

okay so this section is all about the "fast reconnect" mode for EAP-IKEv2 🔄💖 implementing it is mandatory, but actually using it is optional. The whole point is a speedy re-authentication that also gives you a fresh MSK and EMSK 🔑 and it's only an option if an EAP-IKEv2 security context already exists on both the server and the peer. Local policies get the final say too 📋 so basically, this only works for an EAP server/peer pair that already did mutual authentication in an earlier EAP-IKEv2 run. bestie, that's the prerequisite energy 🫶

The fast reconnect mode uses special "fast reconnect EAP identifiers" 🎀 the server signals that it's down for future fast reconnect runs by including the optional "Next Fast-ID" (NFID) payload in message 5 of a "full" run (see Figure 1), or in message 3 of a "fast reconnect" run (see Figure 2). That NFID payload carries a special EAP identity called the Fast Reconnect Identity (FRID), which shows up as the Network Access Identifier (NAI) in the EAP-Response/Identity message. The FRID has an obfuscated username part and a realm part 🦋 when you're generating one, here's what to keep in mind:

  • The FRID, and therefore the pseudonym usernames, are generated by the EAP server. The server makes pseudonym usernames in an implementation-dependent way 🧚 only the EAP server needs to map a pseudonym username back to the permanent identity.
  • EAP-IKEv2 has no mechanism to guarantee that the same EAP server that made a pseudonym will be used when that pseudonym shows up later 😭 it is recommended that EAP servers have some centralized mechanism so all the home operator's EAP servers can map pseudonyms issued by other servers to the permanent identity. If there's no such mechanism, a server that doesn't recognize a pseudonym issued by someone else can ask the peer to send the permanent identity instead 🙈
  • When generating FRIDs, the server SHOULD choose a fresh and unique FRID that's different from the ones used earlier after the same full authentication exchange 💅 the FRID SHOULD include a random component in the username part, and that random bit works as a reference to the security context 🌸 no matter how you build it, the pseudonym username MUST conform to the grammar for the username portion of an NAI, and the FRID MUST conform to the NAI grammar [4]. The EAP servers that subscribers of an operator can use MUST ensure that the username part of the FRIDs they generate is unique ✨

The peer MAY use the FRID to kick off a "fast reconnect" run 🦋 the EAP Identity Response MUST be sent at the very beginning of a "fast reconnect" run. Now the catch: if the server did not include an NFID payload in message 5 (resp. 3) of the previous successful "full" (resp. "fast reconnect") run, then the peer MUST NOT start a fast reconnect run 🙅‍♀️ when the server gets a FRID, it maps it to an existing EAP-IKEv2 security context. Depending on local policy, the server either goes ahead with the "fast reconnect" run or goes ahead with message 3 of a "full" run. If the server advertised that FRID in the previous EAP-IKEv2 run, it SHOULD go with a "fast reconnect" run 👑 and the peer MUST be able to correctly handle a message 3 of a "full" run, even if it sent a FRID in its EAP Identity Response. No surprises allowed, bestie 💜

Here's a fun one: the peer might fail to save a FRID that was sent in the NFID payload (malfunction, etc.) 😬 so the EAP server SHOULD keep, at minimum, the most recently used FRID and the most recently issued FRID 🛡️ and if the authentication exchange doesn't complete successfully, the server MUST NOT overwrite the FRID that was issued during the most recent successful authentication exchange. Protect that FRID like it's your ex's phone number 💀

The EAP-IKEv2 fast reconnect exchange is basically a cousin of the IKE-SA rekeying procedure from Section 2.18 of [1] 🔄 so it uses a CREATE_CHILD_SA request and response, and the SPIs on those two messages are the SPIs negotiated in the previous exchange. During fast reconnect, the server and the peer MAY exchange fresh Diffie-Hellman values 🌈

Here's the message flow, verbatim, because the figure is iconic 📜

   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 fast reconnect mode 🦋 just like in the full mode, the EAP server is the initiator and the EAP peer is the responder. The first two messages are the standard EAP identity exchange. Note that, to use "fast reconnect," message 2 MUST be sent, because that's how the peer gets its FRID across in message 2 🎀

If the server can map the FRID to an existing EAP-IKEv2 context, it moves on to message 3 ✨ in this message the server MAY embed an NFID payload in the encrypted payload to hand the peer a new FRID. The server MAY also choose to do a full EAP-IKEv2 run instead, in which case it responds with a message that matches the format of message 3 in Figure 1 🧚

Messages 3 and 4 establish a brand 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 IKE_SA Responder's SPI field in HDR MUST be the one from the previous successful EAP-IKEv2 run. The nonce in the Nonce payload (Ni) MUST be fresh, and the Diffie-Hellman value in the Diffie-Hellman payload (KEi, if present) MUST also be fresh. If it's present, that Diffie-Hellman value MUST be drawn from the same group as the one in the previous successful full EAP-IKEv2 run. Also note that the algorithms and keys used to build the Encrypted payload in message 3 are the same as in the previous successful EAP-IKEv2 run 💅

When the responder (EAP peer) gets message 3, it decrypts and verifies the Encrypted payload 🔓 if that goes well (as assumed in Figure 2), it builds message 4 in a similar way to how message 3 was built. The responder MUST choose a new (non-zero) value for the SPI field in each proposal substructure. When the initiator (EAP server) gets message 4, it decrypts and verifies the Encrypted payload. If a correct message 4 arrives, the protocol run counts as successful and the server sends an EAP-Success message (message 5) 🎉

After a successful fast reconnect run, the initiator and the responder both generate fresh keying material to protect the subsequent EAP-IKEv2 traffic 🔥 and, furthermore, both the initiator and the responder MUST generate a fresh MSK and EMSK and export them. Main character energy 👑

The new EAP-IKEv2-specific keying material is computed the same way as in a full run, following Section 2.18 of [1] 🧮 SKEYSEED is computed as:

SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)

where SK_d (old) is the SK_d from the previous successful EAP-IKEv2 run, Ni and Nr are the nonces (without the Nonce payload headers) exchanged in messages 3 and 4, and g^ir (new) is the newly computed Diffie-Hellman key, if both 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 just like in the full run 🌈

Generating a fresh MSK and EMSK comes right after the EAP-IKEv2-specific keys, and follows 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's conceivable that an adversary tries a replay attack against the fast reconnect mode. In particular, the adversary may try to send a previously captured message 3 in a later fast reconnect run. This replay attempt fails, though, because the keys the responder uses to verify and decrypt the Encrypted payload change with every successful reconnect run 🛡️ replay denied, bestie 💅

5. Key Derivation 🔑

okay this section is about how the Master Session Key (MSK) and the Extended Master Session Key (EMSK) get derived in EAP-IKEv2 🧁 the MSK and EMSK are expected to be exported by the EAP-IKEv2 process and used according to the EAP keying framework [7] ✨

During an EAP-IKEv2 run, the initiator and the responder generate a bunch of keys, as described above and in line with Section 2.14 of [1] 🔐 generating these keys relies on a pseudorandom function (prf) that both parties agreed to use, applied iteratively. That iterative approach is specified in Section 2.13 of [1] and is called prf+ 🌸

Specifically, after a successful EAP-IKEv2 run, both parties generate 128 octets of keying material, called KEYMAT, like this:

KEYMAT = prf+(SK_d, Ni | Nr)

where Ni and Nr are the nonces (just the payload, no headers) from messages 3 and 4 in Figure 1 (for a full run) or Figure 2 (for a fast reconnect run) 💖 only the nonces get used, not the whole Nonce payload that contains them, so be precise, bestie 🎀

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 run completes successfully. Also, the EAP-IKEv2 method does not produce an initialisation vector [7]. Hard rules, no exceptions 🙅‍♀️💀

6. Session ID, Peer ID, and Server ID ✨

okay so the EAP key management framework [7] wants EAP methods to export three info elements: the Session-ID, the Peer-ID, and the Server-ID. 🫶 Here's how EAP-IKEv2 builds each one:

  • The Session-ID is the concatenation of three things, in this exact 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, and (c) the contents of the Nonce Data field of the Nonce Payload Nr from message 4. 💖
  • In a full EAP-IKEv2 protocol run, the Peer-ID is the content of the Identification Data field of the Identification Payload IDr from message 6. 🎀 Only the "actual" identification data gets exported, as indicated by the Payload Length field. If the Identification Data field has any padding, that padding is ignored. 🙈 In a "fast reconnect" run, the Peer-ID is built in exactly the same way, except message 6 refers to the full EAP-IKEv2 protocol run that originally set up the security context between the EAP peer and EAP server. 🦋
  • In a full EAP-IKEv2 protocol run, the Server-ID is the contents of the Identification Data field of the Identification Payload IDi from message 5. 🌸 Same deal: only the "actual" identification data counts, as indicated by the Payload Length field, and any padding in the Identification Data field gets ignored. ✨ In a "fast reconnect" run, the Server-ID is built 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 explains how errors get handled in EAP-IKEv2 💅. To send error info 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 (meaning the verification of the AUTH field fails at the server or the peer) but no other errors happened, the message flow deviates from the one described in Section 3. 🙃 The message flows when authentication fails are specified in Appendix A.

If, in message 3 of a full EAP-IKEv2 protocol run (see Figure 1), the responder gets a Diffie-Hellman value (KEi) that belongs to a group that isn't supported (and there are no 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 message above is the EAP-IKEv2 header plus a Notification payload, with the Notify Message Type field set to 17 (INVALID_KE_PAYLOAD). 🎀 There's a two-octet value attached to 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 gets a message matching Figure 3 instead of the usual message 4, then it MUST check whether the indicated DH group was proposed in message 3. 🧐 If it wasn't, the initiator MUST silently discard the message. 🤫 Otherwise, the protocol keeps going 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 drawn from the group 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 matching the format of message 5. 👀 The AUTH payload in that message SHOULD contain a value that is computationally indistinguishable from the value it would contain if IDr* were valid and authorised. 🕵️‍♀️ One way to get there is to generate a random key and calculate AUTH as usual (though this document doesn't mandate a specific mechanism). Only after receiving message 6, the server SHOULD respond with an authentication failure notification, meaning a message matching message 6 in Figure 10. 💀 The point of all this is to stop 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 wouldn't be required in these use cases). 🌸 The server MUST compare IDr* with the IDr received in message 6. If there's a mismatch, the server MUST respond with an authentication failure notification, meaning a message matching message 6 in Figure 10. 🙅‍♀️ If no mismatch is detected, normal processing applies. ✅

Other errors don't trigger messages with Notification payloads, and they MUST be treated as if nothing happened (i.e., the erroneous EAP-IKEv2 packet MUST be silently discarded). 🫥 This covers situations where at least one of the following conditions is met for an incoming EAP-IKEv2 packet:

  • The packet contains an Encrypted payload that, when decrypted with the appropriate key, yields an invalid decryption. 🔐
  • The packet contains an Encrypted payload with a Checksum field that doesn't verify with the appropriate key. ❌
  • The packet contains an Integrity Checksum Data field (see *Figure 4) that is incorrect. 🧮
  • The packet does not contain a compulsory field. 📭
  • 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). 🙈
  • 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). 🧩
  • The packet causes a defragmentation error. 🧵
  • The format of the packet is invalid. 🫠
  • The identity provided by the EAP peer in the EAP-Response/Identity cannot be associated with either an established security context (in the case of a fast reconnect) or a real user account (in the 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 the 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 that has a specified behaviour in this section, and an error that, without 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 we get into the EAP-IKEv2 data fields and the processing rules that go with them 🤓. Figure 4 shows the general packet format of EAP-IKEv2 messages and how EAP-IKEv2 gets embedded in EAP. The EAP-IKEv2 messages live in the Data field of standard EAP Request/Response packets. The Code, Identifier, Length, and Type fields are described in [2]. The EAP Type for this 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 handles fragmentation support, as described in Section 8.1. The Message Length field isn't always there; whether it shows up depends on a certain flag in the Flags field, as described in Section 8.1. The field labelled "HDR + payloads" in Figure 4 holds the EAP-IKEv2 header (see Section 8.2), followed by the payloads, according to how EAP-IKEv2 messages are composed, as described in the previous sections. 📦 Each payload starts with a generic payload header specified in Section 3.2 of [1].

The Integrity Checksum Data field isn't always present either; whether it shows up depends on a certain flag in the Flags field, as described in Section 8.1. 🧾

For the rest of this section, we'll go through the protocol fields EAP-IKEv2 uses. This spec leans heavily on the IKEv2 specification [1], and lots of fields get constructed, formatted, and processed in a way that's almost identical to IKEv2. 💜 But there are some deviations from standard IKEv2 formatting and processing. Those deviations are called out in the rest of this section. 🌟

8.1. The Flags, Message Length, and Integrity Checksum Data Fields ✨

Okay so this section is all about EAP-IKEv2 fragmentation 🧩 and it lays out the encoding and processing rules for the Flags, Message Length, and Integrity Checksum Data field shown in Figure 4 💖

Fragmentation support in EAP-IKEv2 comes from the Flags and Message Length fields in Figure 4. Here's how they're encoded and used 🎀

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |L M I 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+

Figure 5: Flags Field

The Flags field is defined in Figure 5 🦋 Only the first three bits (0-2) get used, and all the remaining bits MUST be set to zero and ignored on receipt 🌸 The L flag tells you whether a Message Length field is there, and the M flag tells you if the current EAP message still has more fragments coming 💅 Literally, 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 holds the length of the entire message (aka the length of the EAP Data field 🧠). The Length field in Figure 4 is different, because it only tells you the length of the current fragment. There are two length fields that get mixed up, so here's the tea: the Length field is a generic EAP field, and the Message Length field is EAP-IKEv2-specific 🙈 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. On the last fragment, the M flag MUST NOT be set. Reliable fragment delivery is handled by EAP's retransmission mechanism, which is described below 🔁

When an EAP-IKEv2 peer gets an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-IKEv2 and no data. That's the fragment ACK 🫶 The EAP server MUST wait until it gets that EAP-Response before it sends another fragment. To keep fragment processing from going sideways, the EAP server MUST increment the Identifier field for each fragment in an EAP-Request, and the peer MUST include that Identifier value in the fragment ACK inside the EAP-Response. Retransmitted fragments keep the same Identifier value 💜

Same energy in the other direction 👑 When the EAP server gets an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-IKEv2 and no data, which is also a fragment ACK. The EAP peer MUST wait until it receives that EAP-Request before sending another fragment. To avoid processing errors, the EAP server MUST increment the Identifier value for each fragment ACK in an EAP-Request, and the peer MUST include this Identifier value in the next fragment inside an EAP-Response ✨

The Integrity Checksum Data field holds a cryptographic checksum covering the whole EAP message, from the Code field all the way to the end of the EAP Data field 🔐 This field (shown in Figure 4) is only there if the I bit is set in the Flags field. It goes right after the EAP Data field, with no padding.

Whenever possible, the Integrity Checksum Data field MUST be present (with the I bit set) for each fragment, even if the whole EAP-IKEv2 message fits in a single fragment 🌈 The algorithm and keys used to compute it MUST be identical to the ones used for the Integrity Checksum Data field of the Encrypted Payload (see Section 8.9). So it's the algorithm and keys negotiated and established during this EAP-IKEv2 protocol run. Also, different keys get used for the Integrity Checksum Data field in each direction 🔄 For messages where this algorithm and these keys aren't established yet, the Integrity Checksum Data field can't be computed, so it isn't included. For example, that applies to messages 3 and 4 in Figure 1 🙃

To cut down on denial-of-service exposure for fragmented packets, messages that aren't protected with an Integrity Checksum Data field SHOULD NOT be fragmented. Those packets probably won't get fragmented anyway, though, since they don't carry certificates 🦋

8.2. EAP-IKEv2 Header 🎀

The EAP-IKEv2 header (called HDR in this spec) gets built and formatted according to the rules in Section 3.1 of [1] 💅

In the first EAP-IKEv2 message the initiator sends (message 3 in Figure 1), the IKE_SA Responder's SPI field is set to zero. Why? The initiator doesn't know yet what SPI value the responder will pick for this run 🤷‍♀️ In all other messages, both SPI fields MUST contain non-zero values that reflect the SPI values chosen by the initiator and the responder.

Following [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 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 built according to Section 3.1 of [1]. Heads up, this is NOT the same field as the Flags field shown in Figure 4 🙈

The Message ID field works like this. 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 how the initiator and responder negotiate cryptographic algorithms 🤝 Its construction follows [1], specifically Sections 2.7 and 3.3.

In EAP-IKEv2, all Proposal Substructures in the SA payload MUST carry Protocol ID value 1 (IKE) ✨

8.4. Key Exchange Payload 🗝️

The Key Exchange payload, called KEi when the initiator builds it and KEr when the responder does, is formatted according to the rules in Section 3.4 of [1] 💖

8.5. Nonce Payload 🎲

The Nonce payload, called Ni when the initiator builds it and Nr when the responder does, is constructed and formatted according to the rules in Section 3.9 of [1] 🌈

8.6. Identification Payload 🪪

The Identification payload, called IDi if it holds an identifier for the initiator and IDr if it holds one for the responder, is constructed and formatted according to the rules in Section 3.5 of [1] 💜

8.7. Certificate Payload 📜

The Certificate payload, called CERT, is constructed and formatted according to the rules in Section 3.6 of [1]. Now, some certificate encodings for the EAP server certificate (like ones that need to be resolved through another network protocol) can't be used in lots of typical EAP-IKEv2 deployments 😭 Take a user who authenticates by way of EAP-IKEv2 to get network access. They can't resolve the server certificate while the EAP-IKEv2 protocol is running, so that's a no-go.

8.8. Certificate Request Payload 🙏

The Certificate Request payload, called CERTREQ, is constructed and formatted according to the rules in Section 3.7 of [1] 🍓

8.9. Encrypted Payload 🔒

The Encrypted payload, called SK{...}, is constructed and formatted according to the rules in Section 3.14 of [1] 💅

8.10. Authentication Payload 🔑

The Authentication payload, called AUTH, is constructed and formatted according to the rules in Sections 2.15 and 3.8 of [1] 🧚

What goes in the Authentication payload depends on who generates it, the use case, and the algorithm for the credential that party uses to authenticate itself (asymmetric key, symmetric key, or password). The Authentication payload contains either a MAC or a signature 🌸

If the party generating the Authentication payload authenticates itself with a shared secret (a password or a symmetric key), then the Authentication payload MUST contain a MAC. That MAC gets calculated with a key derived from the shared secret, following Section 2.15 of [1]. In that section, the shared secret is padded with the string "Key Pad for IKEv2" as part of the key derivation. For EAP-IKEv2, this rule is overridden, and the padding string is redefined as "Key Pad for EAP-IKEv2" 🔁 That second padding string MUST be used when deriving the MAC key from a shared secret in the context of EAP-IKEv2. Why? So the same MAC key doesn't get used for both IKEv2 and EAP-IKEv2 when the same shared secret is used for both 🛡️ Also, using a shared secret (like a password) in EAP-IKEv2 that's identical or similar to one used in another context (including IKEv2) is still NOT RECOMMENDED 🚫

8.11. Notify Payload 🔔

The Notify payload, called N(...), is constructed and formatted according to the rules 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 like this 👑

                           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 (NFID) doesn't have an equivalent in IKEv2 🙃 Even so, its Next Payload, C, RESERVED, and Payload Length fields are constructed according to Section 3.2 of [1]. The payload ID is registered in Section 11 📋 The Fast-Reconnect-ID field holds a fast reconnect identifier that the peer can use in its next fast reconnect protocol run, as described in Section 4 🔁 If a realm portion is required in your environment, the Fast-Reconnect-ID includes both a username portion and a realm name portion. The Fast-Reconnect-ID MUST NOT include any terminating null characters. Its encoding MUST follow the NAI format [4] 🫶

9. Payload Types and Extensibility ✨

okay so every EAP-IKEv2 payload gets its own type field 🎀 It's the one the previous payload points at through its "Next Payload" field, same trick as in [1] 💅 But here's the tea: the EAP-IKEv2 payload type numbers come from a totally separate pool from IKEv2's 🫶 They're independent because the two protocols can evolve in different directions, so a payload type in one doesn't have to show up in the other 🦋 The "Next Fast-ID" (NFID) payload is the perfect example, since it doesn't exist in IKEv2 at all 😭

The payload type values defined in this document are listed in Section 11 🌸 Values 13-127 are reserved for IANA to hand out later for EAP-IKEv2 ✨ Values 128-255 are for private use between parties who've agreed to them 🧚

10. Security Considerations 🔥

bestie, this section is the serious one. Read it carefully. 🙈

okay so, as Section 3 mentioned, the EAP server always plays the initiator (I) 👑 and the EAP peer is the responder (R) of the exchange 💖 Why? Because when the peer authenticates with a password (that's use case 3), anything involving that password only happens after the server has proven itself 🔐 So that role assignment protects against offline dictionary attacks on the peer's password (see Section 10.7) 💅

Now, for two EAP-IKEv2 implementations to talk to each other, they need at least one cryptographic algorithm set in common 🦋 So to make interop actually happen, EAP-IKEv2 implementations MUST support the following algorithms, based on the "MUST/MUST-" recommendations 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

Everything else in [5] is MAY be implemented 🌈

The rest of this section describes EAP-IKEv2 using the specific security terms that [2] asks for 📚 It also points back at the use cases from Section 1 🍓

10.1. Protected Ciphersuite Negotiation

Message 3 is where the EAP server offers up the ciphersuites it's willing to accept in an EAP-IKEv2 run 👑 So the server is the one in charge of the ciphersuite, full stop 💅 If a peer doesn't support any of the offered ones, it just can't authenticate, sorry bestie 😭 The peer's local security policy MUST spell out which ciphersuites it accepts ✨ And when the peer picks one in message 4, the server MUST check that the pick was actually in the list it offered in message 3 🔍 If that check fails, the server MUST silently discard the packet 🙈

10.2. Mutual Authentication

EAP-IKEv2 supports mutual authentication 🫶 Both sides prove who they are, no one gets left out 💜

10.3. Integrity Protection

EAP-IKEv2 protects the integrity of its traffic 🛡️ This protection kicks in once authentication is done ✨ It comes from two Integrity Checksum Data fields: one at the very end of the EAP packet (see Figure 4), and one inside an Encrypted payload (see Section 8.9) 🎀

10.4. Replay Protection

EAP-IKEv2 guards against replay attacks in several ways 🔁 One big one is that the Authentication payload gets computed from, among other things, a server-provided nonce and a peer-provided nonce 🧁 Those nonces are supposed to be practically unpredictable to an attacker 🔮 As long as the algorithm used for the Authentication payload has no cryptographic weaknesses, the odds that a valid Authentication payload from one run also works in a later run are negligible 💀

10.5. Confidentiality

EAP-IKEv2 keeps certain fields confidential: the ones inside Encrypted payloads 🔒 For identity confidentiality, here's the deal (and note that "identity" here means the EAP peer's EAP-IKEv2 identity) 🫣

Identity confidentiality holds against a passive adversary, meaning someone who just watches traffic and doesn't touch it 👀 If the optional SK{IDr} payload in message 4 of a full EAP-IKEv2 protocol (see Figure 1) is left out, identity confidentiality also holds against an active adversary 🦋 That payload MUST NOT be included in use cases 1, 2, and 3 🚫 In use case 4, it MUST be included ✨ So in use case 4, EAP-IKEv2 does not give identity confidentiality against an active adversary 😭

Heads up though: the EAP peer sends its identity in cleartext in message 2 of Figure 1 🙈 To get the confidentiality we just talked about, you have to obfuscate the username part of the identity 🎭 The realm part has to stay readable so the AAA (Authentication, Authorization, and Accounting) infrastructure can still route the message correctly 🗺️ The EAP server then uses the identity info from message 4 💜 Other EAP methods do this same trick too, like EAP-TTLS [8] 🧚

NOTE TO SELF: don't leave the realm readable and then wonder why it's not hidden. 🙈

10.6. Key Strength

EAP-IKEv2 can establish session keys (MSK and EMSK) with a range of strengths 💪 The theoretical max is 512 bits per key, since that's the size of the MSK and the EMSK 🔢 In practice though, the effective strength is probably a lot lower 📉 It depends on the authentication credentials, the negotiated ciphersuite (including the output size of the pseudorandom function), the Diffie-Hellman group, and how well the assumptions behind those crypto algorithms actually hold up 🧠 Whichever of those mechanisms is weakest is the one you can treat as the effective key strength of the session keys 🫶 And this is true for other EAP methods too 🌸

Because there are so many possible combinations, this document doesn't give a practical effective key strength for MSK or EMSK 🤷‍♀️ Instead, people deploying EAP-IKEv2 in a given environment should think about the threats that environment faces 🕵️ Then they should configure the EAP-IKEv2 server and peer policies and their credentials so the session keys end up sufficiently strong 💅

10.7. Dictionary Attack Resistance

EAP-IKEv2 shows up in lots of use cases (see Section 1) 🗂️ Dictionary attacks can't happen in use cases 1, 2, and 4, because no passwords are involved there 🙅‍♀️

In use case 3, EAP-IKEv2 protects against offline dictionary attacks 🛡️ Anything involving the password only runs after the server has authenticated itself, using a credential that isn't a password 🔐

To lower exposure to online dictionary attacks in use case 3, the server SHOULD log failed peer authentication events 📝 It SHOULD also have a sensible policy for when a bunch of peer authentication attempts fail in a short window 🚦 For example, it could send an EAP-Failure instead of message 5 for a set amount of time ⏳

When passwords are used with method 4 (instead of a high-entropy key), dictionary attacks become possible 😬 [1] explains why, in Section 8, and this is the quote 💅

"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."

So using passwords with mode 4, where the peer and server share a secret derived from a password, is insecure 💀 It's strongly recommended to use mode 3 whenever the EAP peer uses a password 🎀

10.8. Fast Reconnect

EAP-IKEv2 supports a "fast reconnect" mode, which Section 4 covers 🏃‍♀️⚡

10.9. Cryptographic Binding

EAP-IKEv2 isn't a tunnel EAP method 🙅‍♀️ So cryptographic binding doesn't apply to it 🤷‍♀️

10.10. Session Independence

EAP-IKEv2 gives session independence in a couple of ways 🦋

First off, if an attacker captures EAP-IKEv2 conversations (which is all a passive adversary can get), they still can't work out the Master Session Key (MSK) and Extended Master Session Key (EMSK) from that run 🔐 That stays true even if they later get into the server or the peer and grab those long-term credentials 💪 That's what "perfect forward secrecy" means, and EAP-IKEv2 supports it 🎀 Whether a given run actually uses it depends on when the peer and server delete the Diffie-Hellman values from that run, and on whether they pick fresh Diffie-Hellman values every time 🧠 Section 2.12 of [1] has the details 📚

Second, an active adversary who doesn't know the peer's or server's long-term credentials can't learn the MSK and EMSK from one run, even after getting the MSK and EMSK from other runs 🙌 Why? Because the MSK and EMSK depend on data items that are assumed to be generated independently at random in every run 🎲

10.11. Fragmentation

EAP-IKEv2 supports fragmentation, as described in Section 8.1 📦✨

10.12. Channel Binding

Channel binding is not supported in EAP-IKEv2 🚫

10.13. Summary

The EAP security claims are defined in Section 7.2.1 of [2] 📋 Here's how EAP-IKEv2 stacks up 💅

            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

main character energy, all of it 🌈👑💖

11. IANA Considerations ✨

okay bestie, IANA time 🗂️💅 so IANA has given the EAP method type 49 to EAP-IKEv2 🎀 and this isn't a brand new vibe, EAP-IKEv2 already got through Designated Expert Review earlier, which is what RFC 3748 says has to happen for IANA allocations 🫶

there's also a brand new registry for "EAP-IKEv2 Payloads" 🌈 and it comes pre-loaded with the starter entries below 🍓

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

so payload type values 1-120 line up with the matching IKEv2 payloads 🦋 meaning any EAP-IKEv2 payload with a value in 1-120 has a semantically equivalent IKEv2 payload with the very same number ✨ BUT not every IKEv2 payload has an EAP-IKEv2 twin 🙈 which is why 42, 44, and 45 never got assigned here and stay RESERVED TO IANA for this version of EAP-IKEv2 💜

121-127 is the EAP-IKEv2 specific zone 👑 for payloads with no IKEv2 equivalent, and IKEv2's registry reserved that same range too, so the same number never means two different things across IKEv2 and EAP-IKEv2 🫶 no mix-ups, periodt 💅

122-127 are reserved for future EAP-IKEv2 specific payloads 🌸 and 128-255 are PRIVATE USE, meaning mutually consenting parties can use them however they agree 🤝

the semantics of the payloads listed above are in this document for 0-127 and they point back to IKEv2 where needed for 1-120 📖

new payload type values get added only after Expert Review 🔍 the expert is picked by the IESG in consultation with the Security Area Directors and the EMU working group chairs (or the chairs of whichever working group succeeds them) ✨ updates only happen with expert approval 💖 a designated expert gets appointed by the Security Area Directors 🎀 and with expert approval, entries can be deleted from the registry or marked "deprecated" 🥀

every registration has to include the payload type value and what the payload means 💜

12. Contributors 🌷

the authors are so grateful to Krzysztof Rzecki, Rafal Mijal, Piotr Marnik, and Pawel Matejski 🫶 they implemented EAP-IKEv2 (you can peek at http://eap-ikev2.sourceforge.net/) and gave super valuable feedback and caught a bunch of errors in earlier versions of this doc 😭🙌

13. Acknowledgements 💖

the authors also thank Pasi Eronen for his invaluable comments as the expert reviewer assigned by the EAP working group chairs Jari Arkko and Bernard Aboba 🦋 they'd 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 commented on the initial version 🌈 and they thank Hugo Krawczyk for his feedback on the usage of password-based authentication 🔐

the authors are grateful to the members of the EAP keying design team for their discussion of the EAP Key Management Framework 💜

thanks to Jari Arkko for his support and comments 🫶 and finally, thanks to Charlie Kaufman, Bernard Aboba, and Paul Hoffman for their comments during IETF Last Call 🎉

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. 💜

Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication 💀

this appendix shows how authentication failures get handled in EAP-IKEv2 🙈 and it's worth knowing that authentication failures only happen in full EAP-IKEv2 protocol runs 🫶

Figure 10 shows the message flow when 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 from the full successful exchange in Section 3 is that in message 6, the EAP peer MUST answer the EAP server with an Encrypted payload containing a Notify payload with the Notify Message Type value set to 24 (AUTHENTICATION_FAILED) 🚫 and in that message, the Message ID field in the EAP-IKEv2 header (HDR) MUST carry Message ID value 2 🔢 then in message 7, the EAP server MUST return an EAP-Failure message 💔

Figure 11 shows the message flow when 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 extra roundtrip is required 🔁 in message 7, the EAP server MUST send an EAP request with an Encrypted payload containing a Notify payload with the Notify Message Type value set to 24 (AUTHENTICATION_FAILED), instead of sending an EAP-Success message 🙅‍♀️ the EAP peer, on receiving message 7, MUST send an empty EAP-IKEv2 (informational) message back as its reply to the 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 🔢 and finally, with message 9, the EAP server answers with an EAP-Failure 🏁

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 🦋

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 in it 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 on 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 on whether any license under such rights might or might not be available, and it doesn't claim to have made any independent effort to identify any such rights 🔍 information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt 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 send that information to the IETF at ietf-ipr@ietf.org 📨

📦 where this page comes from