RFC 5931

Extensible Authentication Protocol (EAP) Authentication Using Only a Password

📅 published August 2010, from ietf

Extensible Authentication Protocol (EAP) Authentication Using Only a Password 🔐

okay bestie, this is RFC 5931 🦋 and it's all about EAP-pwd, a way to log in with just a password 🎀

It's an Informational doc (not a Standards Track spec, so it's a "here's some good info" kinda doc 💅). It's from August 2010, the authors are D. Harkins (Aruba Networks) and G. Zorn (Network Zen), and it's got ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates ✨

Abstract

so this memo describes an EAP method called EAP-pwd 🌸 it uses a shared password to authenticate. the password can be low-entropy, aka not super random, and it might come from a list of possible passwords (like a dictionary) that an attacker can access 👀 the key exchange underneath is still resistant to active attack, passive attack, and dictionary attack 💜 literally a whole mood

Status of This Memo

this doc is not an Internet Standards Track spec. it's published for informational purposes 🧚

it's a product of the Internet Engineering Task Force (IETF) ✨ it represents the consensus of the IETF community and got public review. it was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🍓

for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5931 🌈

© 2010 IETF Trust and the persons identified as the document authors. all rights reserved 🎀

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. please actually read those, they explain your rights and restrictions for this doc 🫶 any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅

this doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. the people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭 so unless you get an adequate license from whoever controls that copyright, this doc may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. the exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Keyword Definitions  . . . . . . . . . . . . . . . . . . .  4
     1.3.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
       1.3.1.  Resistance to Passive Attack . . . . . . . . . . . . .  4
       1.3.2.  Resistance to Active Attack  . . . . . . . . . . . . .  5
       1.3.3.  Resistance to Dictionary Attack  . . . . . . . . . . .  5
       1.3.4.  Forward Secrecy  . . . . . . . . . . . . . . . . . . .  5
   2.  Specification of EAP-pwd . . . . . . . . . . . . . . . . . . .  5
     2.1.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Discrete Logarithm Cryptography  . . . . . . . . . . . . .  7
       2.2.1.  Finite Field Cryptography  . . . . . . . . . . . . . .  7
       2.2.2.  Elliptic Curve Cryptography  . . . . . . . . . . . . .  8
     2.3.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  9
     2.4.  Instantiating the Random Function  . . . . . . . . . . . .  9
     2.5.  Key Derivation Function  . . . . . . . . . . . . . . . . . 10
     2.6.  Random Numbers . . . . . . . . . . . . . . . . . . . . . . 10
     2.7.  Representation and Processing of Input Strings . . . . . . 11
       2.7.1.  Identity Strings . . . . . . . . . . . . . . . . . . . 11
       2.7.2.  Passwords  . . . . . . . . . . . . . . . . . . . . . . 11
     2.8.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12
       2.8.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . 12
       2.8.2.  Message Flows  . . . . . . . . . . . . . . . . . . . . 12
       2.8.3.  Fixing the Password Element  . . . . . . . . . . . . . 14
         2.8.3.1.  ECC Operation for PWE  . . . . . . . . . . . . . . 15
         2.8.3.2.  FFC Operation for pwe  . . . . . . . . . . . . . . 16
       2.8.4.  Message Construction . . . . . . . . . . . . . . . . . 16
         2.8.4.1.  ECC Groups . . . . . . . . . . . . . . . . . . . . 16
         2.8.4.2.  FFC Groups . . . . . . . . . . . . . . . . . . . . 17
       2.8.5.  Message Processing . . . . . . . . . . . . . . . . . . 18
         2.8.5.1.  EAP-pwd-ID Exchange  . . . . . . . . . . . . . . . 18
         2.8.5.2.  EAP-pwd-Commit Exchange  . . . . . . . . . . . . . 20
         2.8.5.3.  EAP-pwd-Confirm Exchange . . . . . . . . . . . . . 21
     2.9.  Management of EAP-pwd Keys . . . . . . . . . . . . . . . . 22
     2.10. Mandatory-to-Implement Parameters  . . . . . . . . . . . . 23
   3.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 23
     3.1.  EAP-pwd Header . . . . . . . . . . . . . . . . . . . . . . 23
     3.2.  EAP-pwd Payloads . . . . . . . . . . . . . . . . . . . . . 25
       3.2.1.  EAP-pwd-ID . . . . . . . . . . . . . . . . . . . . . . 25
       3.2.2.  EAP-pwd-Commit . . . . . . . . . . . . . . . . . . . . 26
       3.2.3.  EAP-pwd-Confirm  . . . . . . . . . . . . . . . . . . . 27
     3.3.  Representation of Group Elements and Scalars . . . . . . . 27
       3.3.1.  Elements in FFC Groups . . . . . . . . . . . . . . . . 27
       3.3.2.  Elements in ECC Groups . . . . . . . . . . . . . . . . 28
       3.3.3.  Scalars  . . . . . . . . . . . . . . . . . . . . . . . 28
   4.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . . . 28
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
     6.1.  Resistance to Passive Attack . . . . . . . . . . . . . . . 31
     6.2.  Resistance to Active Attack  . . . . . . . . . . . . . . . 31
     6.3.  Resistance to Dictionary Attack  . . . . . . . . . . . . . 32
     6.4.  Forward Secrecy  . . . . . . . . . . . . . . . . . . . . . 34
     6.5.  Group Strength . . . . . . . . . . . . . . . . . . . . . . 34
     6.6.  Random Functions . . . . . . . . . . . . . . . . . . . . . 34
   7.  Security Claims  . . . . . . . . . . . . . . . . . . . . . . . 35
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 38
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 38

1. Introduction 🌸

1.1. Background

so the most common way people get onto the Internet today is a human typing a username and password to prove who they are to a computer that controls access 🔑 proving you know the password is what authenticates both the human and the computer ✨

usually these passwords aren't stored on the user's computer for security reasons, so the human has to type them in every time they want network access. that means the passwords have to be ones a human can type over and over with a low chance of messing up 😭 they probably won't have high entropy, and it's fair to assume an attacker with a dictionary can guess a user's password. so it's really desirable to have a robust auth method that stays secure even with a weak password against a strong adversary 🛡️💜

EAP-pwd is an EAP method for the problem of password-based authenticated key exchange. the idea is you use a possibly weak password to authenticate and derive a shared secret that's both authenticated and cryptographically strong 🦋 Bellovin and Merritt first described this problem in [BM92] and [BM93]. since then there have been a bunch of other suggestions for password-based authenticated key exchanges, like [JAB96], [LUC97], [BMP00], and others 🧚

1.2. Keyword Definitions

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc get read as described in RFC 2119 [RFC2119] 📖

1.3. Requirements

any protocol that claims to solve password-authenticated key exchange must be resistant to active, passive, and dictionary attack, and it must have forward secrecy. these characteristics get a closer look in the sections below 🔍

1.3.1. Resistance to Passive Attack

a passive attacker (aka a benign one) just relays messages back and forth between the peer and the server, faithfully, without changing anything 👀 they can look at the contents of the messages, but that's all. to be resistant to passive attack, this attacker must not be able to learn anything about the password or the resulting shared secret just by watching repeated runs of the protocol 💅 even if a passive attacker manages to learn the password, she still can't figure out anything about the secret shared by the peer and server 🙈

1.3.2. Resistance to Active Attack

an active attacker can modify, add, delete, and replay messages sent between protocol participants 😈 for this protocol to be resistant to active attack, the attacker must not be able to learn anything about the password or the shared secret using any of its abilities. on top of that, the attacker must not be able to trick a protocol participant into thinking the protocol finished successfully 🫶

it's always possible for an active attacker to block delivery of a message that's critical to completing the exchange. but that's no different from dropping all messages, so it isn't an attack against the protocol itself 🤷‍♀️

1.3.3. Resistance to Dictionary Attack

for this protocol to be resistant to dictionary attack, any advantage an adversary gains has to be directly related to the number of interactions she makes with an honest protocol participant, and not come from computation 🧮 the adversary shouldn't be able to learn anything about the password except whether a single guess from a single protocol run is correct or incorrect 💖

