RFC 4793

The EAP Protected One-Time Password Protocol (EAP-POTP)

📅 published February 2007, from ietf

The EAP Protected One-Time Password Protocol (EAP-POTP) 🦋

Bestie, this is RFC 4793 and it's giving 🌈 EAP-POTP 🌈 looks like a lot but I got you 🫶

Title block: This is RFC 4793, written by M. Nystroem from RSA Security under the Network Working Group. It's Category Informational, so it's sharing info, not setting a standard, and it's dated February 2007 💅 The header doesn't list anything it obsoletes or updates, so it doesn't claim to replace or patch any earlier RFC ✨

Status of This Memo ✨

Okay so this doc is just here to share info with the Internet community. It is NOT an Internet standard of any kind, so don't go treating it like one 🙈 And distribution is unlimited, so share it with everyone 🌸

Copyright (C) The IETF Trust (2007).

Abstract 💜

Okay this is the vibe check. EAP-POTP is a general Extensible Authentication Protocol (EAP) method made for One-Time Password (OTP) tokens, and it's especially slay for tokens with direct electronic interfaces to the client 🔥 It can do unilateral authentication or mutual authentication, and it can carry key material, in protocols that use EAP, like PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2) 🫶

Table of Contents 🧚

   1. Introduction ....................................................4
      1.1. Scope ......................................................4
      1.2. Background .................................................4
      1.3. Rationale behind the Design ................................4
      1.4. Relationship with EAP Methods in RFC 3748 ..................5
   2. Conventions Used in This Document ...............................5
   3. Authentication Model ............................................5
   4. Description of the EAP-POTP Method ..............................6
      4.1. Overview ...................................................6
      4.2. Version Negotiation ........................................9
      4.3. Cryptographic Algorithm Negotiation .......................10
      4.4. Session Resumption ........................................11
      4.5. Key Derivation and Session Identifiers ....................13
      4.6. Error Handling and Result Indications .....................13
      4.7. Use of the EAP Notification Method ........................14
      4.8. Protection against Brute-Force Attacks ....................14
      4.9. MAC Calculations in EAP-POTP ..............................16
           4.9.1. Introduction .......................................16
           4.9.2. MAC Calculation ....................................16
           4.9.3. Message Hash Algorithm .............................16
           4.9.4. Design Rationale ...................................17
           4.9.5. Implementation Considerations ......................17
      4.10. EAP-POTP Packet Format ...................................17
      4.11. EAP-POTP TLV Objects .....................................20
           4.11.1. Version TLV .......................................20
           4.11.2. Server-Info TLV ...................................21
           4.11.3. OTP TLV ...........................................23
           4.11.4. NAK TLV ...........................................33
           4.11.5. New PIN TLV .......................................35
           4.11.6. Confirm TLV .......................................38
           4.11.7. Vendor-Specific TLV ...............................41
           4.11.8. Resume TLV ........................................43
           4.11.9. User Identifier TLV ...............................46
           4.11.10. Token Key Identifier TLV .........................47
           4.11.11. Time Stamp TLV ...................................48
           4.11.12. Counter TLV ......................................49
           4.11.13. Challenge TLV ....................................50
           4.11.14. Keep-Alive TLV ...................................51
           4.11.15. Protected TLV ....................................52
           4.11.16. Crypto Algorithm TLV .............................54
   5. EAP Key Management Framework Considerations ....................57
   6. Security Considerations ........................................57
      6.1. Security Claims ...........................................57
      6.2. Passive and Active Attacks ................................58
      6.3. Denial-of-Service Attacks .................................59
      6.4. The Use of Pepper .........................................59
      6.5. The Race Attack ...........................................60
   7. IANA Considerations ............................................60
      7.1. General ...................................................60
      7.2. Cryptographic Algorithm Identifier Octets .................61
   8. Intellectual Property Considerations ...........................61
   9. Acknowledgments ................................................61
   10. References ....................................................62
      10.1. Normative References .....................................62
      10.2. Informative References ...................................62
   Appendix A. Profile of EAP-POTP for RSA SecurID ...................64
   Appendix B. Examples of EAP-POTP Exchanges ........................65
      B.1. Basic Mode, Unilateral Authentication .....................65
      B.2. Basic Mode, Session Resumption ............................66
      B.3. Mutual Authentication without Session Resumption ..........67
      B.4. Mutual Authentication with Transfer of Pepper .............69
      B.5. Failed Mutual Authentication ..............................70
      B.6. Session Resumption ........................................71
      B.7. Failed Session Resumption .................................73
      B.8. Mutual Authentication, and New PIN Requested ..............75
      B.9. Use of Next OTP Mode ......................................78
   Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes ....80
      C.1. Introduction ..............................................80
      C.2. MPPE Key Attribute Population .............................80
   Appendix D. Key Strength Considerations ...........................80
      D.1. Introduction ..............................................80
      D.2. Example 1: 6-Digit One-Time Passwords .....................81
      D.3. Example 2: 8-Digit One-Time Passwords .....................81

1. Introduction 🌸

1.1. Scope 💖

This doc describes an Extensible Authentication Protocol (EAP) [1] method made for One-Time Password (OTP) tokens. It's especially good for tokens that are electronically connected to a user's computer, like through a USB interface 🔌 It can give you unilateral or mutual authentication, plus key material, in protocols that use EAP, like PPP [10], IEEE 802.1X [11], and IKEv2 [12] ✨

1.2. Background 🧚

An OTP token can be a handheld hardware device, a hardware device plugged into a PC through an electronic interface like USB, or a software module living on a PC that spits out one-time passwords. A user can use those passwords to authenticate to some service 🔐 This doc describes an EAP method for organizations that want to use OTP tokens in an interoperable way to authenticate users over EAP. It's built to be independent of any particular OTP algorithm, and it's meant to meet the requirements for modern EAP methods (see [13]) 💅

The basic variant only does client authentication. It is only to be used inside a secured tunnel 🔒 The more advanced variant gives you mutual authentication, integrity protection of the exchange, protection against eavesdroppers, and establishment of authenticated keying material. Both variants support fast session resumption ⚡

This doc also includes a profile for the RSA SecurID(TM) mechanism, but the method is written in general terms. So the document is also meant to work as a framework for other OTP algorithms 🦋

Note: The term "OTP" as used herein shall not be confused with the EAP OTP method defined in [1]. Don't mix these two up, bestie 🙈

1.3. Rationale behind the Design 👑

EAP-POTP was designed so its messages and data elements are easy for EAP implementations to parse. This makes it easier to use the EAP method programmatically in the peer and the authenticator, which means fewer user interactions and the option to generate user prompts locally when needed 🤖 Compare that with the Generic Token Card (GTC) method from [1], which uses text strings generated by the EAP server. Those strings are meant to be read and acted on by humans 🙋‍♀️ EAP-POTP also does mutual authentication and keying material setup, which GTC can't do. To keep the generic nature of GTC, EAP-POTP is built to support a wide range of OTP algorithms, with profiles expected for specific ones. This doc gives a profile of EAP-POTP for RSA SecurID tokens 💜

1.4. Relationship with EAP Methods in RFC 3748 🎀

The EAP OTP method from [1], which builds on [14], is one example of a specific OTP algorithm. It's not related to the EAP method in this document, except that a profile of EAP-POTP could be made for the OTP algorithm from [14] 🌈

The GTC EAP method from [1] is meant to work with a variety of OTP algorithms, and so is EAP-POTP. The advantages of profiling a particular OTP algorithm for EAP-POTP, compared to using EAP GTC, are covered in Section 1.3 ✨

2. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [2]. These are the capital-letter words that carry real weight, so read them carefully 🫶

3. Authentication Model 🧠

EAP-POTP gives you user authentication, as defined below. It may also give you mutual authentication, where the EAP server is authenticated to the EAP client, and it may establish keying material 🔑

There are basically three entities in this model:

  • A client, or "peer" in EAP terms, acting on behalf of a user who has an OTP token 🙋‍♀️
  • A server, or "authenticator" in EAP terms, which the user needs to authenticate to 🏰
  • A backend authentication server, which gives an authentication service to the authenticator 🛡️

The term "EAP server" means the same thing here as it does in [1]. Any protocol between the authenticator and the backend authentication server is outside the scope of this doc, though RADIUS [15] is a typical choice 📡 The EAP client and the peer are assumed to be on the same host, so from here on this doc only uses the term "peer" for those entities 💻

EAP-POTP assumes a shared secret key, called a "seed". The user and the backend authentication server both know it. The secret seed is stored on the OTP token the user has, and also on the authentication server 🌱

In its most basic variant, EAP-POTP offers only one Service, which is user authentication. There, the user gives information to the authentication server so the server can authenticate the user. The more advanced variant also gives mutual authentication, protection against eavesdropping, and establishment of authenticated keying material 💖

4. Description of the EAP-POTP Method 🧚‍♀️✨

4.1. Overview 🦋

Okay bestie, quick heads up: EAP-POTP is super general, so the doc uses POTP-X as a placeholder for whichever EAP method type identifier you're using for a particular OTP algorithm. Like, if you're using RSA SecurID tokens within EAP-POTP, the EAP method type shall be 32 (see Appendix A). 💖

A typical EAP-POTP authentication goes like this (Appendix B has more detailed examples) ✨

a. First up, the optional EAP Identity Request/Response happens, as per RFC 3748 [1]. An identity given here might save you from needing a "User Identifier" or a "Token Key Identifier" triplet (TLV), defined below, later in the exchange. 🧚

b. The EAP server sends an EAP-Request of type POTP-X with a Version TLV. The Version TLV says the highest and lowest versions of this method the server supports. The EAP server usually also includes an OTP TLV in the EAP-Request. The OTP TLV tells the peer to respond with the current OTP (possibly in protected form), and it may carry a challenge plus some other info, like server policies. The EAP server should also include a Server-Info TLV in the request, and must do so if it supports session resumption. The Server-Info TLV identifies the authentication server, holds an identifier for this (new) session, and the peer may use it to find an already existing session with the EAP server. 🔥

c. The peer responds with an EAP-Response of type Nak (3) if it doesn't support POTP-X, or if it doesn't support a version of this method that the server also supports, as shown in the server's Version TLV.

If the peer does support a version that the EAP server also supports, the peer generates an EAP-Response of type POTP-X like this:

  • First, it generates a Version TLV showing the peer's highest supported version within the range of versions the server offered. This Version TLV will be part of the EAP-Response to the EAP server. 💅
  • Next, if the peer's highest supported version equals the EAP server's, and the EAP server sent a Server-Info TLV, the peer checks whether it has a saved session with the EAP server. If an existing session with the server is found, and session resumption is possible (the Server-Info TLV may explicitly disallow it), the peer calculates new session keys (if the session is a protected-mode session) and responds with a Resume TLV and the Version TLV. 🌸
  • Otherwise, if the peer's highest supported version equals that of the EAP server, and the received EAP-Request message contains an OTP TLV, the peer requests (possibly through user interaction) the OTP token to calculate a one-time password. That calculation uses the info in the received EAP-Request (which could, for example, carry a challenge), the current token state (e.g., token time), a shared secret (the "seed"), and a user-provided PIN. Depending on the OTP token type, some of the info in the EAP-Request may not be used in the calculation, and the PIN may be optional too. If the received OTP TLV has the P bit set (see below), the peer combines the token-provided OTP with other info and hands the combined data to a key derivation function. That function generates several keys, and one of them is used to calculate a Message Authentication Code (MAC) on the received message, together with some other info. The resulting MAC, plus some additional info, goes into an OTP TLV (with the P bit set), which is sent in a response to the EAP server together with the Version TLV. If the P bit is not set in the received OTP TLV, the peer instead puts the calculated OTP value directly in an OTP TLV, which is then sent to the EAP server together with the Version TLV. 🔐
  • Finally, if the peer's highest supported version differs from the server's, or if the server didn't provide any TLVs besides the Version TLV in its initial request, the peer just sends back the generated Version TLV as an EAP-Response to the EAP server. ✨

d. If the EAP server receives an EAP-Response of type Nak (3), the session negotiation failed, and the EAP server may try another EAP method. Otherwise, the EAP server checks the peer's supported version. If the peer didn't support the highest version the server supports, the server will send a new EAP-Request with TLVs adjusted for that version. Otherwise, assuming the EAP server did send additional TLVs in its initial EAP-Request, the EAP server will attempt to authenticate the peer based on the response provided in c). Depending on the result of that authentication, the EAP server may do one of the following:

  • send a new EAP-Request of type POTP-X to the peer indicating that session resumption wasn't possible, and ask for a new OTP (this is the case when the peer responded with a Resume TLV and the session indicated in the Resume TLV wasn't valid),
  • send a new EAP-Request of type POTP-X to the peer (e.g., to ask for the next OTP),
  • accept the authentication (and send an EAP-Request message containing a Confirm TLV to the peer if the received response has the P bit set or was a successful attempt at a protected-mode session resumption; otherwise, send an EAP-Success message to the peer), or
  • fail the authentication (and send an EAP-Failure message -- possibly preceded by an EAP-Request message of type Notification (2) -- to the peer). 💀

e. If the peer receives an EAP-Success or an EAP-Failure message, the protocol run is finished. If the peer receives an EAP-Request of type Notification, it responds as specified by RFC 3748 [1]. If the peer receives an EAP-Request of type POTP-X with a Confirm TLV, it attempts to authenticate the EAP server using the provided data. If the authentication is successful, the peer responds with an EAP-Response of type POTP-X with a Confirm TLV. If it's unsuccessful, the peer responds with an empty EAP-Response of type POTP-X. If the peer receives an EAP-Request of type POTP-X containing some other TLVs, it continues as specified in c) above (though no version negotiation will take place in this case) or as described for those TLVs. 🫶