1.3.4. Forward Secrecy

compromising the password must not reveal anything about the secrets generated by earlier runs of the protocol 🔥 old sessions stay safe even if the password leaks later ✨

2. Specification of EAP-pwd 👑

2.1. Notation ✨

okay so this is the cheat sheet for every bit of notation we're using, bestie 🔖 the rest of the doc is built on it, so bookmark it 💅

  • peer-ID: the peer's identity, which is the peer NAI [RFC4282] 🎀
  • server-ID: a string that identifies the server to the peer 🌸
  • password: the password shared between the peer and server 🔐
  • y = H(x): the binary string x gets fed into a function H, which spits out a fixed-length output y ✨
  • a | b: the concatenation of string a with string b 🧵
  • [a]b: a string made of the single bit "a" repeated "b" times 🔁
  • x mod y: the remainder when you divide x by y. The result will be between 0 and y 🧮
  • g^x mod p: multiply the value "g" by itself "x" times, modulo the value "p" 💖
  • inv(Q): the inverse of an element, Q, from a finite field 🦋
  • len(x): the length in bits of the string x 📏
  • chop(x, y): reducing string x (which has to be at least y bits long) down to y bits ✂️
  • PRF(x,y): a pseudo-random function that takes a key, x, and variable-length data, y, and produces a fixed-length output that cannot be distinguished (with a significant advantage) from a random source 🌈
  • LSB(x): returns the least-significant bit of the bitstring "x" 🍓
  • Ciphersuite: an encoding of a group to use with EAP-pwd, the definition of function H, and a PRF, in that order 👑
  • MK: the Master Key is generated by EAP-pwd. This is a high-entropy secret whose length depends on the random function used 🗝️
  • MSK: the Master Session Key exported by EAP-pwd. This is a high-entropy secret 512 bits in length 💜
  • EMSK: the Extended Master Session Key exported by EAP-pwd. This is a high-entropy secret 512 bits in length 🫶

2.2. Discrete Logarithm Cryptography 🧠

ngl this is the math heart of the whole protocol 🔥 EAP-pwd uses discrete logarithm cryptography to get authentication and key agreement (see [SP800-56A]). Each party in the exchange derives ephemeral keys with respect to a particular set of domain parameters, which we're calling a "group" 🎀 A group can be based on Finite Field Cryptography (FFC) or Elliptic Curve Cryptography (ECC) 🦋

2.2.1. Finite Field Cryptography 🌸

okay so the domain parameters for the FFC groups EAP-pwd uses include:

  • A prime, p, determining a prime field GF(p), the integers modulo p. The FFC group will be a subgroup of GF(p)*, the multiplicative group of non-zero elements in GF(p). The group operation for FFC groups is multiplication modulo p.
  • An element, G, in GF(p)* which serves as a generator for the FFC group. G is chosen such that its multiplicative order is a sufficiently large prime divisor of ((p-1)/2).
  • A prime, r, which is the multiplicative order of G, and thus also the size of the cryptographic subgroup of GF(p)* that is generated by G.

An integer scalar, x, acts on an FFC group element, Y, via exponentiation modulo p, written Y^x mod p 💖

The inverse function for an FFC group is defined so that the product of an element and its inverse modulo the group prime equals one (1). In other words:

(q * inv(q)) mod p = 1

EAP-pwd uses an IANA registry for the definition of groups 📚 Some FFC groups in this registry are based on safe primes, and the order is not included in the domain parameters. In this case only, the order, r, MUST be computed as the prime minus one divided by two, which is (p-1)/2 ✨ If the definition of the group includes an order in its domain parameters, that value MUST be used in this exchange when an order is called for. If an FFC group definition does not have an order in its domain parameters and it is not based on a safe prime, it MUST NOT be used with EAP-pwd 🚫

2.2.2. Elliptic Curve Cryptography 🧚

Domain parameters for the ECC groups EAP-pwd uses include:

  • A prime, p, determining a prime field GF(p). The cryptographic group will be a subgroup of the full elliptic curve group. That group consists of points on an elliptic curve (elements from GF(p) that satisfy the curve's equation) together with the "point at infinity," which serves as the identity element. The group operation for ECC groups is addition of points on the elliptic curve.
  • Elements a and b from GF(p) that define the curve's equation. The point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only if (y^2 - x^3 - a*x - b) mod p equals zero (0).
  • A point, G, on the elliptic curve, which serves as a generator for the ECC group. G is chosen such that its order, with respect to elliptic curve addition, is a sufficiently large prime.
  • A prime, r, which is the order of G, and thus is also the size of the cryptographic subgroup that is generated by G.
  • A co-factor, f, defined by the requirement that the size of the full elliptic curve group (including the "point at infinity") is the product of f and r.

An integer scalar, x, acts on an ECC group element, Y, via repetitive addition (Y is added to itself x times). This is also called point multiplication, written x * Y 🌈

The inverse function for an ECC group is defined so that the sum of an element and its inverse is the "point at infinity" (the identity for elliptic curve point addition). In other words:

Q + inv(Q) = "O"
⚠️ Only ECC groups over GF(p) can be used by EAP-pwd. ECC groups over GF(2^m) SHALL NOT be used by EAP-pwd. While such groups exist in the IANA registry used by EAP-pwd, their use in EAP-pwd is not defined. In addition, ECC groups with a co-factor greater than one (1) SHALL NOT be used by EAP-pwd. At the time of publication, no such groups existed in the IANA registry used by EAP-pwd. 🙈

2.3. Assumptions 🎀

okay so to see how the protocol handles the requirements above (see Section 1.3), we have to state some assumptions it gets evaluated under. They are:

  1. Function H maps a binary string of indeterminate length onto a fixed binary string that is x bits in length.
H: {0,1}^* --> {0,1}^x
  1. Function H is a "random oracle" (see [RANDOR]). Given knowledge of the input to H, an adversary is unable to distinguish the output of H from a random data source 👀
  2. Function H is a one-way function. Given the output of H, it is computationally infeasible for an adversary to determine the input 🔒
  3. For any given input to function H, each of the 2^x possible outputs are equally probable 🎲
  4. The discrete logarithm problem for the chosen group is hard. That is, given g, p, and y = g^x mod p, it is computationally infeasible to determine x. Similarly, for an ECC group given the curve definition, a generator G, and Y = x * G, it is computationally infeasible to determine x 💅
  5. There exists a pool of passwords from which the password shared by the peer and server is drawn. This pool can consist of words from a dictionary, for example. Each password in this pool has an equal probability of being the shared password. All potential attackers have access to this pool of passwords 🫣

2.4. Instantiating the Random Function 🦋

The protocol in this memo uses a random function, H. As noted in Section 2.3, this is a "random oracle" as defined in [RANDOR]. At first glance you might think of it as a hash function. As noted in [RANDOR], though, hash functions are too structured to be used directly as a random oracle 🙃 But they can be used to instantiate the random oracle, and that's the move here 🍓

The random function, H, in this memo is instantiated by HMAC-SHA256 (see [RFC4634]) with a key whose length is 32 octets and whose value is zero. In other words:

H(x) = HMAC-SHA-256([0]32, x)

2.5. Key Derivation Function 🔑

okay so the keys this protocol outputs, MSK and EMSK, are each 512 bits long. But the shared secret that comes out of a successful run is only 256 bits 😭 So we need to stretch that shared secret with a key derivation function (KDF) 💪

The KDF uses a counter-mode with feedback construction, built on a generic pseudo-random function (PRF), according to [SP800-108]. The specific value of the PRF is specified along with the random function and group when the server sends the first EAP-pwd packet to the peer 📦

The KDF takes a key to stretch, a label to bind into the key, and an indication of the desired length of the output in bits. It uses two internal variables, i and L, each 16 bits in length, represented in network order. Here's how it works:

             KDF(key, label, length) {
               i = 1
               L = length
               K(1) = PRF(key, i | label | L)
               res = K(1)
               while (len(res) < length)
               do
                 i = i + 1
                 K(i) = PRF(key, K(i-1) | i | label | L)
                 res = res | K(i)
               done
               return chop(res, length)
             }

                  Figure 1: Key Derivation Function

2.6. Random Numbers 🎲

The security of EAP-pwd relies on each side, the peer and server, producing quality secret random numbers 🫶 A poor random number chosen by either side in a single exchange can compromise the shared secret from that exchange and open up the possibility of dictionary attack 💀

Producing quality random numbers without specialized hardware means using a cryptographic mixing function (like a strong hash function) to distill entropy from multiple, uncorrelated sources of information and events. A very good discussion of this can be found in [RFC4086] 📚

2.7. Representation and Processing of Input Strings 🧵

2.7.1. Identity Strings 🌈

The strings representing the server identity and peer identity MUST follow the requirements of [RFC4282] for Network Access Identifiers 🎀 This makes sure both ends of the conversation have a canonical representation of identities before they get used in EAP-pwd 💖

2.7.2. Passwords 🔐

okay bestie, passwords are the spicy part 🌶️ EAP-pwd needs the password as a binary string 💖 and for the protocol to actually finish, both sides have to produce the exact same binary string from it or nothing matches 😭 so the password has to go through some pre-processing first 💅

Three pre-processing techniques exist for EAP-pwd ✨

  • None: The input password string SHALL be treated as an ASCII string or a hexadecimal string with no treatment or normalization performed. The output SHALL be the binary representation of the input string. 🎀
  • RFC 2759: The input password string SHALL be processed to produce the output PasswordHashHash, as defined in [RFC2759], including any approved errata to [RFC2759]. This one is useful when the server does not have access to the plaintext password 🙈
  • SASLprep: The input password string is processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHALL be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output SHALL be the binary representation of the processed UTF-8 character string. Prohibited output and unassigned codepoints encountered in SASLprep pre-processing SHALL cause a failure of pre-processing, and the output SHALL NOT be used with EAP-pwd 💀

Changing a password is out of scope for EAP-pwd, but internationalized character strings are kinda messy 🌈 so 1) it SHOULD be done using SASLprep to make sure a canonical representation of the new password is stored on the server, and 2) later EAP-pwd runs SHOULD use SASLprep so the client generates an identical binary string from the input password. no cap, consistency is everything 🫶

2.8. Protocol 🦋

2.8.1. Overview 🌸

okay so EAP is a two-party protocol spoken between an EAP peer and an authenticator 💜 for scaling reasons, the authenticator's EAP-speaking part often gets split out into its own stand-alone EAP server. when that happens, the EAP peer talks to the EAP server through the authenticator, which is basically just a passthrough 🧚

An EAP method defines the specific authentication protocol being used by EAP. This memo defines one particular method, so it also defines the messages exchanged between the EAP server (or the "EAP server" functionality inside an authenticator if it isn't broken out) and the EAP peer for authentication and key derivation ✨

2.8.2. Message Flows 🛤️

EAP-pwd has three message exchanges: an Identity exchange, a Commit exchange, and a Confirm exchange 💅 a successful authentication looks like Figure 2 below 👑

           +--------+                                     +--------+
           |        |                  EAP-pwd-ID/Request |        |
           |  EAP   |<------------------------------------|  EAP   |
           |  peer  |                                     | server |
           |        | EAP-pwd-ID/Response                 |        |
           |        |------------------------------------>|        |
           |        |                                     |        |
           |        |              EAP-pwd-Commit/Request |        |
           |        |<------------------------------------|        |
           |        |                                     |        |
           |        | EAP-pwd-Commit/Response             |        |
           |        |------------------------------------>|        |
           |        |                                     |        |
           |        |             EAP-pwd-Confirm/Request |        |
           |        |<------------------------------------|        |
           |        |                                     |        |
           |        | EAP-pwd-Confirm/Response            |        |
           |        |------------------------------------>|        |
           |        |                                     |        |
           |        |          EAP-Success                |        |
           |        |<------------------------------------|        |
           +--------+                                     +--------+

                  Figure 2: A Successful EAP-pwd Exchange

The peer and server use the Identity exchange to find out each other's identities and agree on a Ciphersuite for the next steps 🤝 the EAP server also uses the EAP-pwd-ID/Request message to tell the client about any password pre-processing it might need to do. In the Commit exchange, the peer and server swap information to make a shared key and also lock each other in to a specific guess of the password 🔒 In the Confirm exchange, they prove they're alive and know the password by generating and checking verification data ✅

The components of the EAP-pwd-* messages are:

EAP-pwd-ID/Request
    Ciphersuite, Token, Password Processing Method, Server_ID

EAP-pwd-ID/Response
    Ciphersuite, Token, Password Processing Method, Peer_ID

EAP-pwd-Commit/Request
    Scalar_S, Element_S

EAP-pwd-Commit/Response
    Scalar_P, Element_P

EAP-pwd-Confirm/Request
    Confirm_S

EAP-pwd-Confirm/Response
    Confirm_P

2.8.3. Fixing the Password Element 💍

Once the EAP-pwd-ID exchange is done, the peer and server use each other's identities and the agreed ciphersuite to fix an element in the negotiated group called the Password Element (PWE or pwe, for an element in an ECC group or an FFC group, respectively) 🧩 the result has to be picked in a deterministic way using the password, but it must not leak any info about the password to an attacker 🕵️‍♀️ from an attacker's point of view who doesn't know the password, the Password Element looks like a random element in the negotiated group 🎲

To fix the Password Element properly, both parties need the same view of the string "password". So if a password pre-processing algorithm was negotiated during the EAP-pwd-ID exchange, the client MUST perform the specified password pre-processing before fixing the Password Element 🚨

Fixing the Password Element is an iterative hunting-and-pecking technique 🐦 using the prime from the negotiated group's domain parameter set and an ECC- or FFC-specific operation, depending on the group.

First, an 8-bit counter is set to one (1). Then the agreed-upon random function is used to make a password seed from the identities and the anti-clogging token from the EAP-pwd-ID exchange (see Section 2.8.5.1):

pwd-seed = H(token | peer-ID | server-ID | password | counter)

Next, the pwd-seed gets expanded with the KDF from the agreed-upon Ciphersuite out to the length of the prime:

pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))

If pwd-value is greater than or equal to the prime, p, the counter goes up, a new pwd-seed is generated, and the hunting continues 🏃‍♀️ If pwd-value is less than the prime, p, it gets passed to the group-specific operation, which either returns the selected Password Element or fails. If that group-specific operation fails, the counter goes up, a new pwd-seed is generated, and the hunting-and-pecking keeps going. This repeats until the group-specific operation returns the Password Element ✨

2.8.3.1. ECC Operation for PWE 🌙

The group-specific operation for ECC groups uses pwd-value, pwd-seed, and the curve's equation to produce the Password Element 💫 First, pwd-value is used directly as the x-coordinate, x, in the elliptic curve equation (with parameters a and b from the curve's domain parameter set) to solve for a y-coordinate, y. If there's no solution to the quadratic equation, this operation fails and the hunting-and-pecking continues 🙃 If a solution is found, there's an ambiguity, because there are technically two solutions to the equation. pwd-seed is used to pick one of them unambiguously 🎯 If the low-order bit of pwd-seed equals the low-order bit of y, then a candidate PWE is the point (x, y). If the low-order bit of pwd-seed differs from the low-order bit of y, then the candidate PWE is the point (x, p - y), where p is the prime the curve is defined over. The candidate PWE becomes PWE, and the hunting and pecking ends successfully 🎉

Algorithmically, it goes like this:

found = 0
counter = 1
do {
  pwd-seed = H(token | peer-ID | server-ID | password | counter)
  pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
  if (pwd-value < p)
  then
    x = pwd-value
    if ( (y = sqrt(x^3 + ax + b)) != FAIL)
    then
      if (LSB(y) == LSB(pwd-seed))
      then
        PWE = (x, y)
      else
        PWE = (x, p-y)
      fi
      found = 1
    fi
  fi
  counter = counter + 1
} while (found == 0)
                Figure 3: Fixing PWE for ECC Groups