f. When an EAP server, which has sent an EAP-Request of type POTP-X with a Confirm TLV, receives an EAP-Response of type POTP-X with a Confirm TLV present, it can go one of two ways. If it has detected that there's a need to send additional EAP-Requests of type POTP-X, it shall enter a "protected state", where from then on, all POTP-X TLVs must be encrypted and integrity-protected before being sent (at this point, the parties shall have calculated a master session key as described in Section 4.5). One reason to keep the POTP-X conversation going after the Confirm TLV exchange could be that the user needs to update her OTP PIN, so the EAP server needs to send a New PIN TLV. At that point, the handshake is back at step c) above (except for the version negotiation and the protection of all TLVs). If there's no need to send additional EAP-Request packets, the EAP server shall instead send an EAP-Success method to the peer to indicate successful protocol completion. The EAP server may not continue the conversation unless it indicates its intent to do so in the Confirm TLV. 👑

An EAP server, which has sent an EAP-Request of type POTP-X with a Confirm TLV and receives an EAP-Response of type POTP-X that is empty (i.e., does not contain any TLVs), shall respond with an EAP-Failure and terminate the handshake. 🙈

As implied by the description, steps c) through f) may be carried out a number of times before the exchange is complete. One example is when the authentication server initially requests an OTP, accepts the response from the peer, performs an (intermediary) Confirm TLV exchange, requests the peer to select a new PIN, and finally asks the peer to authenticate with an OTP based on the new PIN (which will again be followed by a final Confirm TLV exchange). 🌈

4.2. Version Negotiation 🎀

The EAP-POTP method provides a version negotiation mechanism that lets implementations stay backward compatible with previous versions of the protocol. This specification documents EAP-POTP protocol version 1. Version negotiation goes like this:

a. In the first EAP-Request of type POTP-X, the EAP server MUST send a Version TLV in which it sets the Highest field to its highest supported version number, and the Lowest field to its lowest supported version number. The EAP server MAY include other TLV triplets, as described below, that are compatible with the Highest supported version number, to optimize the number of round-trips when the peer supports the server's Highest version number. 🍓

b. If the peer supports a version of the protocol that falls within the range of versions the EAP server indicated, it MUST respond with an EAP-Response of type POTP-X that contains a Version TLV with the Highest field set to the highest version the peer supports. The peer MUST also respond to any TLV triplets included in the EAP-Request, if it supported the Highest supported version indicated in the server's Version TLV.

The EAP peer MUST respond with an EAP-Response of type Nak (3) if it doesn't support a version that falls within the range of versions the EAP server indicated. This lets the EAP server use another EAP method for peer authentication. 🙅‍♀️

c. When the EAP server receives an EAP-Response containing a Version TLV from the peer, but the Highest supported version field in the TLV differs from the Highest supported version field the EAP server sent, or when the version is the same as the one originally proposed by the EAP server but the EAP server didn't include any TLV triplets in the initial request, the EAP server sends a new EAP-Request of type POTP-X with the negotiated version and TLV triplets as desired and described herein. 🧠

The version negotiation procedure guarantees that the EAP peer and server will agree to the highest version supported by both parties. If version negotiation fails, use of EAP-POTP won't be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is to proceed. 🥺

🚨 The EAP-POTP version field may be modified in transit by an attacker. It is therefore important that EAP entities only accept EAP-POTP versions according to an explicit policy. 🚨

4.3. Cryptographic Algorithm Negotiation ✨

okay so the algorithms get picked using the Crypto Algorithm TLV 🔐 EAP-POTP has default ones: SHA-256 [3] for digest, AES-CBC [4] for encryption, and HMAC [5] for MAC. bestie, every EAP-POTP implementation MUST support these defaults 💖 An EAP server that only wants the defaults doesn't need to send a Crypto Algorithm TLV at all, which is so efficient 🧚

If the server wants something else, it MUST send the Crypto Algorithm TLV in the initial EAP-Request of type POTP-X that also has an OTP TLV with the P bit set 🎀 The TLV MUST NOT show up in any other EAP-Request in the session. no cap, that's a hard rule 💅

There are two exceptions, and they're giving plot twist 🦋 The first is when the client tried to resume a session, that failed, and so it never looked at a Crypto Algorithm TLV. The second is when the TLV came in the server's first message, but the client picked a lower EAP-POTP version than the highest one the server supports. If either of these happens, the server MUST include the Crypto Algorithm TLV in the first EAP-Request that also has an OTP TLV with the P bit set, sent after the failed resumption or version negotiation 🌸

In the Crypto Algorithm TLV, the server suggests some mix of digest, encryption, and MAC algorithms. If it only wants to negotiate one class, the suggestions for the other classes can be left out, since the default covers them 🍓

The peer MUST include a Crypto Algorithm TLV in an EAP-Response only when all of these are true: an EAP-Request of type POTP-X came in with a Crypto Algorithm TLV, that TLV was allowed to be there, the peer isn't trying to resume an existing session, and the peer and the server agree on at least one non-default algorithm 🫶 If the peer doesn't give a value for a class in its response, the default applies to that class. When a session is being resumed (see the next section), the peer doesn't need to negotiate, because the session already has its set of algorithms ✨ Also, servers MUST fail the session (i.e., send an EAP-Failure) if they get an EAP-Response TLV that has both a Resume TLV and a Crypto Algorithm TLV. that is a hard no 🙈

Obviously, EAP servers and peers MUST NOT suggest any algorithms beyond the ones their policy lets them use 🔥 Policies can also limit which combinations of cryptographic algorithms are okay. iykyk 👑

4.4. Session Resumption 🌈

This method uses session identifiers and server identifiers so a peer can skip a lot of work when it keeps trying to authenticate to the same EAP server within a short window. it's literally made for wireless roaming 🦋

So the peer can find the session tied to the EAP server, an EAP server that supports session resumption MUST send a Server-Info TLV containing a server identifier in its initial EAP-Request of type POTP-X that also has an OTP TLV. The peer can then use that identifier to look things up 💜

Whether the peer tries to continue a previous session is up to the peer, which can make the negotiation shorter 🧚 Usually that decision depends on how much time has passed since the last authentication attempt to that EAP server. If the peer wants to resume, it sends a Resume TLV that identifies the chosen session, plus other contents, as described below 💖

The EAP server then decides, based on the session identifier the peer picked and how much time has passed since the last authentication, whether to allow the resumption or start a new session 🎀

  • If the EAP server is willing to resume a session it set up before, it MUST authenticate the peer based on the contents of the Resume TLV. If that authentication succeeds, the handshake continues in one of two ways:
    • If the session is a protected-mode session, the server MUST respond with a request containing a Confirm TLV. If the Confirm TLV authenticates the EAP server, the peer responds with an empty Confirm TLV, and then the EAP server responds with an EAP-Success message. If the Confirm TLV does not authenticate the EAP server, the peer responds with an empty EAP-Response of type POTP-X. 🫶
    • If the session is not a protected-mode session, meaning it was created from a basic-mode peer authentication, the server MUST respond with an EAP-Success message. ✨

If the peer's authentication fails, the EAP server SHOULD send another EAP-Request that contains an OTP TLV and a Server-Info TLV with the N bit set, to show that no session resumption is possible 🙈 The EAP server MAY also send an EAP-Failure message, possibly after an EAP-Request of type Notification (2). If it does that, the EAP run ends 💀

  • If the EAP server is not willing or able to resume a session it set up before, it responds with another EAP-Request that contains an OTP TLV and a Server-Info TLV with the N bit set (meaning no session resumption) 🍓
Sessions SHOULD NOT be kept around longer than the security of the exchange that created them allows 🚨 For example, if someone could estimate that an attacker could brute-force the OTP in 24 hours, then EAP-POTP session lifetimes should be clearly shorter than that. this is the kind of thing you do not skip, periodt 😭

4.5. Key Derivation and Session Identifiers 🔑

EAP-POTP uses a key derivation function called "PBKDF2" 🧁 PBKDF2 is described in [6], Section 5.2. The PBKDF2 PRF SHALL be set to the negotiated MAC algorithm. The default MAC algorithm, which MUST be supported, is HMAC-SHA256. HMAC is defined in [5], and SHA-256 is defined in [3]. HMAC-SHA256 is the HMAC construct from [5] with SHA-256 as the hash function H. When HMAC-SHA256 is used as a PRF for PBKDF2, the output length shall be 32 octets (i.e., the full output length) 💅

PBKDF2 gives out five keys (see Section 4.11.3 for details on how to calculate these keys) 🌟

  • K_MAC, a MAC key used for mutual authentication and integrity protection 🛡️
  • K_ENC, an encryption key used to protect certain data during the authentication 🔐
  • SRK, a session resumption key only used for session resumption purposes 🦋
  • MSK, a Master Session Key, as defined in [1], and 👑
  • EMSK, an Extended Master Session Key, also as defined in [1]. 🌸

For the default algorithms, K_MAC, K_ENC, and SRK SHALL be 16 octets. For other cases, the key lengths are whatever the negotiated algorithms decide. The MSK and the EMSK SHALL each be 64 octets, in conformance with [1]. So, for the default algorithms, the "dkLen" parameter from Section 5.2 of [6] SHALL be set to 176 (the combined length of K_MAC, K_ENC, SRK, MSK, and EMSK) 🧮

[1] and [16] define usage of the MSK and the EMSK. For a particular use case, see also Appendix C. 📚

4.6. Error Handling and Result Indications ⚠️

EAP doesn't let a peer send an EAP-Response of type Nak (3) inside a method after the first EAP-Request and EAP-Response pair of that method has been exchanged (see [1], Section 2.1) 🙃 So instead, when a peer can't keep going with an EAP-POTP session, the peer MAY answer the outstanding EAP-Request with an empty EAP-Response of type POTP-X, rather than just ending the conversation right away. That way the EAP server can log what went wrong 📝

To make sure the EAP server actually gets that empty EAP-Response, the peer SHOULD wait for the EAP server to reply before it ends the conversation. The EAP server MUST reply with an EAP-Failure. 💔

When EAP-POTP runs in protected mode, the Confirm TLV exchange (Section 4.11.6) acts as a success result indication. When the peer gets a Confirm TLV, it knows the EAP server has authenticated it successfully. And when the EAP server gets the Confirm TLV response from the peer, it knows the peer has authenticated it too 🥰 In protected mode, the peer will not accept an EAP-Success packet unless it has received and validated a Confirm TLV 🔒 The Confirm TLV the EAP server sends to the peer is a "protected result indication" as defined in [1], because it's integrity protected and can't be replayed. The Confirm TLV the peer sends back is, however, not a protected result indication 🙅‍♀️ An empty EAP-POTP response from the peer to the EAP server counts as a failure result indication 💀

4.7. Use of the EAP Notification Method 📣

Unless it's explicitly allowed in the cases below, the EAP Notification method MUST NOT be used within an EAP-POTP session 🚫 The EAP Notification method MAY be used within an EAP-POTP session in these situations:

  • The EAP server MAY send an EAP-Request of type Notification (2) when it has received an EAP-Response containing an OTP TLV and it can't authenticate the user. In that case, once the EAP-Response of type Notification comes back, the EAP server MAY retry the authentication and send a new EAP-Request containing an OTP TLV, or it MAY fail the session and send an EAP-Failure message 🫠
  • The EAP server MAY send an EAP-Request of type Notification (2) when it has received an unacceptable New PIN TLV. In that case, once the EAP-Response of type Notification comes back, the EAP server MAY retry the PIN update and send a new EAP-Request with a New PIN TLV, or it MAY fail the session and send an EAP-Failure message 🔁

4.8. Protection against Brute-Force Attacks ✨

okay so OTPs can be pretty short, which is lowkey a problem 😭. The whole point is that when an attacker has watched an EAP-POTP handshake in protected mode, brute-forcing the OTP has to be so slow and expensive that it's just not worth their time 💅. One way to do that is a big number of iterated hashes in the PBKDF2 function 🔥. Another way is for the client to mix in a value ("pepper") that the attacker doesn't know 🫶. A regular "salt" usually gets sent in the clear, but the pepper stays hidden and can be sent to the EAP server in encrypted form instead 🔐. Here's how it goes in practice:

a. The EAP server says in its OTP TLV whether it supports pepper searching 🔍. It may also tell the peer that a new pepper shall be chosen 🎀.

b. If the peer supports pepper, it checks whether it already has a shared pepper set up with this server 👀.

If it does have a pepper stored for this server, and the server didn't say a new pepper shall be generated, then it uses the existing pepper value, as specified in Section 4.11.3 below, to calculate its OTP TLV response 💖. In this case, the iteration count shall be kept to a minimum, because the security is coming from the pepper, and efficiency is otherwise lost 🧚.

If the peer does not have a pepper stored for this server, but the server indicated support for pepper searching, or the server indicated that a new pepper shall be generated, then the peer generates a random and uniformly distributed pepper of sufficient length (the maximum length supported by the server is provided in the server's OTP TLV) and includes the new pepper in the PBKDF2 computation 🌸.

If the peer does not have a pepper stored for this server, and the server did not indicate support for pepper searching, then a pepper will not be used in the response computation 🙈.

Obviously, if the peer itself doesn't support pepper, then no pepper gets used in the response computation either 💀.

c. In its subsequent Confirm TLV, the EAP server may hand the peer a pepper to use later 🎁. When it does, that pepper is way longer than a peer-chosen one, and it gets encrypted with a key derived from the PBKDF2 computation 🔒.

The procedure above lets either side kick off a pepper update, for example because of policy 📋. Since the pepper basically works like a MAC key, its lifetime should be limited ⏳.

An EAP server that can't store pepper values for every user it authenticates can still support pepper, but the price is extra computation time for pepper searches 🥲. Still, that cost is way lower than what the attacker has to pay, since the server already knows the underlying OTP 👑.

4.9. MAC Calculations in EAP-POTP 🦋

4.9.1. Introduction

in protected mode, EAP-POTP uses MACs for authentication, and also to keep protocol sessions intact 🛡️. This section explains how the MACs get calculated and why the design works the way it does 🧠.

4.9.2. MAC Calculation

in protected mode, and when resuming a previous session, the peer doesn't send its credentials (like one-time passwords or shared keys) straight up 🙅‍♀️. Instead, it sends evidence that it knows them 🕵️‍♀️. That evidence is a MAC over the hash of (certain parts of) the EAP-POTP messages exchanged so far in the session, using a key K_MAC 🔑:

mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))

where