2.8.3.2. FFC Operation for pwe 🌊

The group-specific operation for FFC groups takes pwd-value, plus the prime, p, and the order, r, from the group's domain parameter set (see Section 2.2.1 when the order isn't part of the defined domain parameter set) 📐 It directly produces a candidate Password Element, pwe, by raising pwd-value to the power ((p-1)/r) modulo the prime. If the result is greater than one (1), the candidate pwe becomes pwe, and the hunting and pecking ends successfully 🦋

Algorithmically, it goes like this:

found = 0
counter = 1
do {
  pwd-seed = H(token | peer-ID | server-ID | password | counter)
  pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p))
  if (pwd-value < p)
  then
    pwe = pwd-value ^ ((p-1)/r) mod p
    if (pwe > 1)
    then
      found = 1
    fi
  fi
  counter = counter + 1
} while (found == 0)
                Figure 4: Fixing PWE for FFC Groups

2.8.4. Message Construction 🧵

After the EAP-pwd Identity exchange, how the components of later messages get built depends on the type of group in the ciphersuite (ECC or FFC) 💕 This section gives an overview of the authenticated key exchange. For the full description of message generation and processing, check out Sections 2.8.5.2 and 2.8.5.3 📖✨

2.8.4.1. ECC Groups 🦋

okay so for ECC groups we use the mapping function F() from Section 2.2.2 plus the group order r. here's how the handshake goes 💅

  • Server, EAP-pwd-Commit/Request:
    • choose two random numbers, 1 < s_rand, s_mask < r
    • compute Scalar_S = (s_rand + s_mask) mod r
    • compute Element_S = inv(s_mask * PWE)

Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request ✨

  • Peer, EAP-pwd-Commit/Response:
    • choose two random numbers, 1 < p_rand, p_mask < r
    • compute Scalar_P = (p_rand + p_mask) mod r
    • compute Element_P = inv(p_mask * PWE)

Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response 🎀

  • Server, EAP-pwd-Confirm/Request:
    • compute KS = (s_rand * (Scalar_P * PWE + Element_P))
    • compute ks = F(KS)
    • compute Confirm_S = H(ks | Element_S | Scalar_S | Element_P | Scalar_P | Ciphersuite)

Confirm_S is used to construct EAP-pwd-Confirm/Request 🌸

  • Peer, EAP-pwd-Confirm/Response:
    • compute KP = (p_rand * (Scalar_S * PWE + Element_S)),
    • compute kp = F(KP)
    • compute Confirm_P = H(kp | Element_P | Scalar_P | Element_S | Scalar_S | Ciphersuite)

Confirm_P is used to construct EAP-pwd-Confirm/Response 💜

the EAP Server ends up with the shared secret like this:

MK = H(ks | Confirm_P | Confirm_S)

and the EAP Peer gets it like this:

MK = H(kp | Confirm_P | Confirm_S)

the MSK and EMSK are derived from MK per Section 2.9 🔥

2.8.4.2. FFC Groups ✨

no mapping function, F(), needed for an FFC group!! 🙌 you just use the order, r, for the group (see Section 2.2.1 when the order is not part of the defined domain parameters):

  • Server, EAP-pwd-Commit/Request:
    • choose two random numbers, 1 < s_rand, s_mask < r
    • compute Scalar_S = (s_rand + s_mask) mod r
    • compute Element_S = inv(pwe^s_mask mod p)

Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request 🦋

  • Peer, EAP-pwd-Commit/Response:
    • choose random two numbers, 1 < p_rand, p_mask < r
    • compute Scalar_P = (p_rand + p_mask) mod r
    • compute Element_P = inv(pwe^p_mask mod p)

Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response 🧚

  • Server, EAP-pwd-Confirm/Request:
    • compute ks = ((pwe^Scalar_P mod p) * Element_P)^s_rand mod p
    • compute Confirm_S = H(ks | Element_S | Scalar_S | Element_P | Scalar_P | Ciphersuite)

Confirm_S is used to construct EAP-pwd-Confirm/Request 💖

  • Peer, EAP-pwd-Confirm/Response:
    • compute kp = ((pwe^Scalar_S mod p) * Element_S)^p_rand mod p
    • compute Confirm_P = H(kp | Element_P | Scalar_P | Element_S | Scalar_S | Ciphersuite)

Confirm_P is used to construct EAP-pwd-Confirm/Request 🌈

the EAP Server computes the shared secret as:

MK = H(ks | Confirm_P | Confirm_S)

the EAP Peer computes the shared secret as:

MK = H(kp | Confirm_P | Confirm_S)

the MSK and EMSK are derived from MK per Section 2.9 👑

2.8.5. Message Processing 💅

2.8.5.1. EAP-pwd-ID Exchange 🫶

okay bestie, EAP already has an Identity method to figure out who the peer is 🙈 BUT the Identity Response might be cut short or blurred for privacy, or decorated with routing info [RFC3748], so it's not really giving for the EAP-pwd method to use. that's why the EAP-pwd-ID exchange exists: to swap identities between the peer and the server ✨

the EAP-pwd-ID/Request has these bits:

  • a ciphersuite
  • a representation of the server's identity per Section 2.7.1
  • an anti-clogging token
  • a password pre-processing method

the ciphersuite picks the finite cyclic group, random function, and PRF that the server wants for the next authentication exchange 🔥

the anti-clogging token MUST be unpredictable and SHOULD NOT be from a source of random entropy. its whole job is to give the server proof that the peer making the EAP-pwd-ID/Response is legit and not part of a flooding attack 🛡️

the password pre-processing method gets communicated so both sides end up with the same canonical version of the password string (see Section 2.7.2) 🎀

the EAP-pwd-ID/Request is built according to Section 3.2.1 and then sent to the peer 💌

when the peer gets an EAP-pwd-ID/Request, it checks whether the ciphersuite and pre-processing method are acceptable. if not, the peer MUST respond with an EAP-NAK. if they're fine, the peer replies with an EAP-pwd-ID/Response (built according to Section 3.2.1) that acknowledges the Ciphersuite, token, and pre-processing method, and then adds its identity. after sending that Response, the peer knows the server's identity (from the Request), its own identity (which it encoded in the Response), and the password pre-processing algorithm, so it can compute the Password Element as specified in Section 2.8.3. the Password Element gets stored in state allocated for this exchange 🌸

the EAP-pwd-ID/Response acknowledges the Ciphersuite from the Request, acknowledges the anti-clogging token from the Request (that's the "liveness" demo, periodt 💅), and contains the peer's identity. when the server gets the Response, it checks that the Ciphersuite the peer acknowledged is the same one it sent, and that the anti-clogging token added in the Response matches the one from the Request. if the Ciphersuites or anti-clogging tokens differ, the server MUST respond with an EAP-Failure message. if the anti-clogging tokens match, the server knows the peer is an active participant in the exchange ✨ if the Ciphersuites match, the server now knows its own identity (which it encoded in the Request) and the peer's identity (from the Response), and can compute the Password Element according to Section 2.8.3. the server stores the Password Element in state it allocated for this exchange, and then starts an EAP-pwd-Commit exchange 🦋

2.8.5.2. EAP-pwd-Commit Exchange 🌈

the server kicks off the EAP-pwd-Confirm exchange by choosing two random numbers, s_rand and s_mask, between 1 and r (where r is described in Section 2.1 according to the group established in Section 2.8.5.1), with their sum modulo r greater than one (1). then it computes Element_S and Scalar_S as defined in Section 2.8.4, builds an EAP-pwd-Commit/Request according to Section 3.2.2, adds Element_S and Scalar_S to the state allocated for this exchange, and sends the EAP-pwd-Commit/Request to the peer 🧚

when the peer gets the EAP-pwd-Commit/Request, it checks the length of the whole payload against the expected lengths of Element_S and Scalar_S (which are fixed by the length of the agreed-upon group). if the length is wrong, the peer MUST terminate the exchange. if the length is right, the peer pulls Element_S and Scalar_S out of the EAP-pwd-Commit/Request. then Scalar_S gets checked to make sure it's between 1 and r, exclusive. if it's not, the peer MUST terminate the exchange. if it is, Element_S MUST be validated, depending on the type of group. validation for FFC groups is in Section 2.8.5.2.1, and validation for ECC groups is in Section 2.8.5.2.2 🔍

if validation works out, the peer picks two random numbers, p_rand and p_mask, between 1 and r (where r is described in Section 2.1 according to the group established in Section 2.8.5.1), with their sum modulo r greater than one (1), and computes Element_P and Scalar_P. next, the peer computes kp from p_rand, Element_S, Scalar_S, and the Password Element according to Section 2.8.4. if kp is the "identity element" -- the point at infinity for an ECC group or the value one (1) for an FFC group -- the peer MUST terminate the exchange. if not, the peer uses Element_P and Scalar_P to build an EAP-pwd-Commit/Response according to Section 3.2.2 and sends it to the server 💌

when the server gets the EAP-pwd-Commit/Response, it checks the length of the whole payload against the expected lengths of Element_P and Scalar_P (which are fixed by the agreed-upon group). if the length is wrong, the server MUST respond with an EAP-Failure message, and it MUST terminate the exchange and free up any state allocated. if the length is right, Scalar_P and Element_P get pulled out of the EAP-pwd-Commit/Response and compared to Scalar_S and Element_S. if Scalar_P equals Scalar_S and Element_P equals Element_S, that means a reflection attack, and the server MUST respond with an EAP-failure and terminate the exchange. if they differ, Scalar_P gets checked to make sure it's between 1 and r, exclusive. if it isn't, the server MUST respond with an EAP-failure and terminate the exchange. if it is, Element_P gets verified depending on the type of group. FFC validation is in Section 2.8.5.2.1, and ECC validation is in Section 2.8.5.2.2 🧐 if validation works, the server computes ks from s_rand, Element_P, Scalar_P, and the Password Element according to Section 2.8.4. if ks is the "identity element" -- the point at infinity for an ECC group or the value one (1) for an FFC group -- the server MUST respond with an EAP-failure and terminate the exchange. otherwise, the server starts an EAP-pwd-Confirm exchange 🎉

2.8.5.2.1. Element Validation for FFC Groups 🌸

a received FFC Element is valid if: 1) it's between one (1) and the prime, p, exclusive; and 2) modular exponentiation of the Element by the group order, r, equals one (1). if either of these isn't true, the received Element is invalid 🙅‍♀️

2.8.5.2.2. Element Validation for ECC Groups 💜

validating a received ECC Element means: 1) checking that both coordinates, x and y, are greater than zero (0) and less than the prime defining the underlying field; and 2) checking that the x- and y-coordinates satisfy the equation of the curve (so they make a valid point on the curve that is not the point at infinity). if either of these conditions isn't met, the received Element is invalid. otherwise, the Element is valid 🦋

2.8.5.3. EAP-pwd-Confirm Exchange ✨

okay so the server works out Confirm_S following Section 2.8.4, builds an EAP-pwd-Confirm/Request following Section 3.2.3, and sends it to the peer 💌

when the peer gets that EAP-pwd-Confirm/Request, it checks the length of the whole payload against the expected length of Confirm_S (fixed by whatever random function was agreed on) 📏. if the length is wrong, the peer MUST terminate the exchange and free up any state it allocated 🙅‍♀️. if the length checks out, the peer confirms that Confirm_S is the value it expects, based on kp 🔑. if Confirm_S is wrong, the peer MUST terminate the exchange and free up any state it allocated, no exceptions 💀. if Confirm_S is right, the peer computes Confirm_P, builds an EAP-pwd-Confirm/Response following Section 3.2.3, and sends it back to the server 🫶.

then the peer computes MK (following Section 2.8.4) and the MSK and EMSK (following Section 2.9), and stores them in the state it allocated for this exchange 🗝️. the peer SHOULD export the MSK and EMSK right then, in anticipation of a secure association protocol at the lower layer that uses them to create session keys ✨. or, if it'd rather, the peer can wait for an EAP-Success message from the server before exporting the MSK and EMSK 🦋.

when the server gets an EAP-pwd-Confirm/Response, it checks the length of the whole payload against the expected length of Confirm_P (again, fixed by the agreed-upon random function) 📐. if the length is wrong, the server MUST respond with an EAP-Failure message, and it MUST terminate the exchange and free up any state it allocated 😭. if the length is right, the server checks that Confirm_P is the value it expects, based on ks 🔐. if Confirm_P is wrong, the server MUST respond with an EAP-Failure message 🚫. if Confirm_P is right, the server computes MK (following Section 2.8.4) and the MSK and EMSK (following Section 2.9). then it exports the MSK and EMSK and responds with an EAP-Success message 🎉. the server SHOULD free up the state it allocated for this exchange 🧹.

2.9. Management of EAP-pwd Keys

[RFC5247] recommends that each EAP method define how to build a Method-ID and a Session-ID, so you can identify one particular EAP session between a peer and a server 🪪. here's how that gets put together:

    Method-ID = H(Ciphersuite | Scalar_P | Scalar_S)

    Session-ID = Type-Code | Method-ID

where Ciphersuite, Scalar_P, and Scalar_S all come from the specific exchange being identified 🔍. H is the random function specified in the Ciphersuite, and Type-Code is the code assigned to EAP-pwd, which is 52, represented as a single octet 🔢.

the authenticated key exchange in EAP-pwd generates a shared, authenticated key called MK 🤝. how big MK is depends on the random function H that's asserted in the Ciphersuite 📏. EAP-pwd has to export two 512-bit keys, MSK and EMSK. no matter what len(MK) is, implementations MUST invoke the KDF defined in Section 2.5 to build the MSK and EMSK 🧠. they're derived like this:

    MSK | EMSK = KDF(MK, Session-ID, 1024)

[RFC4962] talks about how important it is to name keys, especially when key caching is in use 🏷️. to make that optimization easier, names get assigned like so:

  • EMSK-name = Session-ID | 'E' | 'M'| 'S' | 'K'
  • MSK-name = Session-ID | 'M'| 'S' | 'K'

where 'E' is a single octet with the value 0x45, 'M' is a single octet with the value 0x4d, 'S' is a single octet with the value 0x53, and 'K' is a single octet with the value 0x4b 🔤.

this naming scheme lets key-management applications quickly and accurately find the keys for one particular session, or all the keys of one particular type 💜.

2.10. Mandatory-to-Implement Parameters

for interoperability's sake 🤝, compliant EAP-pwd implementations SHALL support the following parameters:

  • Diffie-Hellman Group: group 19 defined in [RFC5114]
  • Random Function: defined in Section 2.4
  • PRF: HMAC-SHA256 defined in [RFC4634]
  • Password Pre-Processing: none

3. Packet Formats 📦

3.1. EAP-pwd Header

the EAP-pwd header has this structure 👀:

     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      |L|M|  PWD-Exch |         Total-Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Data...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 5: EAP-pwd Header

Code 🔢 Either 1 (for Request) or 2 (for Response); see [RFC3748].

Identifier 🆔 The Identifier field is one octet and helps match responses with requests. The Identifier field MUST be changed on each Request packet 🔄.

Length 📏 The Length field is two octets and says how long the EAP packet is, counting the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception 🫧.

Type 🏷️ 52 - EAP-pwd

L and M bits 🚩 The L bit (Length included) is set to show that the two-octet Total-Length field is there, and it MUST be set for the first fragment of a fragmented EAP-pwd message or set of messages 📦.

The M bit (more fragments) is set on all but the last fragment 🧩.

PWD-Exch 🎭 The PWD-Exch field tells you what type of EAP-pwd payload is encapsulated in the Data field. This document defines these values for the PWD-Exch field:

  • 0x00 : Reserved
  • 0x01 : EAP-pwd-ID exchange
  • 0x02 : EAP-pwd-Commit exchange
  • 0x03 : EAP-pwd-Confirm exchange