"MAC" is the negotiated MAC algorithm, "K_MAC" is a key derived as specified in Section 4.5, and "msg_hash(msg_1, msg_2, ..., msg_n)" is the message hash defined below of messages msg_1, msg_2, ..., msg_n ✨.

4.9.3. Message Hash Algorithm

okay so to compute the message hash for the MAC, given a sequence of EAP messages msg_1, msg_2, ..., msg_n, these steps shall be carried out 📝:

a. Retransmitted messages get removed from the sequence 🗑️.

Note: The resulting sequence of messages must be an alternating sequence of EAP Request and EAP Response messages. 🔁

b. The contents of each message (so, starting from the EAP "Type" field and skipping the EAP "Code", "Identifier", and "Length" fields) get concatenated together into one string 🧵.

c. User identifier TLVs MUST NOT be included in the hash 🙅‍♀️. This is so a backend service that doesn't know about individual user names can still work 🫶. Any such TLV just gets removed from the message it appeared in 🧹.

d. The resulting string gets hashed with the negotiated hash algorithm 🌈.

4.9.4. Design Rationale

the reason the "Identifier" field is excluded is that the actual transmitted "Identifier" field isn't always visible to the EAP method layer 🤷‍♀️. The reason the "Length" field is excluded is to let an intermediary remove or replace a Username TLV (say, for anonymity or service reasons) before it passes a received response on to an authentication server 🎭. I know that might sound like bad security practice on the surface, but in practice it can only lead to denial of service, which an attacker who can modify messages in transit can always pull off anyway 😤. By excluding the "Code" field, the hash is just calculated over the applicable sent and received message contents 📦. Leaving out "Code" is considered harmless, because the hash is made over a sequence of POTP-X messages that always alternate between known Code values: 1 (Request) and 2 (Response) 💅.

4.9.5. Implementation Considerations

to save storage space, each EAP entity can partially hash messages as they're sent and received 💾. For example: HashInit(); HashUpdate(message 1); ...; HashUpdate(message n-1); HashFinal(message n) 🧩. This cuts down the state needed for this purpose to just the internal state the negotiated hash algorithm already needs 🧚‍♀️.

4.10. EAP-POTP Packet Format 📦

okay, here's the EAP-POTP packet format at a glance 👀. The fields go from left to right ➡️.

 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      |   Reserved    | TLV-based EAP-POTP message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code 🔢

  • 1 - Request
  • 2 - Response

Identifier 🆔

The Identifier field is 1 octet and helps match responses with requests 🤝. For a more detailed description of this field and how to use it, see [1] 📚.

Length 📏

The Length field is 2 octets and says how long the EAP packet is, counting the Code, Identifier, Length, Type, Version, Flags, and TLV-based EAP-POTP message fields 🧮.

Type 🏷️

Identifies use of a particular OTP algorithm with EAP-POTP 🔐.

Reserved 🚧

This octet is reserved for future use. It SHALL be set to zero for this version. Recipients SHALL ignore this octet for this version of EAP-POTP 🙃.

TLV-based EAP-POTP message 💌

This field will contain 0, 1, or more Type-Length-Value triplets defined as follows (this is similar to the EAP-TLV TLVs defined in PEAPv2 [17], and the explanation of the generic fields is borrowed from that document) 🤍.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|          TLV Type         |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M 🚦

  • 0 - Non-mandatory TLV
  • 1 - Mandatory TLV

The TLVs inside EAP POTP-X carry parameters between the EAP peer and the EAP server 🚚. An EAP peer might not implement every TLV that an EAP server supports, so for interoperability there's a special TLV that lets an EAP server find out whether the EAP peer supports a given TLV 🕵️.

The mandatory bit in a TLV says that if the peer or server doesn't support the TLV, it MUST send a NAK TLV in response, and all other TLVs in the message MUST be ignored 🚫. If an EAP peer or server runs into an unsupported TLV marked as non-mandatory (so, optional), it MUST NOT send a NAK TLV just for that reason 🙅‍♀️.

The mandatory bit doesn't mean the peer or server has to understand what's inside the TLV 🧐. The right response to a supported TLV whose content it doesn't understand is defined by the specification of that particular TLV 📜.

R 🔮

Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of the EAP-POTP 🌙.

TLV Type 🗂️

these are the TLV types defined for use with EAP-POTP 💜:

 0 - Reserved for future use
 1 - Version
 2 - Server-Info
 3 - OTP
 4 - NAK
 5 - New PIN
 6 - Confirm
 7 - Vendor-Specific
 8 - Resume
 9 - User Identifier
10 - Token Key Identifier
11 - Time Stamp
12 - Counter
13 - Keep-Alive
14 - Protected
15 - Crypto Algorithm
16 - Challenge

These TLVs are defined in the following 👇. With the exception of the NAK TLV, a particular TLV type MUST NOT appear more than once in a message of type POTP-X 🚨.

Length 📐

The length of the Value field in octets 🔢.

Value 🎁

The value of the TLV 💖.

4.11. EAP-POTP TLV Objects 🌟

4.11.1. Version TLV 💖

Okay so the Version TLV is the one that carries the info about which EAP-POTP method version is supported 🎀 This TLV MUST be present in the initial EAP-Request of type POTP-X from the EAP server and in the initial response of type POTP-X from the peer. It MUST NOT be present in any subsequent EAP-Request or EAP-Response in the session. The Version TLV MUST be supported by all peers, and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. The version negotiation procedure is described in detail in Section 4.2. ✨

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|          TLV Type         |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Reserved    |    Highest    |    Lowest     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M 1 - Mandatory TLV 🌸

R Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type 1

Length 3 in EAP-Requests, 2 in EAP-Responses

Reserved Reserved for future use. This octet MUST be set to zero for this version. Recipients SHALL ignore this octet for this version of EAP-POTP.

Highest This field contains an unsigned integer representing the highest protocol version supported by the sender. If a value provided by a peer to an EAP server falls between the server's "Highest" and "Lowest" supported version (inclusive), then that value will be the negotiated version for the authentication session. 🦋

Lowest This field contains an unsigned integer representing the lowest version acceptable by the EAP server. The field MUST be present in an EAP-Request. The field MUST NOT be present in an EAP-Response. A peer SHALL respond to an EAP-Request of type POTP-X with an EAP-Response of type Nak (3) if the peer's highest supported version is lower than the value of this field. 💅

This document defines version 1 of the protocol. Therefore, EAP server implementations conforming to this document SHALL set the "Highest" field to 1. Peer implementations conforming to this document SHALL set the "Highest" field to 1. 👑

4.11.2. Server-Info TLV 🧚

The Server-Info TLV carries information about the EAP server and the session (when applicable). It provides one piece in the framework for fast session resumption. 🫶

This TLV SHOULD always be present in an EAP-Request of type POTP-X that also carries an OTP TLV, as long as the peer has not been authenticated, and MUST be present in such a request if the server supports session resumption. It MUST NOT be present in any other EAP-Request of type POTP-X or in any EAP-Response packets. This TLV type MUST be supported by all peers conforming to this specification and MUST NOT be responded to with a NAK TLV (this is not to say that all peers need to support session resumption, only that they cannot respond to this TLV with a NAK TLV). 🙈

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|          TLV Type         |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Reserved  |N|            Session Identifier                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Session Identifier (continued)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)|             Nonce ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Server Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M 1 - Mandatory TLV 🌸

R Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type 2

Length 25 + length of Server Identifier field

Reserved Reserved for future use. All 7 bits MUST be set to zero for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

N The N bit signals that the peer MUST NOT attempt to resume any session it has stored associated with this server. 🍓

Session Identifier An 8-octet identifier for the session about to be negotiated. Note that, in the case of session resumption, this session identifier will not be used (the session identifier for the resumed session will continue to be used).

Nonce A 16-octet nonce chosen by the server. During session resumption, this nonce is used when calculating new K_ENC, K_MAC, SRK, MSK, and EMSK keys as specified below. 🔥

Server Identifier An identifier for the authentication server. The peer MAY use this identifier to search for a stored session associated with this server, or to associate the session to be negotiated with the server. The value of the identifier SHOULD be chosen so as to reduce the risk of collisions with other EAP server identifiers as much as possible. One possibility is to use the DNS name of the EAP server. The identifier MAY also be used by the peer to select a suitable key on the OTP token (when there are multiple keys available). 💜

The identifier MUST NOT be longer than 128 octets. The identifier SHALL be a UTF-8 [7] encoded string of printable characters (without any terminating NULL character). 🌈

4.11.3. OTP TLV 🎀

In an EAP-Request, the OTP TLV is used to request an OTP (or a value derived from an OTP) from the peer. In an EAP-Response, the OTP TLV carries an OTP or a value derived from an OTP. ✨

This TLV type MUST be supported by all peers and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. The OTP TLV MUST NOT be present in an EAP-Request of type POTP-X that contains a New PIN TLV. Further, the OTP TLV MUST NOT be present in an EAP-Response of type POTP-X unless the preceding EAP-Request of type POTP-X contained an OTP TLV and it was valid for it to do so. Finally, an OTP TLV MUST NOT be present in an EAP-Response of type POTP-X that also contains a Resume TLV. The OTP TLV is defined as follows: 💖

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|          TLV Type         |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Reserved    |A|P|C|N|T|E|S| Pepper Length |Iteration Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Iteration Count (cont.)            |  Auth. Data   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M 1 - Mandatory TLV 🌸

R Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type 3

Length 7 + length of Authentication Data field

Reserved Reserved for future use. All 9 bits SHALL be set to zero (0) for this version. Recipients SHALL ignore these bits for this version of EAP-POTP.

A The A bit MUST be set in an EAP-Request if and only if the request immediately follows an EAP-Response of type POTP-X containing a New PIN TLV (see Section 4.11.5), and the new PIN in the response was accepted by the EAP server. In this case, the A bit signals that the EAP-server has accepted the PIN, and that the peer SHALL use the newly established PIN when calculating the response (when applicable). The A bit MUST NOT be set if the S bit is set. If a request has both the S bit and the A bit set, the peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message. 🦋

In an EAP-Response, the A bit, when set, indicates that the OTP was calculated with the use of the newly selected user PIN. The A bit MUST be set in a response if and only if the EAP-Request which triggered the response contained an OTP TLV with the A bit set. 💅

P In an EAP-Request, the P bit indicates that the OTP in the response MUST be protected. Use of this bit also indicates that mutual authentication will take place, as well as generation of keying material. It is RECOMMENDED to always set the P bit. If a peer receives an EAP-Request with an OTP TLV that does not have the P bit set, and the peer's policy dictates protected mode, the peer MUST respond with an empty POTP-X EAP-Response message. All peers MUST support protected mode. 👑

In an EAP-Response, this bit indicates that the provided OTP has been protected (see below). The P bit MUST be set in a response (and hence the OTP MUST be protected) if and only if the EAP-Request that triggered the response contained an OTP TLV with the P bit set. 🫶

In an 802.1x EAP over LAN (EAPOL) environment (this includes wireless LAN environments), the P bit MUST be set, or, alternatively, the EAP-POTP method MUST be carried out inside an authenticated tunnel that provides a cryptographic binding with inner EAP methods such as the one provided by PEAPv2 [17]. 🌸

C The C bit carries meaning only when the OTP algorithm in question makes use of server challenges. For other OTP algorithms, the C bit SHALL always be set to zero. 🧚

In an EAP-Request, the C bit ("Combine") indicates that the OTP SHALL be calculated using both the provided challenge and internal state (e.g., current token time). The OTP SHALL be calculated based only on the provided challenge (and the shared secret) if the C bit is not set, and a challenge is present. The returned OTP SHALL always be calculated based on the peer's current state (and the shared secret) if no challenge is present. If the C bit is set but no challenge is provided, the peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message. 🍓

In an EAP response, this bit indicates that the provided OTP has been calculated using a provided challenge and the token state. The C bit MUST be set in a response if and only if the EAP-Request that triggered the response contained an OTP TLV with the C bit set and a challenge. 💜

N

In an EAP-Request, the N bit is like the server saying "nah, use the NEXT token state, not the current one" 🦋. The OTP to calculate SHALL be based on the next token "state", not the current one. For a time-based token, that's the next time slot ⏰. For an event-based token, it could mean the next counter value, if counter values are used 🔢. This bit will normally not be set in initial EAP-Request messages, but it may be set in subsequent ones 💅. The N bit carries no meaning in an EAP-Request if a challenge is present and the C bit is not set, and in that case it SHALL be set to 0 🙅. If a request has the N bit set and also contains a challenge, but no C bit, the peer SHALL regard the request as invalid and return an empty POTP-X EAP-Response message 💀. Lowkey the most important part: setting the N bit in an EAP-Request will normally advance the internal state of the token 🔥.

In an EAP-Response, the N bit, when set, means the OTP was calculated using the next token "state" (as explained above), not the current one 🎀. The N bit MUST be set in a response if and only if the EAP-Request that triggered the response contained an OTP TLV with the N bit set. No wiggle room, bestie 😭.

T

The T bit only matters for OTP methods that normally put a user PIN into the OTP computation 🔐.

In an EAP-Request, the T bit, when set, means the OTP to calculate MUST NOT include a user PIN 🚫.

In an EAP-Response, the T bit, when set, means the OTP was calculated without a user PIN. The T bit MUST be set in a response if and only if the EAP-Request that triggered the response contained an OTP TLV with the T bit set. Also, client policy may prohibit PIN-less calculations. In those cases, the client MAY respond with an empty POTP-X EAP response message 🧚.

E

In an EAP-Request, the E bit, when set, means the peer MUST NOT use any stored pepper value associated with this server in the PBKDF2 computation. Instead, it MUST generate a new pepper (if the peer supports it) and/or use the iteration count parameter to protect the OTP. If the server's Max Pepper Length is 0, then the peer MUST rely on the iteration count only to protect the OTP 🛡️. This bit will usually not be set in initial EAP-Request messages, but it may be set in subsequent ones, for example if the server, upon receiving an OTP TLV with a pepper identifier, detects that it doesn't have a pepper with that identifier in storage 🕵️. This bit carries no meaning, and MUST be set to zero, when the P bit is not set. If a request has the E bit set but not the P bit, a peer SHALL regard the request as invalid and return an empty POTP-X EAP-Response message.