All other values of the PWD-Exch field are unassigned 🤷‍♀️.

Total-Length 📐 The Total-Length field is two octets long, and it's only there if the L bit is set. It gives the total length of the EAP-pwd message or set of messages that's being fragmented 🧃.

3.2. EAP-pwd Payloads

every EAP-pwd payload has the EAP-pwd header plus encoded information 💅. the encoded information is made of sequences of data. payloads in the EAP-pwd-ID exchange also carry a ciphersuite statement, which says what finite cyclic group to use, what cryptographic primitive to use for H, and what PRF to use for deriving keys 🔐.

3.2.1. EAP-pwd-ID

the Group Description, Random Function, and PRF, in that order, make up the Ciphersuite that gets included in the calculation of the peer's and server's confirm messages 🧮.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Group Description       | Random Func'n |      PRF      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Token                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Prep     |                  Identity...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 6: EAP-pwd-ID Payload

the Group Description field value comes from the IANA registry for "Group Description", which was created by IKE [RFC2409] 🗂️.

this document defines this value for the Random Function field:

  • 0x01 : Function defined in this memo in Section 2.4

the value 0x00 is reserved for private use between mutually consenting parties. all other values of the Random Function field are unassigned 🚧.

the PRF field has this value:

the value 0x00 is reserved for private use between mutually consenting parties. all other values of the PRF field are unassigned 🔒.

the Token field holds an unpredictable value. the server assigns it in an EAP-pwd-ID/Request, and the peer acknowledges it in an EAP-pwd-ID/Response (see Section 2.8.5) 🎟️.

the Prep field represents the password pre-processing technique (see Section 2.7.2) that the client uses before generating the password seed (see Section 2.8.3). this document defines these values for the Prep field:

  • 0x00 : None
  • 0x01 : RFC2759
  • 0x02 : SASLprep

all other values of the Prep field are unassigned 🧼.

the Identity field depends on the tuple of PWD-Exch/Code:

  • EAP-pwd-ID/Request : Server_ID
  • EAP-pwd-ID/Response : Peer_ID

the length of the identity is computed from the Length field in the EAP header 📏.

3.2.2. EAP-pwd-Commit

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                           Element                             ~
    |                                                               |
    ~                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
    |                                                               |
    ~                            Scalar             +-+-+-+-+-+-+-+-+
    |                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: EAP-pwd-Commit Payload

the Element and Scalar fields depend on the tuple of PWD-Exch/Code:

  • EAP-pwd-Commit/Request : Element_S, Scalar_S
  • EAP-pwd-Commit/Response : Element_P, Scalar_P

the Element is encoded according to Section 3.3. the length of the Element is worked out by the finite cyclic group from the agreed-upon Ciphersuite. the length of the scalar can then be computed from the Length in the EAP header 🧮.

3.2.3. EAP-pwd-Confirm

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                            Confirm                            ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 8: EAP-pwd-Confirm Payload

the Confirm field depends on the tuple of PWD-Exch/Code:

  • EAP-pwd-Confirm/Request : Confirm_S
  • EAP-pwd-Confirm/Response : Confirm_P

the length of the Confirm field is computed from the Length in the EAP header 📏.

3.3. Representation of Group Elements and Scalars

payloads in the EAP-pwd-Commit exchange carry elements from the agreed-upon finite cyclic cryptographic group, which is either an FFC group or an ECC group 🧑‍🔬. for interoperability, field elements and scalars MUST be represented in payloads according to the requirements described below 💖.

3.3.1. Elements in FFC Groups 🎀

Okay bestie, let's start with FFC groups 💅. Elements in an FFC group MUST be represented (in binary form) as unsigned integers that are strictly less than the prime, p, from the group's domain parameter set. The binary representation of each group element MUST have a bit length equal to the bit length of the binary representation of p. If it's too short, the length requirement gets enforced by prepending zeros to the integer until it hits the required length 🌸.

3.3.2. Elements in ECC Groups 🦋

Now for ECC groups, which are giving curves 🌈. Elements in an ECC group are points on the agreed-upon elliptic curve. Each such element MUST be represented by the concatenation of two components, an x-coordinate and a y-coordinate ✨.

Each of the two components, the x-coordinate and the y-coordinate, MUST be represented (in binary form) as an unsigned integer that is strictly less than the prime, p, from the group's domain parameter set. The binary representation of each component MUST have a bit length equal to the bit length of the binary representation of p. Same deal as before: if it's too short, you prepend zeros until the required length is achieved 🧚.

Since the field element is represented in a payload by the x-coordinate followed by the y-coordinate, the length of the element in the payload MUST be twice the bit length of p. In other words, "compressed representation" is not used 🙈.

3.3.3. Scalars 💜

Scalars MUST be represented (in binary form) as unsigned integers that are strictly less than r, the order of the generator of the agreed-upon cryptographic group. The binary representation of each scalar MUST have a bit length equal to the bit length of the binary representation of r. This requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved 🍓.

4. Fragmentation ✨

Okay so EAP [RFC3748] is a request-response protocol 💬. The server sends requests and the peer responds. These request and response messages are assumed to be limited to at most 1020 bytes. Messages in EAP-pwd can be larger than 1020 bytes, which means they need fragmentation and reassembly support 😭.

Implementations MUST establish a fragmentation threshold that indicates the maximum size of an EAP-pwd payload. When an implementation knows the maximum transmission unit (MTU) of its lower layer, it SHOULD calculate the fragmentation threshold from that value. If there's no knowledge of the lower layer's MTU, the fragmentation threshold MUST be set to 1020 bytes 🔥.

Since EAP is a simple ACK-NAK protocol, fragmentation support can be added in a simple manner, which is so iconic 👑. In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field like the one IPv4 has 🦋.

EAP-pwd fragmentation support is provided through the addition of flags within the EAP-Response and EAP-Request packets, plus a Total-Length field of two octets. The flags include the Length included (L) and More fragments (M) bits. The L flag is set to indicate the presence of the two-octet Total-Length field, and it MUST be set for the first fragment of a fragmented EAP-pwd message or set of messages. The M flag is set on all but the last fragment. The Total-Length field is two octets and provides the total length of the EAP-pwd message or set of messages that is being fragmented, which simplifies buffer allocation 🎀.

When an EAP-pwd peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-pwd and no data. This serves as a fragment ACK 🫶. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. To prevent errors in processing fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value 💅.

Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-pwd and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. To prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response 🌈.

5. IANA Considerations 🌸

This memo contains new numberspaces to be managed by IANA 🧚. The policies used to allocate numbers are described in [RFC5226]. IANA has allocated a new EAP method type for EAP-pwd (52) 🍓.

IANA has created new registries for PWD-Exch messages, random functions, PRFs, and password pre-processing methods, and has added the message numbers, random function, PRF, and pre-processing methods specified in this memo to those registries, respectively 💜.

The following is the initial PWD-Exch message registry layout:

o   0x00 : Reserved

o   0x01 : EAP-pwd-ID exchange

o   0x02 : EAP-pwd-Commit exchange

o   0x03 : EAP-pwd-Confirm exchange

The PWD-Exch field is 6 bits long. The value 0x00 is reserved. All other values are available through assignment by IANA. IANA is instructed to assign values based on "IETF Review" (see [RFC5226]) ✨.

The following is the initial Random Function registry layout:

o   0x00 : Private Use

o   0x01 : Function defined in this memo, Section 2.4

The Random Function field is 8 bits long. The value 0x00 is for Private Use between mutually consenting parties. All other values are available through assignment by IANA. IANA is instructed to assign values based on "Specification Required" (see [RFC5226]). The Designated Expert performing the necessary review MUST ensure the random function has been cryptographically vetted 🔥.

The following is the initial PRF registry layout:

o   0x00 : Private Use

o   0x01 : HMAC-SHA256 as defined in [RFC4634]

The PRF field is 8 bits long. The value 0x00 is for Private Use between mutually consenting parties. All other values are available through assignment by IANA. IANA is instructed to assign values based on "IETF Review" (see [RFC5226]) 🦋.

The following is the initial layout for the password pre-processing method registry:

o   0x00 : None

o   0x01 : RFC2759

o   0x02 : SASLprep

The Prep field is 8 bits long, and all other values are available through assignment by IANA. IANA is instructed to assign values based on "Specification Required" (see [RFC5226]) 👑.

6. Security Considerations 🔥

Okay, this part is seriously important, so let's get into it 🙈. In Section 1.3, several security properties were presented that motivated the design of this protocol. This section addresses how well they are met 💀.

6.1. Resistance to Passive Attack 🕵️

A passive attacker will see Scalar_P, Element_P, Scalar_S, and Element_S. She can guess at passwords to compute the password element, but she will not know s_rand or p_rand, and therefore she will not be able to compute MK 😭.

The secret random value of the peer (server) is effectively hidden by adding p_mask (s_mask) to p_rand (s_rand) modulo the order of the group. If the order is "r", then there are approximately "r" distinct pairs of numbers that will sum to the value Scalar_P (Scalar_S). Attempting to guess the particular pair is just as difficult as guessing the secret random value p_rand (s_rand), and the probability of a guess is 1/(r - i) after "i" guesses. For a large value of r, this exhaustive search technique is computationally infeasible 🌸.

An attacker would do better by determining the discrete logarithm of Element_P (Element_S) using an algorithm like the baby-step giant-step algorithm (see [APPCRY]), which runs on the order of the square root of r group operations (e.g., a group with order 2^160 would require 2^80 exponentiations or point multiplications). Based on the assumptions made on the finite cyclic group in Section 2.3, that is also computationally infeasible 🧚.

6.2. Resistance to Active Attack 💅

An active attacker can launch her attack after an honest server has sent EAP-pwd-Commit/Request to an honest peer. This would result in the peer sending EAP-pwd-Commit/Response. In this case, the active attack has been reduced to that of a passive attacker, since p_rand and s_rand will remain unknown. The active attacker could forge a value of Confirm_P (Confirm_S) and send it to the EAP server (EAP peer) in the hope that it will be accepted, but due to the assumptions on H made in Section 2.3, that is computationally infeasible 🙅‍♀️.

The active attacker can also launch her attack by forging EAP-pwd-Commit/Request and sending it to the peer. This will result in the peer responding with EAP-pwd-Commit/Response. The attacker can then attempt to compute ks, but since she doesn't know the password, this is infeasible. It can be shown that an attack by forging an EAP-pwd-Commit/Response is an identical attack with equal infeasibility 🌈.

6.3. Resistance to Dictionary Attack ✨

okay so bestie, this is the part where an attacker tries to guess the password, and the protocol is like "nice try, but no" 💅 An active attacker can wait until an honest server sends EAP-pwd-Commit/Request, then forge EAP-pwd-Commit/Response and send it to the server. The server responds with EAP-pwd-Confirm/Request. Now the attacker can try a dictionary attack 👀 She can guess at potential passwords, compute the password element, and compute kp using her p_rand, Scalar_S, and Element_S from the EAP-pwd-Commit/Request plus the candidate password element from her guess. She knows her guess is correct when she can verify Confirm_S in EAP-pwd-Confirm/Request. 🎀

But here's the tea 🍵 the attacker already committed to a password guess in her forged EAP-pwd-Commit/Response when she computed Element_P. That value got used by the server when he computed ks, which he then used to build Confirm_S in EAP-pwd-Confirm/Request. So any guess that differs from the one in her forged EAP-pwd-Commit/Response can't be verified, because she has no way of knowing whether it's correct 😭 She gets one guess and only one guess per attack. That means any advantage she gains (guess a password, and if it fails, cross it off the pool and try again) comes solely from interacting with an honest protocol peer. No computation shortcut, just vibes and repeated active contact 💀

The attacker can also commit to a guess with the forged EAP-pwd-Commit/Response, then run through the whole dictionary, computing the password element and ks with her forged Scalar_P and Element_P. She knows she's right if she can reproduce the same Confirm_S the server produced in EAP-pwd-Confirm/Request. But that requires knowing s_rand, which we already said was not possible 🙅‍♀️

The password element PWE/pwe is picked using the method in Section 2.8.3. Since it's an element in the group, there's a scalar value, q, where:

PWE = q * G, for an ECC group

pwe = g^q mod p, for an FFC group

Knowing q can be used to launch a dictionary attack 🧐 For brevity, I'll show it with an ECC group. Here's how it goes:

The attacker waits until an honest server sends an EAP-pwd-Commit/Request. Then she generates a random Scalar_P and a random p_mask, and computes Element_P = p_mask * G. She sends the bogus Scalar_P and Element_P to the server and gets Confirm_S back. Note that the server cannot tell that Element_P was calculated incorrectly 🫣

Now the attacker knows that:

KS = (Scalar_P * q + p_mask) * s_rand * G

and

s_rand * G = Scalar_P * G - ((1/q) mod r * -Element_P)

Since Scalar_P, p_mask, G, and Element_P are all known, she can run through the dictionary, make a password guess, compute PWE using the technique in Section 2.8.3, determine q, and then use the equations above to compute KS and check whether she can verify Confirm_S. BUT to determine q for a candidate PWE, she'd need a discrete logarithm, which Section 2.3 assumed is computationally infeasible. So this attack is also a no-go 🙅‍♀️✨

The best advantage an attacker can get from a single active attack is learning whether one password guess was correct. So her advantage comes from interaction, not computation, and that's exactly what resistance to dictionary attack is supposed to mean 💖

Resistance to dictionary attack means the attacker must run an active attack for each single guess at the password. If the dictionary the password came from has size D, and every password in it is equally likely, then the chance of success after one guess is 1/D. After X guesses, with failed guesses removed from the pool, the chance becomes 1/(D-X). As X grows, so does the chance of success. So yeah, an attacker can figure out the password through repeated brute-force, active guessing 😬 This protocol does not claim to be secure against that by itself, so implementations SHOULD make sure D is large enough to stop this attack. Implementations SHOULD ALSO take countermeasures, like refusing authentication attempts for a certain amount of time once the number of failed attempts hits a certain threshold. No such threshold or amount of time is recommended in this memo 🌸

6.4. Forward Secrecy 🦋

The MSK and EMSK are extracted from MK, which is derived from group operations using s_rand, p_rand, and the password element. The peer and server choose random values every time the protocol runs. So even if an attacker learns the password, she won't know the random values either side used in an earlier run, and she'll be unable to work out MK, or the MSK or EMSK. This is the definition of Forward Secrecy 🔐👑

6.5. Group Strength 💪

The strength of the shared secret, MK, derived in Section 2.8.4, depends on how much effort it takes to solve the discrete logarithm problem in the chosen group. [RFC3766] has a great discussion on how strong symmetric keys derived from discrete logarithm cryptography are 📚

The mandatory-to-implement group defined in this memo is group 19, a group from [RFC5114] based on Elliptic Curve Cryptography (see Section 2.2.2) with a prime bit length of 256. This group was picked because the current best estimate for a symmetric key derived from it is 128 bits, which is the typical key length for the Advanced Encryption Standard ([FIPS-197]) 🔥 You can get an equivalent level of strength with a group based on Finite Field Cryptography (see Section 2.2.1), but it would need a much larger prime and be way more memory and compute intensive. Nobody wants that, bestie 🙅‍♀️

6.6. Random Functions 🎲

The protocol in this memo uses a function called a "random oracle" (as defined in [RANDOR]). Building a random oracle out of handy cryptographic primitives takes a LOT of care 🥹 The random oracle used here is based on the notion of a "Randomness Extractor" from [RFC5869] ✨

This protocol can use any properly instantiated random oracle. To make sure any new value for H uses a properly instantiated random oracle, IANA has been instructed (in Section 5) to only allocate values from the Random Function registry after an expert has vetted them 🧚