In an EAP-Response, the E bit indicates that the response was calculated without any stored pepper value 🫶.

S

In an EAP-Request, the S bit ("Same") is giving "stay with what you had" 💜. When it's set, the peer SHOULD calculate its response based on the same OTP value that was used for the preceding response. This bit MAY be set when the EAP server has received an OTP TLV from the peer protected with a pepper that the server no longer has. The server hasn't tried validating the data, so the EAP peer doesn't need to fetch a new OTP value 🍓. This bit carries no meaning, and MUST be set to zero, when the E bit is not set. A peer SHALL regard a request where the S bit is set but not the E bit as invalid, and return an empty POTP-X EAP-Response message. Further, the S bit MUST NOT be set when the A bit also is set; see above.

In an EAP-Response, the S bit is never set 🙈.

Pepper Length

This octet SHALL be present if and only if the P bit is set ✨. When present, it contains an unsigned integer with a value between 0 and 255 (inclusive). In an EAP-Request, the integer is the maximum length (in bits) of a client-generated pepper that the server is prepared to search for. Peers MUST NOT generate peppers longer than this value. If the value is set to zero, it means the peer MUST NOT generate a pepper for the PBKDF2 calculation. In an EAP-Response, it shows the length of the pepper that was used 🌈.

Iteration Count

These 4 octets SHALL be present if and only if the P bit is set. When present, they contain an unsigned, 4-octet integer in network byte order 🧮. In an EAP-Request, the integer is the maximum iteration count the peer may use in the PBKDF2 computation. Peers MUST NOT use iteration counts higher than this value. In an EAP-Response, it shows the actual iteration count that was used 💖.

Note regarding the Pepper Length and Iteration Count parameters: A peer MUST compare these policy parameters provided by the EAP server with local policy, and MUST NOT continue the handshake if using the EAP server's suggested parameters would result in lower security than the client's acceptable policy 🚨. If the security given by the EAP server's policy parameters is higher than the security level from the peer's local policy, the client SHOULD use the server's parameters (within reason, because active attackers could otherwise run simple denial-of-service attacks against peers or servers, e.g., by providing unreasonably high values for the iteration count) 🙅‍♀️. Note that the server-provided parameters only apply when the peer cannot use, or doesn't have, a previously provided server-provided pepper. If a peer can't continue the handshake because the server's policy is unacceptable, it MUST return an empty POTP-X EAP-Response message 💅.

Authentication Data

EAP-Request: In an EAP-Request, the Authentication Data field, when present, contains an optional "challenge" 🎯. The challenge is an octet string that SHOULD be uniquely generated for each request in which it is present (i.e., it is a "nonce"), and SHOULD be 8 octets or longer. To avoid fragmentation (i.e., EAP messages longer than the minimum EAP MTU size; see [1]), the challenge MUST NOT be longer than 64 octets. When the challenge is not present, the OTP is calculated on the current token state only. The peer MAY ignore a provided challenge if and only if the OTP token the peer is interacting with can't include a challenge in the OTP calculation. In that case, EAP server policies decide whether to accept the provided OTP value 🧠.

EAP-Response: The following applies to the Authentication Data field in an EAP-Response:

  • When the P bit is not set, the peer SHALL directly place the OTP value calculated by the token in the Authentication Data field. In this case, the EAP server MUST NOT send a Confirm TLV upon successful authentication of the peer (instead, it sends an EAP-Success message) 🎉.
  • When the P bit is set, the peer SHALL populate this field as follows. After the token has calculated the OTP value, the peer SHALL compute:
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(otp, salt | pepper
| auth_id, iteration_count, key_length)

where:

  • "|" denotes concatenation.
  • "otp" is the already computed OTP value.
  • "salt" is a 16-octet nonce.
  • "pepper" is an optional nonce (at most 255 bits long and, if necessary, padded to be a multiple of 8 bits long; see below) included to complicate the task of finding a matching "otp" value for an attacker 🕵️.
  • "auth_id" is an identifier (at most 255 octets in length) for the authenticator (i.e., the network access server) as reported by lower layers and as specified below.
  • "iteration_count" is an iteration count chosen so that the computation time on the peer is acceptable (based on the server's indicated policy and the peer's local policy), while an attacker who has observed the response and started searching for a matching OTP will be sufficiently slowed down. The "iteration_count" value MUST be chosen to provide a suitable level of protection (e.g., at least 100,000) unless a server-provided pepper is being used, in which case it SHOULD be 1 🐢.
  • "key_length" is the combined length of the desired key material, in octets. When the default algorithms are used, key_length is 176.

The "pepper" values are only included in PBKDF2 calculations and are never sent to EAP servers (though peers do send their length, in bits) 🤫. As mentioned above, their purpose is to slow down an attacker's search for a matching OTP without slowing down the peer, which iterated hashes do. If the pepper was generated by the peer and the chosen pepper length in bits is not a multiple of 8, then the pepper value SHALL be padded to the left with '0' bits up to the nearest multiple of 8 before being used in the PBKDF2 calculation. This keeps the input to the calculation made of whole octets 🧩. For example, if the chosen pepper length is 4, the pepper value is padded to the left with 4 '0' bits to form an octet before being used in the PBKDF2 calculation.

When a pepper is used, it is RECOMMENDED that the length of the pepper and the iteration count are chosen so that it is computationally infeasible or unattractive for an attacker to brute-force search for the given OTP within the lifetime of that OTP 🔥.

As mentioned previously, a peer MUST NOT include a newly generated pepper value in the PBKDF2 computation if the server did not indicate its support for pepper searching in this session. If the server did not indicate support for pepper searching, the PBKDF2 computation MUST be carried out with a sufficiently higher number of iterations to compensate for the lack of pepper (see further Appendix D) 🙃.

A server may, in an earlier session, have transferred a pepper value to the peer in a Confirm TLV (see below). When this is the case, and the peer still has that pepper value stored for this server, the peer MUST NOT generate a new pepper but MUST, instead, use this transferred pepper value in the PBKDF2 calculations. The only exception is when a local policy (e.g., a timer) dictates that the peer must switch to a new pepper, and the server indicated support for pepper searching 🔄.

The following applies to the auth_id component:

  • For dial-up, "auth_id" SHALL be either the empty string or the phone number called by the peer. The phone number SHALL be specified in the form of a URL conformant with RFC 3966 [8], e.g., "tel:+16175550101". Processing of received phone numbers SHALL be conformant with RFC 3966 (this assumes that "tel" URIs will be shorter than 256 octets, which would normally be the case) 📞.
  • For use with IEEE 802.1X, auth_id SHALL be either the empty string or the MAC address of the authenticator in canonical binary format (6 octets). 💖
  • For IP-based EAP, auth_id SHALL be either the empty string or the IPv4 or IPv6 address of the authenticator as seen by the peer and in binary format (4 or 16 octets, respectively). Like, the IPv4 address 192.0.2.5 would be C0 00 02 05 in hex, and the IPv6 address 2001:DB8::101 would be 20 01 0D B8 00 00 00 00 00 00 00 00 00 00 01 01 in hex. 🦋

Note: Putting the authenticator's identifying info into the computation helps protect against man-in-the-middle attacks, where a rogue authenticator tries to intercept and forward the Authentication Data so it can impersonate the peer at a legit authenticator. (See also the spoofed authenticator address stuff in Section 6, because it's connected! 🧚) For these reasons, a peer SHOULD NOT set the auth_id component to the empty string unless it's unable to learn the authenticator's identifying info. In those cases, the EAP server's policy decides whether or not the session can continue. 🫶

Okay, here's an example. When otp = "12345678", salt = 0x54434534543445435465768789099880, pepper is not used, auth_id = "192.0.2.5", iteration_count = 2000 (decimal), and key_length = 176 (decimal), the input to the PBKDF2 calculation is (first two parameters in hex, line wrapped for readability):

(3132333435363738, 54434534543445435465768789099880 |
c0000205, 2000, 176)

As described, when the default algorithms are used, K_MAC is the first 16 octets of the PBKDF2 output, K_ENC is the next 16 octets, MSK is the following 64 octets, EMSK is the next 64 octets, and SRK is the final 16 octets. Using K_MAC, the peer calculates:

mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))