A few of the defined groups that work with this protocol have a security estimate (see Section 6.5) under 128 bits, but many don't. To keep the random function from being the bottleneck (or a target for attack), any new random function MUST map its input to a target of at least 128 bits, and SHOULD map its input to a target of at least 256 bits 🌈💜

7. Security Claims ✨

okay bestie, this is the part where the EAP-pwd spec lays out its whole security report card 💅 RFC 3748 says any new EAP method has to clearly spell out its security properties, and RFC 4017 adds a bunch more for wireless LANs. so here's the lineup, no cap 🎀

  • a. mechanism: password.
  • b. claims:
    • mutual authentication: the peer and server both prove they know a shared password, so they authenticate each other 🫶 This is REQUIRED by [RFC4017].
    • forward secrecy: if the password gets compromised, the secret keys (MK, MSK, or EMSK) from earlier runs of the protocol are still safe 🦋
    • replay protection: an attacker can't replay messages from an earlier exchange to learn the password or a derived key, and can't trick the peer or server into thinking the exchange finished when it didn't 🙈 Reflection attacks get foiled because the server checks that the scalar and element from the peer don't equal its own 👑
    • key derivation: keys come from a group operation in a finite cyclic group (like exponentiation), using secret data from both the peer and server 🔥 The MSK and EMSK come from that shared secret. This is REQUIRED by [RFC4017].
    • dictionary attack resistance: an attacker only gets one password guess per active attack, so their advantage comes from interacting, not from crunching numbers 💀 This is REQUIRED by [RFC4017].
    • session independence: the protocol resists active and passive attacks, and neither kind lets someone compromise later or earlier MSKs or EMSKs 🧚
    • Denial-of-Service Resistance: an attacker can make a server allocate state and burn CPU cycles generating Scalar_S and Element_S 😭 But that's gated: the attacker first needs connectivity through a lower-layer protocol (like 802.11 authentication followed by association, or 802.3 "link-up") and has to answer two EAP messages, the EAP-ID/Request and the EAP-pwd-ID/Request. The EAP-pwd-ID exchange also has an anti-clogging token, which gives the server some assurance the peer is doing a bit of real processing and not just spraying packets 🌸 That stops distributed denial-of-service attacks and makes the attacker announce and commit to a lower-layer identity, like a MAC (Media Access Control) address 🍓
    • Man-in-the-Middle Attack Resistance: the exchange resists active attacks, and that's a requirement for launching a man-in-the-middle attack, so this is a big win 🙌 This is REQUIRED by [RFC4017].
    • shared state equivalence: when EAP-pwd finishes, the peer and server agree on MK, MSK, EMSK, Method-ID, and Session-ID ✨ The peer authenticates the server based on the Server-ID, and the server authenticates the peer based on the Peer-ID. That works because Peer-ID, Server-ID, and the shared password all get combined into the password element, which has to be shared between peer and server for the exchange to complete 💜 This is REQUIRED by [RFC4017].
    • fragmentation: the protocol defines a fragmentation and reassembly technique in Section 4 🧩
    • resistance to "Denning-Sacco" attack: learning keys from an earlier run, like the MSK or EMSK, won't help an adversary learn the password 🌈
  • c. key strength: the strength of the resulting key depends on the finite cyclic group you pick. See Section 6.5. This is REQUIRED by [RFC4017]. 💖
  • d. key hierarchy: MSKs and EMSKs get derived from the MK using the KDF defined in Section 2.5, as described in Section 2.8.4 🎀
  • e. vulnerabilities (note that none of these are REQUIRED by [RFC4017]) 🥺
    • protected ciphersuite negotiation: the ciphersuite offer from the server isn't protected from tampering by an active attacker. BUT downgrade attacks are still prevented, since this isn't a "negotiation" with a list of acceptable ciphersuites 🙅‍♀️ If an attacker modifies a Ciphersuite, the confirm messages won't match, because each side binds the Ciphersuite into its confirm message, and the protocol fails as a result.
    • confidentiality: none of the messages in this protocol are encrypted 👀
    • integrity protection: messages in the EAP-pwd-Commit exchange are not integrity protected 😬
    • channel binding: this protocol doesn't let you exchange integrity-protected channel information to compare with values sent out-of-band 🫠
    • fast reconnect: no fast-reconnect capability here 🥲
    • cryptographic binding: this isn't a tunneled EAP method, so there's no cryptographic information to bind 🤷‍♀️
    • identity protection: the EAP-pwd-ID exchange isn't protected. An attacker can see the server's identity in the EAP-pwd-ID/Request and the peer's identity in the EAP-pwd-ID/Response 👀🙈

8. Acknowledgements 🎀

the authors gave some major shoutouts here 🫶 Scott Fluhrer discovered the "password as exponent" attack that was possible in the initial version of this memo, and gave super helpful tips on fixing PWE/pwe to prevent it 👑 Hideyuki Suzuki spotted an attack against a previous version of the underlying key exchange protocol 🦋 Lily Chen helped with hashing into an elliptic curve, and Jin-Meng Ho suggested countermeasures against a small sub-group attack 💜 Rich Davis suggested the defensive checks on Commit messages and made the memo and the underlying key exchange way better 🔥 Scott Kelly suggested adding the anti-clogging token to the ID exchange to stop distributed denial-of-service attacks 🌸 Dorothy Stanley gave valuable suggestions too 🧚 And the fragmentation method came from [RFC5216] ✨

9. References 📚

9.1. Normative References

[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2759]    Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
             RFC 2759, January 2000.

[RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
             Internationalized Strings ("stringprep")", RFC 3454,
             December 2002.

[RFC3748]    Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
             H. Levkowetz, "Extensible Authentication Protocol
             (EAP)", RFC 3748, June 2004.

[RFC4013]    Zeilenga, K., "SASLprep: Stringprep Profile for User
             Names and Passwords", RFC 4013, February 2005.

[RFC4282]    Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
             Network Access Identifier", RFC 4282, December 2005.

[RFC4634]    Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
             (SHA and HMAC-SHA)", RFC 4634, July 2006.

[RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 5226,
             May 2008.

[SP800-108]  Chen, L., "Recommendations for Key Derivation Using
             Pseudorandom Functions", NIST Special
             Publication 800-108, April 2008.

[SP800-56A]  Barker, E., Johnson, D., and M. Smid, "Recommendations
             for Pair-Wise Key Establishment Schemes Using Discrete
             Logarithm Cryptography", NIST Special
             Publication 800-56A, March 2007.

9.2. Informative References ✨

okay bestie, these are the "extra reading" sources 📚🫶 nothing here is required to implement the spec, but they're the receipts behind the ideas. 🧠 Here's the full list, typos and all:

  • [APPCRY] Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press Series on Discrete Mathematics and Its Applications, 1996.
  • [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attack", Proceedings of the IEEE Symposium on Security and Privacy, Oakland, 1992.
  • [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: A Password-Based Protocol Secure against Dictionary Attacks and Password File Compromise", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, 1993.
  • [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman", Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 2000.
  • [FIPS-197] National Institute of Standards and Technology, FIPS Pub 197: Advanced Encryption Standard (AES), November 2001.
  • [JAB96] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM SIGCOMM Computer Communication Review Volume 1, Issue 5, October 1996.
  • [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary Attacks Without Encrypting Public Keys", Proceedings of the Security Protocols Workshop, LNCS 1361, Springer-Verlag, 1997.
  • [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, 1993.
  • [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
  • [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
  • [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
  • [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
  • [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
  • [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
  • [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
  • [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
  • [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.

Authors' Addresses 🎀

these are the humans who wrote it, so you know who to thank (or tag) 💅💖

Dan Harkins 🧚

Dan Harkins
Aruba Networks
1322 Crossman Avenue
Sunnyvale, CA  94089-1113
USA

EMail: dharkins@arubanetworks.com

Glen Zorn 🌸

Glen Zorn
Network Zen
1310 East Thomas Street
#306
Seattle, WA  98102
USA

Phone: +1 (206) 377-9035
EMail: gwz@net-zen.net

and that's the whole RFC, bestie!! 🌈✨ we made it 😭🫶

📦 where this page comes from