as specified in Section 4.9, where msg_1, msg_2, ..., msg_n is a sequence of all EAP messages of type POTP-X exchanged so far in this session, as sent and received by the peer. (For the peer's initial MAC, it'll typically be just one message: the EAP server's initial EAP-Request of type POTP-X. 🌸)

The peer then puts the first 16 octets of mac in the Authentication Data field, followed by the salt value, followed by one octet representing the length of the auth_id value in octets, followed by the actual auth_id value in binary form, and optionally followed by a pepper identifier (only when the peer used a pepper value previously provided by the EAP server). Pepper identifiers, when present, are always 4 octets. All variables SHALL be present in the form they were input to the PBKDF2 algorithm. This makes the Authentication Data field 33 + (length of auth_id in octets) + (4, for pepper identifier, when present) octets long. 📏

Continuing the previous example, the Authentication Data field gets populated with (in hex, line wrapped for readability):

< 16 octets of mac > | 54434534543445435465768789099880 |
04 | c0000205

Note: Since in this case (i.e., when the P bit is set), successful authentication of the peer by the EAP server will be followed by an EAP-Request of type POTP-X containing a Confirm TLV for mutual authentication, the peer MUST save either all the input parameters to the PBKDF2 computation or the keys K_MAC, K_ENC, SRK, MSK, and EMSK (recommended, since they'll be used later). This is because the peer can't be guaranteed to generate the same OTP value again. For that same reason (the Confirm TLV from the EAP server), the peer MUST also store either the hash of the contents of the sent EAP-Response or the EAP-Response itself (but see the note above about not including any User Identifier TLVs in the hash computation). 🔐

Now, given a set of possible OTP values, the authentication server verifies an authentication request from the peer by computing:

K_MAC' | K_ENC' | MSK' | EMSK' | SRK' = PBKDF2 (otp',
  salt | pepper' | auth_id, iteration_count, key_length)

for each possible OTP value otp' and each possible pepper value pepper', plus the provided values for salt, authenticator identity, and iteration count, as well as the applicable key length (default: 176). Note: Doing the computation for each possible pepper value implements the pepper search mentioned elsewhere in this document. Also, the EAP server may accept more than one OTP value at a given time, e.g., due to clock drift in the token. If the given pepper length isn't a multiple of 8, each tested pepper value gets padded to the left to the nearest multiple of 8, the same way the peer did it. If the server already shares a secret pepper value with this peer, there's obviously only one possible pepper value, and the server finds it based on the pepper_identifier the peer provided. The server SHALL send a new EAP-Request of type POTP-X with an OTP TLV with the E bit set if the peer provided a pepper identifier unknown to the server. 👀

For each K_MAC', the EAP server computes:

mac' = MAC(K_MAC', msg_hash(msg_1', msg_2', ..., msg_n'))

where MAC is the negotiated MAC algorithm, msg_hash is the message hash algorithm defined in Section 4.9, and msg_1', msg_2', ..., msg_n' are the same messages the peer used for its message hash, but this time as sent and received by the EAP server. If the first 16 octets of mac' match the first 16 octets in the Authentication Data field of the EAP-Response in question, and the provided authenticator identity is acceptable (e.g., it matches the EAP server's view of the authenticator's identity), then the peer is authenticated. ✅

If authentication succeeds, the authentication server then tries to authenticate itself to the peer using the Confirm TLV (see below). If authentication fails, the EAP server MAY send another EAP-Request of type POTP-X containing an OTP TLV to the peer, or it MAY send an EAP-Failure message (in both cases, possibly preceded by an EAP-Request of type Notification). 💅

4.11.4. NAK TLV ✨

Presence of this TLV indicates that the peer did not support a received TLV with the M bit set. This TLV may occur 0, 1, or more times in an EAP-Response of type POTP-X. Each occurrence flags the non-support of a particular received TLV. 🙈

The NAK TLV MUST be supported by all peers and all EAP servers conforming to this specification, and it MUST NOT be responded to with a NAK TLV. Receipt of a NAK TLV by an EAP server MAY cause an authentication to fail, and the EAP server to send an EAP-Failure message to the peer. 💀

Note: The definition of the NAK TLV here matches the definition made in [17], and it has the same type number. Field descriptions are copied from that document, with some minor modifications. 🎀

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|          TLV Type         |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Vendor-Id                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            NAK-Type           |           TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

  • 1 - Mandatory TLV

R

  • Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type

  • 4

Length

  • 6 + cumulative total length of embedded TLVs

Vendor-Id

  • The Vendor-Id field is 4 octets, and contains the Vendor-Id of the TLV that wasn't supported. The high-order octet is 0 and the low-order 3 octets are the Structure of Management Information (SMI) Network Management Private Enterprise Code of the Vendor in network byte order. The Vendor-Id field MUST be zero for TLVs that aren't Vendor-Specific TLVs. For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code. 🏢

NAK-Type

  • The type of the unsupported TLV. The TLV MUST have been included in the most recently received EAP message. 🔍

TLVs

  • This field contains a list of TLVs, each of which MUST NOT have the mandatory bit set. These optional TLVs can be used in the future to communicate why the offending TLV was determined to be unsupported. 🌈

4.11.5. New PIN TLV ✨

Okay so the New PIN TLV is how the EAP server asks the peer for a brand-new user PIN 🎀. In an EAP-Request, the server MAY provide a new PIN, and in the EAP-Response the peer sends back the PIN it chose 💅. This TLV may be used by an EAP server when policy says the peer (user) needs to change a PIN tied to the OTP Token 🔐.

This TLV type SHOULD be supported by peers and EAP servers that conform to this spec 🫶. The New PIN TLV MUST NOT be sent by an EAP server unless the peer has been authenticated 🙈 no sending it to randos! If the peer was authenticated in protected mode, then the New PIN TLV MUST NOT be present in an EAP-Request until after the exchange of the Confirm TLV (i.e., until after mutual authentication has occurred and keys are in place to protect the TLV) 🔒. The New PIN TLV MUST be sent by a peer if and only if the EAP-Request that triggered the response contained a New PIN TLV, it was valid for the EAP server to send such a TLV in that request, and the TLV is supported by the peer 💜.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved  |Q|A|  PIN Length   |             PIN ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Min. PIN Length|Max. PIN Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the field breakdown, bestie 🧚

M 💫

  • 1 - Mandatory TLV

R 🌸

Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type 🦋

  • 5

Length 📏

2 + length of the PIN field (as specified in the PIN Length field) + (0, 1, or 2)

Note: the final term above is:

  • 0 if none of the optional Min. / Max. PIN Length fields is present in the TLV,
  • 1 if only the Min. PIN Length field is present in the TLV,
  • 2 if both of these optional fields are present in the TLV.

Reserved 🍓

Reserved for future use. All six bits SHALL be set to zero for this version. Recipients SHALL ignore these bits for this version of EAP-POTP.

Q 👑

The Q bit, when set in an EAP-Request, means an accompanying PIN is required, i.e., the peer (user) is not free to choose another PIN 🙅‍♀️. When the Q bit is set, there MUST be an accompanying PIN and the provided PIN MUST be used in subsequent OTP generations. A peer SHALL respond with an empty POTP-X EAP-Response message if the Q bit is set but there is not any accompanying PIN. When the Q bit is not set, any provided PIN is suggested only, and the peer is free to choose another PIN, subject to local policy ✨.

The Q bit carries no meaning, and SHALL be set to zero, in an EAP-Response.

A 🌈

This bit lets methods that distinguish between two different PIN types (e.g., decimal vs. alphanumeric) say whether the augmented set is to be used (when set) or not (when not set) 🔢. The A bit carries no meaning, and SHALL be set to zero, in an EAP-Response.

PIN Length 🔢

This field holds an unsigned integer for the length of the provided PIN. This means the maximum length of a PIN will be 255 octets 💅.

PIN 🔐

In an EAP-Request, depending on the setting of the Q bit, the PIN field MAY be empty. If it's empty, the peer (user) will need to choose a PIN subject to local and (any) provided policy. When the PIN field is not empty, it MUST consist of UTF-8 encoded printable characters without a terminating NULL character.

In an EAP-Response, the PIN value SHALL consist of a UTF-8 encoded string of printable characters without a terminating NULL character.

The peer accepts a PIN suggested by the EAP server by replying with the same PIN, but MAY replace it with another one, depending on the server's setting of the Q bit 🔄. The length of the PIN is application-dependent, and so are any other PIN requirements, e.g., allowed characters. The peer MUST be prepared to receive a repeated request for a new PIN, as described above, if the EAP server, for some reason, does not accept the received PIN 😭. Such a request MAY be preceded by an EAP-Request of type Notification (2) that gives the user information about the reason for the rejection. Mechanisms for passing knowledge about PIN requirements from the EAP server to the peer (beyond what's specified for this TLV, such as maximal and minimal PIN length) are outside the scope of this document 🚫. However, some information MAY be provided in notification messages sent from the EAP server to the peer, as per above.

Min. PIN Length 📉

This field MAY be present in an EAP-Request. This field MUST NOT be present in an EAP-Response. It SHALL be interpreted as an unsigned integer in network byte order, representing the minimum length allowed for a new PIN 🧮.

Max. PIN Length 📈

This field MUST NOT be present in an EAP-Request unless the Min. PIN Length field is present, in which case it MAY be present. The field MUST NOT be present in an EAP-Response. It SHALL be interpreted as an unsigned integer in network byte order, representing the maximum length allowed for a new PIN. The value of this field, when present, MUST be equal to, or larger than, the value of the Min. PIN Length field 🎀.

4.11.6. Confirm TLV ✨

okay bestie, the Confirm TLV is the big mutual-trust moment 🫶 When it shows up in a request, the EAP server is basically saying "I've authenticated you, now let me prove who I am" 💅 When it shows up in a response, the peer has verified the EAP server, and the calculated keys (K_MAC, K_ENC, MSK, EMSK, and SRK) are finally ready to use 🔑 no cap, this is the payoff.

The rules are strict, so listen up 👑 The Confirm TLV MUST NOT appear together with any other TLV in an EAP-Request message of type POTP-X, and it MUST NOT be sent unless the peer has been authenticated through an OTP TLV with the P bit set, or through a Resume TLV whose underlying session was established in protected mode 🔒 The Confirm TLV MUST be present in an EAP-Response if and only if the request that triggered the response contained a Confirm TLV, it was legal for it to do so, and the Confirm TLV authenticated the EAP server to the peer. If the peer wasn't able to authenticate the server, then it MUST send an empty (i.e., no TLVs present) EAP-Response of type POTP-X 🙈

An EAP server MUST send an EAP-Success message after receiving an EAP-Response of type POTP-X containing a valid Confirm TLV, sent in response to an EAP-Request containing a Confirm TLV where the C bit was not set ✨ A peer MUST NOT accept an EAP-Success message when it has sent an OTP TLV with the P bit set, unless it has received an acceptable Confirm TLV from the EAP server. Main character energy for the handshake 🦋

This TLV type MUST be supported by all peers and EAP servers conforming to this specification, and it MUST NOT be responded to with a NAK TLV 💜

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved  |C|       Authentication Data ... (16 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pepper Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              IV ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Encrypted Pepper ... (16 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

1 - Mandatory TLV 🧚

R

Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type

6 🎀

Length

17 or 37 + length of IV in requests, 1 in responses.

Reserved

Reserved for future use. These 7 bits SHALL be set to zero (0) for this version. Recipients SHALL ignore these bits for this version of EAP-POTP.

C

The C bit, when set in an EAP-Request, indicates that the EAP server intends to send more EAP-Requests of type POTP-X in this session, after receipt of a Confirm TLV from the peer 🌸

The C bit carries no meaning in EAP-Responses, and MUST NOT be set within them.

Note: An EAP-Response containing a Confirm TLV, sent in response to an EAP-Request containing a Confirm TLV that did not have the C bit set, MUST be followed by an EAP-Success message from the EAP server concluding the handshake. However, when the C bit was set in an EAP-Request, the EAP server MAY send another EAP-Request (containing, for example, a New PIN TLV wrapped in a Protected TLV) rather than an EAP-Success message. Therefore, peers MUST NOT assume that the only EAP message following an EAP-Response of type POTP-X containing a Confirm TLV is EAP-Success. The C bit gives EAP servers a way to indicate their intent to follow the Confirm TLV with more requests, and allows the peer's state machine to adapt to this. 👀

Authentication Data

EAP-Request:

In a request, this field consists of the first 16 octets of (see also Section 4.11.3):

mac_a = MAC(K_MAC', msg_hash(trig_msg))

where

MAC is the negotiated MAC algorithm,

"K_MAC'" has been calculated as described in Section 4.11.3 or (in the case of session resumption) Section 4.11.8, and

"msg_hash" is the message hash algorithm defined in Section 4.9, and "trig_msg" the latest EAP-Response of type POTP-X received from the peer (the one which triggered this request).

Given a saved or recomputed value for K_MAC, the peer authenticates the EAP server by computing

mac'' = MAC(K_MAC, msg_hash(trig_msg'))

where "msg_hash(trig_msg')" is the peer's hash of the EAP-Response message that it sent to the server (and that the server calculated its message hash on). If the first 16 octets of mac'' matches the first 16 octets in the Authentication Data field of the EAP-Request in question, then the EAP server is authenticated. ✅

EAP-Response:

Not used in this version, and SHALL NOT be present in EAP-Responses.

Pepper Identifier

In an EAP-Request, the truncated MAC MAY optionally be followed by an encrypted pepper and its identifier. This initial, 4-octet field identifies a pepper generated by the server.

For this version of EAP-POTP, this field SHALL NOT be present in EAP-Responses.

IV (Initialization Vector)

An initialization vector for the encryption. The length of the vector is dependent on the negotiated encryption algorithm. For example, for AES-CBC, it SHALL be 16 octets. The IV is only present if a pepper is present, and the negotiated encryption algorithm makes use of an IV. This field SHALL NOT be present in EAP-Response messages for this version of EAP-POTP. 🫧

Encrypted Pepper

When present in an EAP-Request, this will be a uniformly distributed and randomly chosen 16-octet pepper generated by the EAP server and encrypted with the negotiated encryption algorithm, using K_ENC as the encryption key and possibly (depending on the encryption algorithm) using an IV (stored in the IV field). This field MUST be present if and only if the Pepper Identifier field is present.

EAP servers are RECOMMENDED to include a freshly generated encrypted pepper (and a corresponding Pepper Identifier) in every Confirm TLV.

This field SHALL NOT be present in EAP-Response messages for this version of EAP-POTP.

When a new pepper is generated by the server and transferred in encrypted form to the peer, then this new pepper value will be stored in the EAP server upon receipt of the Confirm TLV from the peer, and SHOULD be stored with its identifier and associated with the EAP server and the current user in the peer upon receipt of the EAP-Success message. If the peer already had a pepper stored for the EAP server, it SHALL replace it with the newly received one. 🌈

4.11.7. Vendor-Specific TLV 💅

this one's for the vendors 🍓 The Vendor-Specific TLV lets vendors support their own extended attributes that aren't suitable for general usage. A Vendor-Specific TLV can contain one or more inner TLVs, referred to as Vendor TLVs. The TLV-type of a Vendor TLV will be defined by the vendor. All the Vendor TLVs inside a single Vendor-Specific TLV SHALL belong to the same vendor.

This TLV type MAY be sent by EAP servers, as well as by peers, and MUST be supported by all entities conforming to this specification. Conforming implementations may not support specific Vendor TLVs inside a Vendor-Specific TLV, however. They MAY, in this case, respond to the Vendor TLVs with a NAK TLV containing the appropriate Vendor-ID and Vendor TLV type.

The presence of a Vendor-Specific TLV in an EAP-Request or EAP-Response of type POTP-X MUST NOT violate any existing rules for coexistence of TLVs in such requests or responses. If it does, then it will result in an EAP-Failure (when the peer made the violation) or an empty EAP-POTP response (when the EAP-server made the violation). It is left to the definition of specific Vendor-Specific TLVs to further constrain when they are allowed to appear. In particular, EAP-POTP implementations may have policies that completely disallow use of the Vendor-Specific TLV before protected mode mutual authentication has occurred (since the Protected TLV, Section 4.11.15, then can be used to protect all TLVs).

Note: This TLV type has the same definition and TLV type number as the Vendor-Specific TLV in [17], and the description of it is largely borrowed from that document. 📚
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Vendor TLVs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

1 - Mandatory TLV 🧚

R

Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type

7 🎀

Length

4 + cumulative total length of inner Vendor TLVs

Vendor-ID

The Vendor-Id field is 4 octets. The high-order octet SHALL be set to 0, and the low-order 3 octets SHALL be set to the SMI Network Management Private Enterprise Code (see [18]) of the Vendor in network byte order.

Vendor TLVs

This field shall contain vendor-specific TLVs, in a format defined by the vendor. To avoid fragmentation (i.e., EAP messages longer than the minimum EAP MTU size), the field SHOULD NOT be longer than 256 octets.

To ensure interoperability when an EAP entity (peer or server) from vendor A sends a vendor-specific TLV that is not understood by the recipient EAP entity from vendor B, the vendor A entity SHALL, upon receipt of the NAK TLV from the recipient, refrain from usage of the vendor-specific TLV in question for the rest of the handshake, and MUST NOT fail the session due to the receipt of the NAK TLV for the Vendor TLV (i.e., it SHALL continue as if the vendor-specific TLV had not been sent). Additionally, all implementations conformant with this document SHOULD allow use of vendor-specific extensions to be turned off via configuration. 🔧✨

4.11.8. Resume TLV 🔁✨

Okay bestie, the Resume TLV is how a peer says "hey server, can we pick up where we left off?" 🦋 It's MAY be sent by a peer to an authentication server to try session resumption.

This TLV type MUST only be sent in response to an EAP-Request of type POTP-X that contains a Server-Info TLV allowing session resumption. Any EAP server that sends a Server-Info TLV allowing session resumption MUST support the Resume TLV. No skipping this one, periodt 💅

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |               Session Identifier              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Session Identifier (continued)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sess.Id (cont.)|             Authentication Data               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Authentication Data (cont.) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

0 - Non-mandatory TLV 🌸

R

Reserved for future use, so it's just vibes for now. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP. 🫶

TLV Type

8

Length

45

Reserved

Also reserved for future use. This octet SHALL be set to zero (0) for this version, and recipients SHALL ignore it for this version of EAP-POTP. 🍓

Session Identifier

An 8-octet identifier for the session the peer wants to resume. 🧚

Authentication Data

Okay, this is the main character moment 👑. When the peer gets the Server-Info TLV and the N bit is not set, it goes digging for any stored sessions tied to the server named in the Server Name field. If it finds one, it makes a fresh random 16-octet nonce called "c_nonce" and then does this math:

K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(base_key, c_nonce | s_nonce, iteration_count, key_length)

Where:

  • "|" means concatenation.
  • "base_key" is either the current SRK for the session (if the session was created in protected mode) or the OTP that was used when the session was created (if it was created in basic mode).
  • "c_nonce" is that 16-octet nonce the peer just generated.
  • "s_nonce" is the server nonce from the Server-Info TLV.
  • "iteration_count" is whatever number local policy says to use.
  • "key_length" is the combined length of the key material you want, in octets. When the default algorithms are used, key_length is 176.

The iteration count only needs to be 1 (one) when resuming a session that was set up in protected mode, but it MUST be picked to give a suitable level of protection when resuming a session that was set up in basic mode (see also Section 4.11.3). Be safe, not sorry 🔥

Note: Session resumption for basic mode MUST only be carried out in a server-authenticated and protected tunnel that also provides a cryptographic binding for inner EAP methods. This one is non-negotiable, bestie 🙈

Next, the peer calculates:

mac = MAC(K_MAC, msg_hash(resume_req))

Where "MAC" is the negotiated MAC algorithm, and "msg_hash(resume_req)" is the message hash algorithm from Section 4.9, applied to resume_req. That's the EAP server's EAP-Request of type POTP-X that contained the Server-Info TLV allowing session resumption. ✨

Then the peer packs the first 16 octets of the MAC value, then the c_nonce value, then the iteration count value (as a 4-byte unsigned integer in network byte order) into the Authentication Data field. For example, when c_nonce = 0x2b3b1b12babdebebfb43bd7bdfbeb8df and iteration_count = 1, the Authentication Data field gets filled with (in hex):

< 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df | 00000001

The server then checks the peer by doing the same calculations on its side. If that works out, the server MUST send an EAP-Request of type POTP-X containing a Confirm TLV to the peer. If it doesn't work out, the server MUST either send an EAP-Request of type POTP-X containing an OTP TLV and a Server-Info TLV, where the Server-Info TLV says session resumption isn't possible, or send an EAP-Failure. Rough, but at least it's clear 💀

When resuming in basic mode, all the calculated keys SHALL be thrown out once the MAC has been calculated and verified. When resuming in protected mode, the new SRK replaces the stored SRK, and the new MSK and EMSK get exported once the method completes successfully. Fresh keys, fresh start 🌈

4.11.9. User Identifier TLV 🪪💖

The User Identifier TLV carries an identifier for the holder of the OTP token that made the OTP. Usually that's the username, so you know who's who 🧁

At least one of the User Identifier TLV and the Token Key Identifier TLV SHOULD be in the session's first EAP-Response of type POTP-X that also carries an OTP TLV, unless a suitable identity was already sent in an earlier EAP-Response of type Identity (1) or gets figured out some other way (see [1], Section 2). Using the User Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED even when an EAP-Response of type Identity (1) has already been sent. 🎀

If a peer sends both a User Identifier TLV and a Token Key Identifier TLV, the EAP server SHALL read the Token Key Identifier TLV as picking out one particular token key for that user. If the server can't find a token key for the user it was given, it MUST respond with an EAP-Failure. Big oof 😭

This TLV type is sent by peers and MUST be supported by all EAP servers conforming to this specification. The User Identifier TLV MUST NOT be in a response that doesn't also carry an OTP TLV. Not without its plus-one, no way 🙅‍♀️

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       User Identifier ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

1 - Mandatory TLV 💜

R

Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type

9

Length

Length of User Identifier, >= 1

User Identifier

The value SHALL be a UTF-8 encoded string that represents the holder of the token. It MUST NOT be NULL-terminated. The string MUST be less than 128 octets in length. Keep it short and sweet 🍬

4.11.10. Token Key Identifier TLV 🔑🌸

The Token Key Identifier TLV carries an identifier for the token key that was used to generate the OTP. It's basically the key's ID card 🪪

At least one of the User Identifier TLV and the Token Key Identifier TLV SHOULD be in the session's first EAP-Response of type POTP-X, which also carries the OTP TLV, unless a suitable identity was already provided in an earlier EAP-Response of type Identity (1) or is determined by some other means (see [1], Section 2). Using the User Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED even when an EAP-Response of type Identity (1) has been sent. 💅

If a peer sends both a User Identifier TLV and a Token Key Identifier TLV, the EAP server SHALL read the Token Key Identifier TLV as picking out one particular token key for that user. If the server can't find a token key that matches the token key identifier it got, it MUST respond with an EAP-Failure. Stay on the list, or else 🫠

This TLV type is sent by peers and MUST be supported by all EAP servers conforming to this specification. The Token Key Identifier TLV MUST NOT be in a response that doesn't also carry an OTP TLV. Same energy as the last one, babe 🧚

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Token Key Identifier ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

1 - Mandatory TLV 🦋

R

Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type

10

Length

Length of Token Key Identifier, >= 1

Token Key Identifier

An identifier for the OTP token key that was used to generate the OTP. The field MUST be less than 128 octets in length. Short names only, that's the rule 🌷

4.11.11. Time Stamp TLV ⏰🫧

The Time Stamp TLV MAY be sent by peers to make authentications smoother. When it shows up, it carries the time as the OTP Token reported it. ⏱️

An EAP server that follows this spec SHOULD support (aka recognize) this TLV, but it doesn't have to process or act on it. An EAP server that doesn't support this TLV, but gets an EAP-Response with it, MAY ignore the value. The Time Stamp TLV MUST NOT be in any EAP-Responses of type POTP-X other than the ones that also carry an OTP TLV. Only where it belongs, babe 💖

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Time Stamp ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

0 - Non-mandatory TLV ✨

R

Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.

TLV Type

11

Length

Length of Time Stamp field, >= 20 (depending on precision)

Time Stamp

This is the time, as the OTP token reported it, when the OTP used for the accompanying OTP TLV got calculated. The field SHALL hold a UTF-8 encoded value of the XML simple type "dateTime", with time zone info and precision down to at least seconds, like this:

2004-06-16T15:20:02Z

4.11.12. Counter TLV 🔢✨

okay so the Counter TLV is totally optional 💅 Peers MAY send it to make authentications smoother 🦋 When it's there, it carries the token counter value, exactly as the OTP Token reported it 🍓

An EAP server that follows this spec SHOULD support (aka recognize) this TLV, but it doesn't have to process or act on it 🫶 An EAP server that doesn't support it, but gets an EAP-Response with it present, MAY ignore the value 🙈 And the Counter TLV MUST NOT show up in any POTP-X EAP-Responses unless that same response also carries an OTP TLV. Periodt 💅

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Counter ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • M: 0 - Non-mandatory TLV
  • R: Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
  • TLV Type: 12
  • Length: The length of the Counter field, >= 1 (depending on precision)
  • Counter: The counter value, as reported by the OTP token, at which the OTP used for the accompanying OTP TLV was calculated. The counter value SHALL be represented as an unsigned integer in network-byte order, e.g., a counter value of 1030 may be sent as the 2 octets (in hex) 04 06.

4.11.13. Challenge TLV 🎯

The Challenge TLV carries the challenge the token used to calculate the OTP, as the token reported it to the peer 💌 A peer MUST send this TLV if and only if the challenge would otherwise be unknown to the EAP server (for example, if the token or peer modified a received challenge or generated its own challenge). So it's only there when it's actually needed 😌

An EAP server that follows this spec SHOULD support (aka recognize) this TLV, but it doesn't have to process or act on it 🫶 An EAP server that doesn't support it, but gets an EAP-Response with it present, MAY ignore the value 🙈 The Challenge TLV MUST NOT be present in any POTP-X EAP-Responses other than the ones that also carry an OTP TLV 🚫

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Challenge ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • M: 0 - Non-mandatory TLV
  • R: Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
  • TLV Type: 16
  • Length: The length of the Challenge field, >= 1
  • Challenge: The challenge value that was used to calculate the OTP used for the accompanying OTP TLV.

4.11.14. Keep-Alive TLV 💓

The Keep-Alive is used to avoid EAP-POTP timeouts, so nobody gets kicked out mid-convo 🙅‍♀️

The Keep-Alive TLV MAY be sent by a peer to avoid timeouts when the peer has received an EAP-Request containing an OTP TLV or a New PIN TLV and is waiting for the user to respond ⏳ An EAP server MUST send an EAP-Request containing a Keep-Alive TLV when it receives an EAP-Response containing a Keep-Alive TLV and it has an outstanding request that did not contain a Keep-Alive TLV. In this situation the server doesn't need to retransmit its latest outstanding request, but because EAP is synchronous, it still needs to send another request 🔄 Retransmitting the latest outstanding request could be confusing for the peer, since the request would get a new Identifier value 🤯 The Keep-Alive TLV MAY also be sent by an EAP server when the server detects that its processing time will exceed some locally configured threshold and may cause a network timeout. In this case, the peer MUST respond with an EAP-Response containing a Keep-Alive TLV 💅

This TLV type MUST be supported by all peers and all EAP servers conforming to this specification, and it MUST NOT be responded to with a NAK TLV 🚫 The Keep-Alive TLV MUST NOT be sent in any situations other than the ones described above, and it MUST NOT be sent together with any other TLVs defined herein. Implementations SHOULD also follow the recommendations made in Section 4.3 of [1] 📚

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • M: 1 - Mandatory TLV
  • R: Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
  • TLV Type: 13
  • Length: 0

4.11.15. Protected TLV 🔐

The Protected TLV SHALL be used to encrypt individual or multiple TLVs after the Confirm TLV has been successfully exchanged (aka as soon as the calculated keys have been confirmed) 🤫 It's basically a secret envelope that wraps the "ordinary" TLVs inside 💌

This TLV type MAY be sent by EAP servers as well as by peers, and it MUST be supported by all peers conforming to this specification 💜 It SHOULD be supported by all EAP servers conforming to this specification, though it need not be supported if a server will never need to continue a POTP-X conversation after the Confirm TLV exchange 🤷‍♀️

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Authentication Code ... (16 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             IV ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Encrypted TLVs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • M: 1 - Mandatory TLV
  • R: Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
  • TLV Type: 14
  • Length: >32
  • Message Authentication Code (MAC): This field integrity-protects the TLV 🛡️ The MAC SHALL be calculated over the IV and the Encrypted TLVs field like this:
mac = MAC(K_MAC, iv | encrypted_tlvs)

where MAC is the negotiated MAC algorithm, "iv" is the value of the IV field, and "encrypted_tlvs" is the value of the Encrypted TLVs field. The first 16 octets of the MAC are placed in the Message Authentication Code field.

Recipients MUST verify the MAC! If the verification fails, the conversation SHALL be terminated: peers send an empty POTP-X EAP-Response message, and EAP servers send an EAP-Failure message, possibly preceded by an EAP-Request of type Notification. Yikes 😭
  • IV: An initialization vector for the encryption (see below). Its length depends on the negotiated encryption algorithm, e.g., for AES-CBC it shall be 16 octets. Some encryption algorithms may not have any initialization vector at all. An IV, when present, shall be randomly chosen and non-predictable 🎲
  • Encrypted TLVs: This field SHALL contain one or more encrypted POTP-X TLVs. The encryption algorithm SHALL be the negotiated one. Use K_ENC as the encryption key, and use the IV field as the initialization vector (when applicable), to encrypt the concatenation of all the TLVs to be protected 🔒✨

4.11.16. Crypto Algorithm TLV

okay bestie, the Crypto Algorithm TLV is where the algorithm negotiation happens 🔐✨ It's giving "let's pick our favorites together." Section 4.3 has the full deets on how that negotiation works 💅

The server MUST include this TLV in the very first EAP-Request of type POTP-X that carries an OTP TLV indicating protected mode 🔒, assuming the EAP server wants to negotiate algorithms other than the default ones. It MAY also show up in an EAP-Request of type POTP-X that carries an OTP TLV sent after a failed session resumption (in that case, the peer hasn't responded to this TLV yet 🙈). It can also appear when the Crypto Algorithm TLV was already in the initial message from the EAP server, and the client negotiated an EAP-POTP version that's lower than the highest one the EAP server supports 🦋

The Crypto Algorithm TLV MUST NOT be present in any other EAP-Requests 🚫 And it MUST NOT be present in an EAP-Response of type POTP-X unless the EAP-Request right before it also had it AND it was allowed to have it 💀 This TLV MUST be supported by every peer and every EAP server that follows this spec, and it MUST NOT be answered with a NAK TLV. No exceptions, periodt 💖

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |Hash Alg.Length|        Hash Algorithms ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Encr.Alg.Length|             Encryption Algorithms ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |MAC Alg. Length|                  MAC Algorithms ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the breakdown of each field 🧁

  • M: 1 means Mandatory TLV 💪
  • R: Reserved for future use ✨ This bit SHALL be set to zero (0) in this version, and recipients SHALL ignore it for this version of EAP-POTP 🌸
  • TLV Type: 15 🎀
  • Length: >=4. You need at least one class of algorithms, and at least one algorithm in that class 🍓
  • Reserved: Also reserved for future use 🙈 This octet MUST be set to zero for this version, and recipients SHALL ignore this octet for this version of EAP-POTP.
  • Hash Alg. Length: The length of the Hash Algorithms field, in octets 🧮
  • Hash Algorithms: Each octet pair here is one hash algorithm 🔥 An EAP server MAY suggest several hash algorithms. Each algorithm MUST appear only once, and they SHALL be listed in order of priority 👑 Peers MUST supply, at most, one algorithm. If none is present, the default applies 🫶 Here are the values:
        Value
   Octet 1 Octet 2  Hash algorithm
   ------- -------  ----------------------------------
   0x00    0x00     Reserved
   0x00    0x01     SHA-1
   0x00    0x02     SHA-224
   0x00    0x03     SHA-256 (default)
   0x00    0x04     SHA-384
   0x00    0x05     SHA-512
   0x80     -       Vendor-specific (or experimental)

Values 0x8000 and higher are for proprietary vendor-specific algorithms 🦄 Values in the range 0x0006 - 0x7fff get assigned through IANA; see Section 7 📋

  • Encr Alg. Length: The length of the Encryption Algorithms field, in octets 🧮
  • Encryption Algorithms: Each octet pair is one encryption algorithm ✨ An EAP server MAY suggest several encryption algorithms. Each algorithm MUST appear only once, and they SHALL be supplied in order of priority 🌈 Peers MUST supply, at most, one algorithm. If none is present, the default applies 💜 The values:
        Value
   Octet 1 Octet 2  Encryption algorithm
   ------- -------  ------------------------
   0x00    0x00     Reserved
   0x00    0x01     AES-CBC (default) with 128-bit keys and 16-octet IVs
   0x00    0x02     3DES-CBC with 112-bit keys and 8-octet IVs
   0x80     -       Vendor-specific

Values 0x8000 and higher are for vendor-specific proprietary algorithms 🎀 Values in the range 0x0003 - 0x7fff get assigned through IANA; see Section 7 🛠️

  • MAC Alg. Length: The length of the MAC Algorithms field, in octets 🧾
  • MAC Algorithms: Each octet pair is one MAC algorithm 🫧 An EAP server MAY suggest several MAC algorithms. Each algorithm MUST appear only once, and they SHALL be supplied in order of priority 🍭 Peers MUST supply, at most, one algorithm. If none is present, the default applies. The values:
        Value
   Octet 1 Octet 2  MAC algorithm
   ------- -------  -----------------
   0x00    0x00     Reserved
   0x00    0x01     HMAC (default)
   0x80     -       Vendor-specific

Values 0x8000 and higher are for vendor-specific proprietary algorithms 🌷 Values in the range 0x0002 - 0x7fff get assigned through IANA; see Section 7 📌

When HMAC is negotiated, the hash algorithm used for HMAC SHALL be the negotiated hash algorithm. So the HMAC hash is whatever hash got agreed on, no surprises 🧠

5. EAP Key Management Framework Considerations

In line with recommendations made in [16], EAP-POTP defines the following identifiers to be associated with generated key material 🔑

  • Peer-ID: The combined contents of the User Identifier TLV and the Token Key Identifier TLV 🧑‍🤝‍🧑
  • Server-ID: The contents of the Server Identifier field of the Server-Info TLV 🖥️
  • Method-ID: The identifier of the established session. That's the contents of the Session Identifier field of the Server-Info TLV that defined the session 🪪

6. Security Considerations

6.1. Security Claims

Okay, the security claims! 🛡️ In conformance with RFC 3748 [1], EAP-POTP makes the following claims 💅

   Authentication mechanism:  Generic OTP
   Ciphersuite negotiation:   Yes (No in basic variant)
   Mutual authentication:     Yes (No in basic variant)
   Integrity protection:      Yes (No in basic variant)
   Replay protection:         Yes (see below)
   Confidentiality:           Only in the OTP protection variant, and
                              then only OTP values and any information
                              sent after exchange of the Confirm TLV
   Key derivation:            Yes (No in basic variant)
   Key strength:              Depends on size of OTP value, strength of
                              underlying shared secret, strength and
                              characteristics of OTP algorithm, pepper
                              length, iteration count, and whether the
                              method is used within a tunnel such as
                              PEAPv2.  For some illustrative examples,
                              and a further discussion of this, see
                              Appendix D.
   Dictionary attack prot.:   N/A (Human-selected passwords not used)
   Fast reconnect:            Yes
   Crypt. binding:            N/A (EAP-POTP is not a tunnel method)
   Session independence:      Yes
   Fragmentation:             N/A (Packets shall not exceed MTU of 1020)
   Channel binding:           Yes (No in basic variant)
   Acknowledged S/F:          Yes
   State Synchronization:     Yes (No in basic variant)

6.2. Passive and Active Attacks

Let's talk about the scary stuff 😭 The basic variant (the one where OTP protection and mutual authentication aren't used) does NOT give you session privacy, session integrity, server authentication, or protection from active attacks 💀 Especially, man-in-the-middle attacks are possible, where an attacker pretends to be an authenticator just to grab a valid OTP 👀

Same vibe: the basic variant doesn't protect against session hijacking after authentication, and it doesn't protect against replay attacks on its own, where someone gets in by replaying an old valid request. (See the next subsection for more on that 🫶) And when PIN codes get sent, they go out with zero protection and can be replayed too 🙈

So, to protect against all that, the peer MUST only use the basic variant of this method over a server-authenticated and confidentiality-protected connection 🔐 You can get there with PEAPv2 [17], for example 🌸

Now, when the OTP protection variant is used, it's a whole different energy ✨ It gives privacy for OTPs and new PINs, negotiation of cryptographic algorithms, mutual authentication, and protection against replay attacks and protocol version downgrades 👑 It also protects against man-in-the-middle attacks. The reason isn't that a man-in-the-middle can't solve for a valid OTP given an OTP TLV. It's that finding the OTP inside the short window when it's valid is computationally expensive. This is mostly true for tokens that include the current time in their OTP calculations, or when a sent challenge has a limited lifetime ⏳

Here's the tea 🍵 An OTP that's retrieved, even if it's "old" and invalid, may still reveal some information about the user's PIN. That's true for the basic variant too, obviously. So implementations where user PINs get sent along with OTPs are RECOMMENDED to make sure users change their PINs regularly, whether they're running the protected variant or the basic one 🔄

Also, a rogue access point could clone MAC addresses and pull off a man-in-the-middle attack, sure 🙃 But that access point still can't calculate the session keys MSK and EMSK. That's why it's SO important to use the derived key material properly to protect a later session 🗝️

Protected mode guards against version downgrade attacks because of the HMAC both parties send in this mode 🧾 Each side calculates the HMAC over the EAP-POTP handshake messages it sent and received. If an attacker changed a Version TLV, the difference would show up in the calculated MACs, since the recipient of the Version TLV got a different value than the sender sent 🚨 Unless the attacker knows K_MAC, they can't calculate the correct MAC, so the mismatch gets caught 🙌

The OTP protection variant also protects against session hijacking, as long as the derived key material gets used (directly or indirectly) to protect a later session 🧚 So, for all these reasons, using the OTP protection variant is RECOMMENDED 💖

Bad news though: not even the OTP protection variant gives privacy for user names and/or token key identifiers 😬 If you need privacy for those parameters, EAP-POTP MUST be used inside a secure tunnel, like the one PEAPv2 [17] provides 🔒

When resuming sessions that were created in the basic variant (which MUST only happen inside a protected tunnel), the peer proves it's legit by showing it knows not just a valid session identifier, but also the OTP that was used when the session was created 🪪 Server nonces stop replay attacks, but there's still some chance an attacker guesses the right combo of session identifier and OTP value 👀 Assuming OTPs with about 32 bits of entropy, the odds of an attacker pulling this off are about 1/2^48, thanks to the birthday paradox 🎂 Servers that allow session resumption for the basic variant MUST protect against such attacks, for example by keeping track of the rate of failed resumption attempts 🚦

6.3. Denial-of-Service Attacks ✨

Okay bestie, so an active attacker can swap out the iteration count value in the OTP TLVs the peer sends, just to make an authentication server super slow 🐢 Rude! 😤 The fix is that authentication servers SHOULD protect against this, like by disregarding OTP TLVs with an iteration count higher than some number that's either preset or set on the fly depending on load 💅

6.4. The Use of Pepper 🌶️

As we talked about in Section 4.8, pepper makes an attacker's hunt for a matching OTP way harder 🕵️‍♀️ Being able to send a pepper value encrypted from the EAP server to the peer is giving efficiency. Yes, the EAP server might have an upfront computational cost to authenticate the peer, but later logins are efficient and more secure, since a pre-shared, 128-bit-long pepper value won't be easily found by an attacker. 🔐

Here's the tea though 🫖 An attacker watching an EAP-Request with an OTP TLV calculated using a pepper the peer picked might, depending on their resources, still crack that one EAP-POTP session, since it's probably based on a relatively short pepper value or just an iteration count. Once they find the correct OTP, eavesdropping on the EAP server's Confirm TLV could give them access to the longer, server-provided pepper for the rest of that pepper's lifetime. 😱

So, initial exchanges with EAP servers SHOULD happen in a secure environment (e.g., in a PEAPv2 tunnel offering cryptographic binding with inner EAP methods) 🛡️ If they don't, the iteration count MUST be significantly higher than for messages where a pre-shared pepper is used. The lifetime of the shared pepper also has to be calculated with this in mind. Finally, the peer and the EAP server MUST store the pepper value securely and associated with the user 🔒 Non-negotiable, periodt!

6.5. The Race Attack 🏁

If EAP messages get fragmented, the basic variant of this method lets an attacker listen to most of an OTP, guess the rest, and then race the legit user to finish the authentication first. 🏃‍♀️💨 Conforming backend authentication server implementations MUST protect against this race condition. One defense is outlined below, borrowed from [14]. Implementations MAY use this approach or MAY select an alternative defense. Note that this defense relies on the user providing the identity in response to an initial Identity EAP-Request 📝

One possible defense is to stop a user from starting multiple simultaneous authentication sessions. That means once the legitimate user has started authenticating, an attacker gets blocked until the first authentication process has completed. In this approach, a timeout is necessary to thwart a denial-of-service attack ⏱️

7. IANA Considerations 📋

7.1. General

This document is a description of a general EAP method for OTP tokens. It also defines EAP method 32 as a profile of the general method. Extending the set of EAP-POTP TLVs or the set of EAP-POTP cryptographic algorithms shall be seen as revisions of the protocol and hence shall require an RFC that updates or obsoletes this document 📜

7.2. Cryptographic Algorithm Identifier Octets

A new registry for EAP-POTP cryptographic algorithm identifier octets has been created 🗂️ The initial contents of this registry are as specified in Section 4.11.16.

Assignment of new values for hash algorithms, encryption algorithms, and MAC algorithms in the Crypto Algorithm TLV MUST be done through IANA with "Specification Required" and "IESG Approval" (see [9] for the meaning of these terms) 🎀

8. Intellectual Property Considerations ⚖️

RSA, RSA Security, and SecurID are either registered trademarks or trademarks of RSA Security Inc. in the United States and/or other countries. The names of other products and services mentioned may be the trademarks of their respective owners 💼

9. Acknowledgments 🫶

This document was improved by comments from, and discussion with, a number of RSA Security employees. Simon Josefsson drafted the initial versions of an RSA SecurID EAP method while working for RSA Laboratories. The inspiration for the TLV-type of information exchange comes from [17]. Special thanks to Oliver Tavakoli of Funk Software, who provided numerous useful comments and suggestions, Randy Chou of Aruba Networks for good suggestions in the session resumption area, and Jim Burns of Meetinghouse, who provided inspiration for the Protected TLV 🌸 Thanks also to the IESG reviewers, Pasi Eronen, David Black, and Uri Blumenthal, for insightful comments that helped improve the document, and to Alfred Hoenes for a thorough editorial review 👑

10. References 📚

10.1. Normative References

  • [1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, February 2004.
  • [4] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.
  • [5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [6] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
  • [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
  • [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.

10.2. Informative References

  • [10] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  • [11] The Institute of Electrical and Electronics Engineers, Inc., "IEEE Standard for Local and metropolitan area networks -- Port-Based Network Access Control", IEEE 802.1X-2001, July 2001.
  • [12] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  • [13] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
  • [14] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
  • [15] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
  • [16] Aboba, B., Simon, D., Eronen, P., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2006.
  • [17] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
  • [18] Internet Assigned Numbers Authority, "Private Enterprise Numbers", December 2006.
  • [19] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.

Appendix A. Profile of EAP-POTP for RSA SecurID 💖

Note: The RSA SecurID product is a hardware token card (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication 🔑

The EAP method type identifier for the RSA SecurID profile of EAP-POTP is 32.

Peers and EAP servers implementing the SecurID profile of EAP-POTP SHALL conform to all EAP-POTP normative requirements in this Document. In addition, the New PIN TLV and the Protected TLV MUST be supported by peers 🧚

Appendix B. Examples of EAP-POTP Exchanges 🦋

This appendix is non-normative. In the examples, "V1", "V2", "V3", etc., stand for arbitrary values of the correct type.

B.1. Basic Mode, Unilateral Authentication

This mode should only be used within a secured tunnel. The peer identifies itself with a User Identifier TLV 🎀

Peer                                 EAP server

                                     <- EAP-Request
                                        Type=Identity

EAP-Response ->
Type=Identity

                                     <- EAP-Request
                                        Type=OTP-X

                                        Version TLV:
                                        Highest=0,Lowest=0

                                        OTP TLV:
                                        P=0,C=0,N=0,T=0,E=0,R=0

EAP-Response ->
Type=OTP-X

Version TLV:
Highest=0

OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
Authentication Data=V1

User Identifier TLV:
User Identifier=V2

                                     <- EAP-Success

B.2. Basic Mode, Session Resumption

This example illustrates successful resumption of a basic mode session. It must be carried out only in a protected tunnel 🌈

Peer                                 EAP server

                                     <- EAP-Request
                                        Type=Identity

EAP-Response ->
Type=Identity

                                     <- EAP-Request
                                        Type=OTP-X

                                        Version TLV:
                                        Highest=0,Lowest=0

                                        OTP TLV:
                                        P=0,C=0,N=0,T=0,E=0,R=0

                                        Server-Info TLV:
                                        N=0
                                        Session Identifier=V1
                                        Server  Identifier=V2
                                        Nonce=V3
EAP-Response ->
Type=OTP-X

Version TLV:
Highest=0

Resume TLV:
Session Identifier=V4 (indicating earlier, basic mode, session)
Authentication Data=V5

                                     <- EAP-Success

B.3. Mutual Authentication without Session Resumption 🦋

okay so in this one the peer sends its token key identifier along with its user identifier 🫶 The initial EAP-Identity exchange can share user info, or it can stay super vague and only tell you the general domain 🌸 No pepper yet! But it's coming in a later session, because the server slides an encrypted pepper into its Confirm TLV ✨ And if the Crypto Algorithm TLV is missing, that just means everyone defaults to the standard crypto algorithms 💅

Peer                                 EAP server

                                     <- EAP-Request
                                        Type=Identity

EAP-Response ->
Type=Identity

                                     <- EAP-Request
                                        Type=OTP-X

                                        Version TLV:
                                        Highest=0,Lowest=0

                                        Server-Info TLV:
                                        N=0
                                        Session Identifier=V1
                                        Server  Identifier=V2
                                        Nonce=V3

                                        OTP TLV:
                                        P=1,C=0,N=0,T=0,E=0,R=0
                                        Pepper Length=0
                                        Iteration Count=V4

EAP-Response ->
Type=OTP-X

Version TLV:
Highest=0

OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
Authentication Data=V5
User Identifier TLV:
User Identifier=V6

Token Key Identifier TLV:
Token Key Identifier=V7

                                     <- EAP-Request
                                        Type=OTP-X

                                        Confirm TLV:
                                        C=0
                                        Authentication Data=V8
                                        Pepper Identifier=V9
                                        Encrypted Pepper=V10

EAP-Response ->
Type=OTP-X

Confirm TLV:
(no data)

                                     <- EAP-Success

B.4. Mutual Authentication with Transfer of Pepper 💜

the vibe here is basically B.3 but with a glow-up 🌈 The peer actually uses an existing pepper inside the PBKDF2 computation! The EAP server then hands over a brand new pepper in the Confirm TLV ✨ Quick tea: the peer couldn't have used a pepper in its response calculation unless it already had one, because the server set the maximum (new) pepper length to zero 🙈

Peer                                 EAP server

                                     <- EAP-Request
                                        Type=Identity

EAP-Response ->
Type=Identity

                                     <- EAP-Request
                                        Type=OTP-X

                                        Version TLV:
                                        Highest=0,Lowest=0

                                        Server-Info TLV:
                                        N=0
                                        Session Identifier=V1
                                        Server  Identifier=V2
                                        Nonce=V3

                                        OTP TLV:
                                        P=1,C=0,N=0,T=0,E=0,R=0
                                        Pepper Length=0
                                        Iteration Count=V4

EAP-Response ->
Type=OTP-X

Version TLV:
Highest=0

OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V5
Iteration Count=V6
Authentication Data=V7
(includes a pepper identifier)
User Identifier TLV:
User Identifier=V8

Token Key Identifier TLV:
Token Key Identifier=V9

                                     <- EAP-Request
                                        Type=OTP-X

                                        Confirm TLV:
                                        C=0
                                        Authentication Data=V10
                                        Pepper Identifier=V11
                                        Encrypted Pepper=V12

EAP-Response ->
Type=OTP-X

Confirm TLV:
(no data)

                                     <- EAP-Success

B.5. Failed Mutual Authentication 💀

this one is the drama episode 😭 The difference from the last example is that the peer can't authenticate the server, so it sends an empty EAP-Response of type POTP-X, and the EAP server basically says "not today" with an EAP-Failure 🥀 No pepper gets used here either!

Peer                                 EAP server

                                     <- EAP-Request
                                        Type=Identity

EAP-Response ->
Type=Identity

                                     <- EAP-Request
                                        Type=OTP-X

                                        Version TLV:
                                        Highest=0,Lowest=0

                                        OTP TLV:
                                        P=1,C=0,N=0,T=0,E=0,R=0
                                        Pepper Length=V1
                                        Iteration Count=V2
                                        Server-Info TLV:
                                        N=0
                                        Session Identifier=V3
                                        Server  Identifier=V4
                                        Nonce=V5

EAP-Response ->
Type=OTP-X

Version TLV:
Highest=0

OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Authentication Data=V6

User Identifier TLV:
User Identifier=V7

Token Key Identifier TLV:
Token Key Identifier=V8

                                     <- EAP-Request
                                        Type=OTP-X

                                        Confirm TLV:
                                        C=0
                                        Authentication Data=V9

EAP-Response ->
Type=OTP-X

(no data)

                                     <- EAP-Failure

B.6. Session Resumption 🌸

this one shows session resumption working perfectly, no notes 🎀✨

Peer                                 EAP server

                                     <- EAP-Request
                                        Type=Identity

EAP-Response ->
Type=Identity

                                     <- EAP-Request
                                        Type=OTP-X

                                        Version TLV:
                                        Highest=0,Lowest=0

                                        OTP TLV:
                                        P=1,C=0,N=0,T=0,E=0,R=0
                                        Pepper Length=V1
                                        Iteration Count=V2

                                        Server-Info TLV:
                                        N=0
                                        Session Identifier=V3
                                        Server  Identifier=V4
                                        Nonce=V5

EAP-Response ->
Type=OTP-X

Version TLV:
Highest=0

Resume TLV:
Session Identifier=V6 (indicating earlier, protected mode, session)
Authentication Data=V7

                                     <- EAP-Request
                                        Type=OTP-X

                                        Confirm TLV:
                                        C=0
                                        Authentication Data=V8

EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)

                                     <- EAP-Success

B.7. Failed Session Resumption 🧚

plot twist 🙈 The resumption attempt flops, so the two of them fall back to a full mutual authentication 💅 The user is identified through the User Identifier TLV, and the client is able to reuse an older pepper. The server sends a fresh pepper for later use in its Confirm TLV ✨ The server also suggests some non-default crypto algorithms, but the client only supports the default ones, so it's a whole vibe mismatch 🫠

Peer                                 EAP server

                                     <- EAP-Request
                                        Type=Identity

EAP-Response ->
Type=Identity

                                     <- EAP-Request
                                        Type=OTP-X

                                        Version TLV:
                                        Highest=0,Lowest=0

                                        OTP TLV:
                                        P=1,C=0,N=0,T=0,E=0,R=0
                                        Pepper Length=V1
                                        Iteration Count=V2

                                        Server-Info TLV:
                                        N=0
                                        Session Identifier=V3
                                        Server  Identifier=V4
                                        Nonce=V5

                                        Crypto Algorithm TLV:
                                        Hash Alg. Length=V6
                                        Hash Algorithms=V7
                                        Encr. Alg. Length=V8
                                        Encr. Algorithms=V9
                                        MAC Alg. Length=V10
                                        MAC Algorithms=V11

EAP-Response ->
Type=OTP-X

Version TLV:
Highest=0
Resume TLV:
Session Identifier=V12 (indicating earlier session)
Authentication Data=V13

                                     <- EAP-Request
                                        Type=OTP-X

                                        OTP TLV:
                                        P=1,C=0,N=0,T=0,E=0,R=0
                                        Pepper Length=V14
                                        Iteration Count=V15

                                        Server-Info TLV:
                                        N=1 (no resumption)
                                        Session Identifier=V3
                                        Server  Identifier=V4
                                        Nonce=V16

EAP-Response ->
Type=OTP-X

OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V17
Iteration Count=V18
Authentication Data=V19 (with pepper identifier)

User Identifier TLV:
User Identifier=V20

                                     <- EAP-Request
                                        Type=OTP-X

                                        Confirm TLV:
                                        C=0
                                        Authentication Data=V21
                                        Pepper Identifier=V22
                                        Encrypted Pepper=V23
EAP-Response ->
Type=OTP-X

Confirm TLV:
(no data)

                                     <- EAP-Success

B.8. Mutual Authentication, and New PIN Requested. 🔐✨

okay so in this one the user gets asked to pick a new PIN too 💅 the new PIN can be alphanumeric and has to be at least 6 characters long. the user goes with a different PIN than the one the server suggested, which is very independent of them 👑 the token key gets identified by combining the user identifier and the token key identifier 🦋

while the peer waits for the user to type, it sends an EAP-Response carrying a Keep-Alive TLV to the EAP server so the network doesn't time out 🫶 the EAP server sends back an EAP-Request with its own Keep-Alive TLV. also, everything exchanged after the Confirm TLV exchange gets wrapped in the Protected TLV 🔒 and if there's no Crypto Algorithm TLV at all, that just means default cryptographic algorithms are being used 🌸

Peer                                 EAP server

                                     <- EAP-Request
                                        Type=Identity

EAP-Response ->
Type=Identity

                                     <- EAP-Request
                                        Type=OTP-X

                                        Version TLV:
                                        Highest=0,Lowest=0

                                        OTP TLV:
                                        P=1,C=0,N=0,T=0,E=0,R=0
                                        Pepper Length=V1
                                        Iteration Count=V2

                                        Server-Info TLV:
                                        N=0
                                        Session Identifier=V3
                                        Server  Identifier=V4
                                        Nonce=V5

EAP-Response ->
Type=OTP-X

Version TLV:
Highest=0

OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V8 (with pepper identifier)

User Identifier TLV:
User Identifier=V9

Token Key Identifier TLV:
Token Key Identifier=V10

                                     <- EAP-Request
                                        Type=OTP-X

                                        Confirm TLV:
                                        C=1
                                        Authentication Data=V11

EAP-Response ->
Type=OTP-X

Confirm TLV:
(no data)

                                     <- EAP-Request
                                        Type=OTP-X

                                        Protected TLV:
                                        MAC=V12
                                        IV=V13
                                        Encrypted TLVs=V14
                                        (Contains:
                                        New PIN TLV:
                                        Q=0,A=1
                                        PIN=V15
                                        Min. PIN Length=6)

EAP-Response ->
Type=OTP-X

Protected TLV:
MAC=V16
IV=V17
Encrypted TLVs=V18
(Contains:
Keep-Alive TLV:
(no data))

                                     <- EAP-Request
                                        Type=OTP-X
                                        Protected TLV:
                                        MAC=V19
                                        IV=V20
                                        Encrypted TLVs=V21
                                        (Contains:
                                        Keep-Alive TLV:
                                        (no data))

EAP-Response ->
Type=OTP-X

Protected TLV:
MAC=V22
IV=V23
Encrypted TLVs=V24
(Contains:
New PIN TLV:
Q=0,A=0
PIN=V25)

                                     <- EAP-Request
                                        Type=OTP-X

                                        Protected TLV:
                                        MAC=V26
                                        IV=V27
                                        Encrypted TLVs=V28
                                        (Contains:
                                        OTP TLV:
                                        P=1,C=0,N=0,T=0,E=0,R=0
                                        Pepper Length=V1
                                        Iteration Count=V2)

EAP-Response ->
Type=OTP-X

Protected TLV
MAC=V29
IV=V30
Encrypted TLVs=V31
(Contains:
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V31)

                                     <- EAP-Request
                                        Type=OTP-X

                                        Protected TLV
                                        MAC=V32
                                        IV=V33
                                        Encrypted TLVs=V34
                                        (Contains:
                                        Confirm TLV:
                                        C=0
                                        Authentication Data=V35)

EAP-Response ->
Type=OTP-X

Protected TLV
MAC=V36
IV=V37
Encrypted TLVs=V38
(Contains:
Confirm TLV:
(no data))

                                     <- EAP-Success

B.9. Use of Next OTP Mode 🌈

in this one, the peer gets asked to hand over a second OTP to the EAP server 🧚 the flow starts out just like the earlier examples, with the Identity exchange and then the OTP-X setup 🍓

Peer                                 EAP server

                                     <- EAP-Request
                                        Type=Identity

EAP-Response ->
Type=Identity

                                     <- EAP-Request
                                        Type=OTP-X

                                        Version TLV:
                                        Highest=0,Lowest=0

                                        OTP TLV:
                                        P=1,C=0,N=0,T=0,E=0,R=0
                                        Pepper Length=V1
                                        Iteration Count=V2
                                        Server-Info TLV:
                                        N=0
                                        Session Identifier=V3
                                        Server  Identifier=V4
                                        Nonce=V5

EAP-Response ->
Type=OTP-X

Version TLV:
Highest=0

OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V8

User Identifier TLV:
User Identifier=V9

                                     <- EAP-Request
                                        Type=OTP-X

                                        OTP TLV:
                                        P=1,C=0,N=1,T=1,E=0,R=0
                                        Pepper Length=V1
                                        Iteration Count=V2

EAP-Response ->
Type=OTP-X

OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V10

                                     <- EAP-Request
                                        Type=OTP-X

                                        Confirm TLV:
                                        C=0
                                        Authentication Data=V11

EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)

                                     <- EAP-Success

Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes 🎀

C.1. Introduction 💜

this section is all about how to fill in the MPPE-Send-Key and MPPE-Receive-Key RADIUS attributes, which are defined in [19], using an MSK that got set up during EAP-POTP 🫶

C.2. MPPE Key Attribute Population ✨

once the EAP-POTP MSK has been generated, you use it like this to fill in the MPPE-Send-Key and MPPE-Receive-Key attributes 🔑

take the first 32 octets of the MSK and use them as the value for the "Key" sub-field in the plaintext "String" field of the MPPE-Send-Key attribute. then take the last 32 octets of the MSK and use them as the "Key" sub-field in the plaintext "String" field of the MPPE-Receive-Key attribute. quick heads up, "Send" and "Receive" here are from the Authenticator's point of view, so for the peer they flip 🙃

Appendix D. Key Strength Considerations 💪

D.1. Introduction 🧠

as we covered in Section 6, how strong the keys are in EAP-POTP protected mode depends on a bunch of factors. this appendix shows some real examples of key strengths under different assumptions 📊

some of these examples look kinda weak, but that only applies to EAP-POTP sessions between a peer and an EAP server that don't share a pepper 🙈 once a pepper has been handed from an EAP server to a peer, future sessions using that pepper get full-strength keys 💖

D.2. Example 1: 6-Digit One-Time Passwords 🔢

in this example we're assuming:

  • OTPs are six decimal digits long;
  • 4-digit PINs get added to generated OTPs; and
  • OTP hardening (iteration count and pepper searching combined) effectively adds 10 bits of entropy. One way of achieving this without use of pepper searching is to have the iteration count in PBKDF2 set to 1,000,000.

so the effective key strength works out to roughly:

log_2(10**6) + log_2(10**4) + log_2(2**10) = 43 bits

this assumes the entropy of the underlying shared secret is >43 bits and that there are no other weaknesses in the OTP algorithm 👀

D.3. Example 2: 8-Digit One-Time Passwords 🦋

in this example we're assuming:

  • OTPs are eight decimal digits long;
  • 4-character alphanumeric PINs get added to generated OTPs; and
  • OTP hardening (iteration count and pepper searching combined) effectively adds 10 bits of entropy.

so the effective key strength works out to roughly:

log_2(10**8) + log_2(26**4) + log_2(2**10) = 55 bits

this assumes the entropy of the underlying shared secret is >55 bits and that there are no other weaknesses in the OTP algorithm 💅

Author's Address 🖊️

Magnus Nystroem
RSA Security

EMail: magnus@rsa.com

Copyright (C) The IETF Trust (2007).

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 ✨

okay bestie, so the IETF is basically saying "we're not picking a side" 💅 on whether any intellectual property or other rights someone might claim over the tech in this doc are valid, or how far they reach. Whether a license is even available? Not their call here. And they're not claiming they went digging to find any of those rights either 🙈. If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79 🎀

copies of IPR disclosures sent to the IETF Secretariat are a whole thing too 📚. so are any license assurances that might be on offer, plus whatever happened when someone tried to get a general license or permission for implementers or users to use those proprietary rights. all of that lives in the IETF on-line IPR repository at http://www.ietf.org/ipr ✨

and the IETF literally invites anyone to speak up 📣 about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send it to ietf-ipr@ietf.org 💌 it's giving transparency, periodt 🦋

Acknowledgement 🫶

funding for the RFC Editor function is currently provided by the Internet Society 🌸 so a big thank-you to them for keeping the RFC Editor going 💖

📦 where this page comes from