RFC 6124
An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol
RFC 6124: An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol 🎀
Title block tea ☕
- Request for Comments: 6124 (published by the IETF 💖)
- Authors: Y. Sheffer (Independent), G. Zorn (Network Zen), H. Tschofenig (Nokia Siemens Networks), and S. Fluhrer (Cisco) 👯♀️
- Category: Informational 📚 (this is not a Standards Track spec, just published for info)
- ISSN: 2070-1721
- Date: February 2011 📅
- Obsoletes / Updates: this doc doesn't list any RFCs it obsoletes or updates 🙅♀️
Abstract ✨
okay so EAP is a framework that lets you use lots of different authentication mechanisms 🦋. This doc defines one of them, called EAP-EKE, which is built on the Encrypted Key Exchange (EKE) protocol 🔐. The main vibe: it gives you mutual authentication using a short, easy-to-remember password 🧠. Compared with other common auth methods, EAP-EKE is not susceptible to dictionary attacks 🙈. And the best part? It doesn't need public-key certificates at all 💅.
Status of This Memo 🌸
this document is not an Internet Standards Track spec. It's published for informational purposes, so no pressure 🫶.
It is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the deets 🤓.
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6124.
Copyright Notice ⭐
Copyright (c) 2011 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 stood on the publication date. Read these carefully, bestie, because they describe your rights and restrictions for this document 📜. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 🧾.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😬. So unless you get a proper license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 4
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 7
4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. The EAP-EKE-ID Payload . . . . . . . . . . . . . . . . 8
4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 10
4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11
4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 12
4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13
4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14
4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14
5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 15
5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 15
5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 17
5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 18
5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 18
5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 19
6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 19
6.1. Generating Keying Material . . . . . . . . . . . . . . . . 19
6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 20
6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 27
8.2. Diffie-Hellman Group Considerations . . . . . . . . . . . 28
8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 28
8.4. Identity Protection, Anonymity, and Pseudonymity . . . . . 28
8.5. Password Processing and Long-Term Storage . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 311. Introduction 💖
The main way people get onto the Internet today is a human typing a username and password to prove who they are to a computer that's controlling access 🔑. Proving you know the password is what authenticates the human to 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 single time they want network access ⌨️. That means 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 we really want a robust auth method that stays secure even when the password is weak and the attacker is strong 💪.
EAP-EKE is an EAP method [RFC3748] that tackles password-based authenticated key exchange. It uses a possibly weak password for authentication and to derive a shared secret that's both authenticated and cryptographically strong 🔥. This problem was first described by Bellovin and Merritt in [BM92] and [BM93]. Since then, other solution approaches have been proposed, for example [JAB96], [LUC97], [BMP00], and others 🌷.
This proposal is based on the original Encrypted Key Exchange (EKE) proposal, as described in [BM92]. Some variants of the original EKE have been attacked (see e.g., [PA97]), and improvements have been proposed 🕵️♀️. None of those later improvements have been added to the current protocol. Instead, we used only the subset of [BM92] (namely the variant described in Section 3.1 of that paper) that has held up over time and is believed secure as of this writing 🦋.
2. Terminology 🎀
This document uses Encr(Ke, ...) to denote encrypted information, and Prot(Ke, Ki, ...) to denote encrypted and integrity-protected information 🧁.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖.
3. Protocol 🧚♀️
EAP is a two-party protocol spoken between an EAP peer and an EAP server (also known as "authenticator") 🗣️. An EAP method defines the specific authentication protocol that EAP uses. This memo defines one particular method, so it defines the messages sent between the EAP server and the EAP peer for the purpose of authentication and key derivation 🔑✨.
3.1. Message Flows 🦋
okay so a successful EAP-EKE run is basically three message exchanges: an Identity exchange, a Commit exchange, and a Confirm exchange 💖 Figure 1 shows the whole flow.
+--------+ +--------+
| | EAP-EKE-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| (P) | EAP-EKE-ID/Response | (S) |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
Figure 1: A Successful EAP-EKE Exchangeso the peer and server use the Identity exchange to learn each other's identities and agree on a ciphersuite for the later steps 🎀 the Commit exchange is where they swap info to make a shared key AND bind each other to a particular guess of the password 🔥 then the Confirm exchange is the proof: both sides prove they're alive and that they know the password by making and checking verification data 💅 (fun fact, the second message of the Commit exchange already does a big chunk of this liveness proof, iykyk 🙈)
the original exchange from [BM92] (just with the roles flipped) looks like this, schematically 🌸
Server Peer
------ ----
Encr(Password, y_s) ->
<- Encr(Password, y_p), Encr(SharedSecret, Nonce_P)
Encr(SharedSecret, Nonce_S | Nonce_P) ->
<- Encr(SharedSecret, Nonce_S)where:
- Password is a typically short string, shared between the server and the peer. Same password is used to authenticate the server to the peer AND vice versa 🔐
y_sandy_pare the server's and the peer's ephemeral public keys, i.e.y_s = g ^ x_s (mod p)andy_p = g ^ x_p (mod p)✨- Nonce_S and Nonce_P are random strings made by the server and the peer as cryptographic challenges 🎲
- SharedSecret is the secret from Diffie-Hellman, namely
SharedSecret = g^(x_s * x_p) (mod p). the server calculates it asSharedSecret = y_p ^ x_s (mod p), and the peer calculates it asSharedSecret = y_s ^ x_p (mod p)🧚
the current protocol extends that basic crypto protocol, so the regular successful exchange becomes:
Message Server Peer
--------- -------- ------
ID/Request ID_S, CryptoProposals ->
ID/Response <- ID_P, CryptoSelection
Commit/Request Encr(Password, y_s) ->
Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P)
Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S ->
Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_Pand on top of the terminology above:
- Encr means encryption only, and Prot is encryption WITH integrity protection 🛡️
- Ke is an encryption key, and Ki is an integrity-protection key 🗝️
Section 5 explains all the crypto values and how they're derived 💜
so as you can see in that exchange, a few new info elements got added to the original protocol: identity values for BOTH parties (ID_S, ID_P), negotiation of crypto protocols, and signature fields that protect the integrity of the negotiated parameters (Auth_S, Auth_P) 👑 also, the shared secret doesn't get used directly anymore 🙈 this first look skips a few details for clarity, so Section 5 is the authoritative source for message and field details, bestie 📖
4. Message Formats ✨
EAP-EKE only defines a small number of message types, and every message is a header followed by a payload 🎀 this section defines the header, several payload formats, and the format of specific fields inside those payloads.
As usual, all multi-octet strings MUST be laid out in network byte order. 🌐
4.1. EAP-EKE Header 🦋
the EAP-EKE header is the standard EAP header (see Section 4 of [RFC3748]) followed by an EAP-EKE exchange type 💅 here's the 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 | EKE-Exch | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EAP-EKE Headerthe Code, Identifier, Length, and Type fields are all part of the EAP header defined in [RFC3748] 🫶 the Type field is 53 for EAP-EKE Version 1 🔥
the EKE-Exch (EKE Exchange) field tells you what kind of EAP-EKE payload is inside the Data field. this document defines these values for EKE-Exch:
0x00: Reserved0x01: EAP-EKE-ID exchange0x02: EAP-EKE-Commit exchange0x03: EAP-EKE-Confirm exchange0x04: EAP-EKE-Failure message
more EKE-Exch values can be added later through IANA registration (Section 7.7) 🧚
4.2. EAP-EKE Payloads 💖
every EAP-EKE message has the EAP-EKE header plus info in ONE payload, and the payload is different for each exchange 🍓
4.2.1. The EAP-EKE-ID Payload 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumProposals | Reserved | Proposal ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Proposal | IDType | Identity ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EAP-EKE-ID Payloadthe EAP-EKE-ID payload has these fields:
NumProposals:
the NumProposals field holds how many Proposal fields come after it in the payload 🔢 in the EAP-EKE-ID/Request message, NumProposals MUST NOT be set to zero (0), and in the EAP-EKE-ID/Response message, NumProposals MUST be set to one (1) 💅 the offered proposals in the Request are listed back to back in priority order, most preferable first ✨ and the selected proposal in the Response MUST be fully identical with one of the offered proposals 🫶
Reserved:
this field MUST be sent as zero, and MUST be ignored by the recipient 🙈
Proposal:
each proposal is four one-octet fields, in this order 🎀
- Group Description: the value comes from the IANA registry for Diffie-Hellman groups defined in Section 7.1 🌈
- Encryption: the value comes from the IANA registry for encryption algorithms defined in Section 7.2 🔐
- PRF: the value comes from the IANA registry for pseudo-random functions defined in Section 7.3 🧚
- MAC: the value comes from the IANA registry for keyed message digest algorithms defined in Section 7.4 🗝️
IDType:
this denotes the Identity Type, taken from the IANA registry defined in Section 7.5 🪪 the server and the peer MAY use different identity types 💖 and ALL implementations MUST be able to receive two identity types: ID_NAI and ID_FQDN 👑
Identity:
what the Identity field means depends on the Code and IDType fields 🔍
- EAP-EKE-ID/Request: server ID
- EAP-EKE-ID/Response: peer ID
the length of the Identity field is computed from the Length field in the EAP header. specifically, its length is:
eap_header_length - 9 - 4 * number_of_proposalsand like every other field in this specification, the Identity field MUST be octet-aligned 📐
4.2.2. The EAP-EKE-Commit Payload 🦋
this payload lets both parties send their encrypted ephemeral public key, and the peer also includes a Challenge 💜
the server and/or the peer can also include a small amount of data for channel binding 🎀 this data goes out UNPROTECTED here, but it gets verified later, when it's signed by the Auth_S/Auth_P payloads in the EAP-EKE-Confirm 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHComponent_S/DHComponent_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBValue (zero or more occurrences) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP-EKE-Commit PayloadDHComponent_S/DHComponent_P:
this holds the password-encrypted Diffie-Hellman public key, generated as described in Section 5.1 🔐 its size depends on the group and the encryption algorithm 📏
PNonce_P:
this field ONLY shows up in the response, and holds the encrypted and integrity-protected challenge value sent by the peer 🧁 its size is set by the encryption and MAC algorithms in use, since this protocol mandates a fixed nonce size for a given choice of algorithms. see Section 5.2 💅
CBValue:
this structure MAY be included in both the request and the response, and MAY be repeated multiple times in a single payload 🌈 see Section 4.5. each structure carries its own length 🫶 the field is neither encrypted nor integrity protected; instead, it's protected by the AUTH payloads in the Confirm exchange 🛡️
4.2.3. The EAP-EKE-Confirm Payload 🏁
Okay bestie, this is the finish line! 🏁 Both parties use this payload to wrap up the whole auth dance: they make a shared temporary key, check that the entire protocol hasn't been messed with, and cook up the key material the EAP consumer protocol needs. It's literally the main event ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_PS/PNonce_S ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth_S/Auth_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: EAP-EKE-Confirm Payload 🎀
PNonce_PS/PNonce_S:
This field ("protected nonce") holds the encrypted and integrity-protected response to the other party's challenge. Check out Sections 5.3 and 5.4 for the details 🔐 Just like the PNonce_P field, its size is decided by the encryption and MAC algorithms.
Auth_S/Auth_P:
This field signs the preceding messages, including the Identity and the negotiated fields. That stops sneaky stuff like algorithm downgrade attacks 🙅 See Section 5.3 and Section 5.4. The size depends on the pseudo-random function that got negotiated.
4.2.4. The EAP-EKE-Failure Payload 💀
The EAP-EKE-Failure payload format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: EAP-EKE-Failure Payload 🎀
The payload's size is always exactly 4 octets. 💅
The following Failure-Code values are defined:
+------------+----------------+-------------------------------------+
| Value | Name | Meaning |
+------------+----------------+-------------------------------------+
| 0x00000000 | Reserved | |
| 0x00000001 | No Error | This code is used for failure |
| | | acknowledgement, see below. |
| 0x00000002 | Protocol Error | A failure to parse or understand a |
| | | protocol message or one of its |
| | | payloads. |
| 0x00000003 | Password Not | A password could not be located for |
| | Found | the identity presented by the other |
| | | protocol party, making |
| | | authentication impossible. |
| 0x00000004 | Authentication | Failure in the cryptographic |
| | Failure | computation, most likely caused by |
| | | an incorrect password or an |
| | | inappropriate identity type. |
| 0x00000005 | Authorization | While the password being used is |
| | Failure | correct, the user is not authorized |
| | | to connect. |
| 0x00000006 | No Proposal | The peer is unwilling to select any |
| | Chosen | of the cryptographic proposals |
| | | offered by the server. |
+------------+----------------+-------------------------------------+Additional values of this field are available via IANA registration, see Section 7.8. 🌈
When the peer hits an error situation, it MUST respond with EAP-EKE-Failure. The server MUST reply with an EAP-Failure message to end the exchange. 🙅♀️
When the server hits an error situation, it MUST respond with EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message containing a "No Error" failure code. Then the server MUST send an EAP-Failure message to end the exchange. Such a dramatic little dance 😭
Implementing the "Password Not Found" code is not mandatory. For security reasons, implementations MAY choose to return "Authentication Failure" also in cases where the password cannot be located. 🙈
4.3. Protected Fields 🔒
Several fields are encrypted and integrity-protected. They're denoted Prot(...), and their general structure looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Random Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value (ICV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Protected Field Structure 🎀
The protected field is a concatenation of three octet strings:
- An optional IV, required when the encryption algorithm/mode necessitates it, e.g., for CBC encryption. The content and size of this field are determined by the selected encryption algorithm. In the case of CBC encryption, this field is a random octet string having the same size as the algorithm's block size.
- The original data, followed if necessary by random padding. This padding has the minimal length (possibly zero) required to complete the length of the encrypted data to the encryption algorithm's block size. The original data and the padding are encrypted together.
- ICV, a Message Authentication Code (MAC) cryptographic checksum of the encrypted data, including the padding. The checksum is computed over the encrypted, rather than the plaintext, data. Its length is determined by the MAC algorithm negotiated.
We note that because of the requirement for an explicit ICV, this specification does not support authenticated encryption algorithms. Such algorithms may be added by a future extension. 🔮
4.4. Encrypted Fields 🫶
Two fields are encrypted but are not integrity protected. They're denoted Encr(...). Their format is identical to a protected field (Section 4.3), except that the Integrity Check Value is omitted.
4.5. Channel Binding Values 🦋
This protocol lets higher-level protocols send limited opaque information between the peer and the server. This information is integrity protected but not encrypted, and it may be used to make sure that protocol participants are identical at different protocol layers. See Section 7.15 of [RFC3748] for more info on the rationale behind this facility.
EAP-EKE neither validates nor makes any use of the transmitted information. The information MUST NOT be used by the consumer protocol until it is verified in the EAP-EKE-Confirm exchange (specifically, until it is integrity protected by the Auth_S, Auth_P payloads). Consequently, it MUST NOT be relied upon in case an error occurs at the EAP-EKE level. Not gonna lie, this part is serious 😤
An unknown Channel Binding Value SHOULD be ignored by the recipient.
Some implementations may require certain values to be present, and will abort the protocol if they are not. Such policy is out of scope of the current protocol.
Each Channel Binding Value is encoded using a TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBType | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: Channel Binding Value 🎀
CBType:
This is the Channel Binding Value's type. This document defines the value 0x0000 as reserved. Other values are available for IANA allocation, see Section 7.6.
Length:
This field is the total length in octets of the structure, including the CBType and Length fields.
This facility should be used with care, since EAP-EKE does not provide for message fragmentation. EAP-EKE is not a tunneled method and should not be used as a generic transport. Specifically, implementors should refrain from using the Channel Binding facility to transmit posture information, in the sense of [RFC5209]. Don't be that person 🙅♀️💅
5. Protocol Sequence ✨
This section describes the sequence of messages for the Commit and Confirm exchanges, and lists the cryptographic operations performed by the server and the peer. Let's get into it 🦋
5.1. EAP-EKE-Commit/Request 💌
okay so the server gets the first move here 💅 It picks its ephemeral private key and turns it into a public key:
y_s = g ^ x_s (mod p),where x_s is a randomly chosen number in the range 2 .. p-1. That random number is the ephemeral private key, and the value it produces is the matching ephemeral public key ✨ The server and the peer MUST both use a fresh, random value for x_s and the corresponding x_p on each run of the protocol 🎲 no reusing old randomness, bestie!!
Next, the server builds its encrypted field (Section 4.4) 🔐
temp = prf(0+, password)
key = prf+(temp, ID_S | ID_P)
DHComponent_S = Encr(key, y_s).Check Section 6.1 for the prf+ notation 🧁 The first argument to prf is a string of zero octets, and its length is the output size of the base hash algorithm (so 20 octets for HMAC-SHA1). The result comes out the same length. The first output octets of prf+ become the encryption key for the negotiated encryption algorithm, sized to that algorithm's key length 🔑
Since the PRF has to be an application of the HMAC operator to a hash function, this construction ends up implementing HKDF as defined in [RFC5869]. the way that fits together!! 🦋
When you use block ciphers, you might need to pad y_s on the right so it fits the encryption algorithm's block size 🧩 In that case random padding MUST be used, and that randomness is critical to the security of the protocol. Randomness recommendations live in [RFC4086], and [NIST.800-90.2007] has more tips on cryptographic-level randomness 🌈 When decrypting this field, the real length of y_s is worked out from the negotiated Diffie-Hellman group.
⚠️ Storing passwords on the server: if the password has to be stored there, it is RECOMMENDED to store a randomized password value as a password-equivalent, not the cleartext password. Implementations can pick the output of either of the two steps of the password derivation. Using the second step's output (where the password gets salted by the identity values) is more secure, but it can cause an operational headache if identities are likely to change. See also Section 8.5 🙈
Now the internationalization bit 🌍 This protocol supports internationalized, non-ASCII passwords. The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454], which means unassigned code points are prohibited 🚫 The output is the binary representation of the processed UTF-8 [RFC3629] character string. Any prohibited output and unassigned code points you hit during SASLprep preprocessing SHOULD cause a preprocessing failure, and the output SHOULD NOT be used. no sneaking bad code points through, periodt 💀
5.2. EAP-EKE-Commit/Response 🎀
Time for the peer to respond! 🫶 It computes its own public key:
y_p = g ^ x_p (mod p)Then it computes:
temp = prf(0+, password)
key = prf+(temp, ID_S | ID_P)
DHComponent_P = Encr(key, y_p)and formats that as an encrypted field (Section 4.4) 💖
Both sides calculate the shared secret 🤝
SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p))The first argument to prf is again a string of zero octets, its length matching the output size of the base hash algorithm (20 octets for HMAC-SHA1 again), and the result is the same length. This extra application of the pseudo-random function is the "extraction step" of [RFC5869] 🧪 Heads up: the peer has to compute the SharedSecret value before it sends out its response!! ⏰
The encryption and integrity protection keys get computed next 🗝️
Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P)And the peer generates the Protected Nonce 🪄
PNonce_P = Prot(Ke, Ki, Nonce_P),where Nonce_P is a randomly generated binary string. The length of Nonce_P MUST be the maximum of 16 octets, and half the key size of the negotiated prf (rounded up to the next octet if necessary) 📏 The peer builds this value as a protected field (Section 4.3), encrypted using Ke and integrity protected using Ki with the negotiated encryption and MAC algorithm. Lock it down!! 🔒
The peer now sends a message with those two generated fields 📨
The server MUST verify the correct integrity protection of the received nonce. If it's wrong, the server MUST abort the protocol with an "Authentication Failure" code 🚨 no vibes, no exceptions!
5.3. EAP-EKE-Confirm/Request 🌸
Server's turn again ✨ It constructs a protected field:
PNonce_PS = Prot(Ke, Ki, Nonce_P | Nonce_S),where Nonce_S is a randomly generated string, the same size as Nonce_P.
Then it computes the key for authentication:
Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P |
Nonce_S)whose length is the preferred key length of the negotiated prf (see Section 5.2) 🧠 After that, the server constructs:
Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE-
ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response).The messages are included in full, starting with the EAP header, and including any possible future extensions 📜
This construction of the Auth_S (and Auth_P) value means that any future extensions MUST NOT be added to the EAP-EKE-Confirm/Request or EAP-EKE-Confirm/Response messages themselves, unless those extensions are integrity-protected in some other manner. Future-proofing, but make it safe 🛡️
The server now sends a message with those two fields 💌
The peer MUST verify the correct integrity protection of the received nonces and the correctness of the Auth_S value. If either one is incorrect, the peer MUST abort the protocol with an "Authentication Failure" code 😤
5.4. EAP-EKE-Confirm/Response 🦄
The peer computes Ka and generates its protected field 🧁
PNonce_S = Prot(Ke, Ki, Nonce_S)Then it computes its own authentication value:
Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/
Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response)The peer sends a message with those two fields 📬
The server MUST verify the correct integrity protection of the received nonce and the correctness of the Auth_P value. If either one is incorrect, the server MUST abort the protocol with an "Authentication Failure" code 🙅♀️
5.5. MSK and EMSK 👑
Once the last message of the protocol is done, both sides compute and export the shared keys, each 64 bytes long 🎉
MSK | EMSK = prf+(SharedSecret, "EAP-EKE Exported Keys" | ID_S |
ID_P | Nonce_P | Nonce_S)When the RADIUS attributes specified in [RFC2548] are used to carry keying material, the first 32 bytes of the MSK correspond to MS-MPPE-RECV-KEY, and the second 32 bytes correspond to MS-MPPE-SEND-KEY. In that case, only 64 bytes of keying material (the MSK) are used 📡
At this point, both protocol participants MUST discard all intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke, Ki, Ka, and SharedSecret 🗑️ Similarly, both parties MUST immediately discard these values whenever the protocol terminates with a failure code or as a result of a timeout. clean up after yourselves, bestie 🧹
6. Cryptographic Details 🔐
6.1. Generating Keying Material 🗝️
Keying material is derived as the output of the negotiated pseudo-random function (prf) algorithm. Since the amount of keying material you need might be bigger than what one prf output gives you, we use the prf iteratively. The function called "prf+" outputs a pseudo-random stream based on the inputs to a prf, like this (where "|" means concatenation) 🧵
prf+ (K, S) = T1 | T2 | T3 | T4 | ...where:
T1 = prf(K, S | 0x01)
T2 = prf(K, T1 | S | 0x02)
T3 = prf(K, T2 | S | 0x03)
T4 = prf(K, T3 | S | 0x04)and so on, continuing as needed to compute all required keys. The keys are taken from the output string without regard to boundaries. For example, if the required keys are a 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC key, and the prf function generates 160 bits, the AES key comes from T1 and the beginning of T2, while the HMAC key comes from the rest of T2 and the beginning of T3 🧩
The constant concatenated to the end of each string feeding the prf is a single octet. In this document, prf+ is not defined beyond 255 times the size of the prf output 🔢
6.2. Diffie-Hellman Groups 🌈
Lots of the commonly used Diffie-Hellman groups are not suitable for EKE 🙃 Most of them use a generator that isn't a primitive element of the group. Because of that, an attacker running a dictionary attack could learn at least 1 bit of information for each decrypted password guess. yikes!! 😱
Any MODP Diffie-Hellman group defined for use in this protocol MUST have the following properties, so it doesn't leak a usable amount of information about the password ✨
- The generator is a primitive element of the group.
- The most significant 64 bits of the prime number are 1.
- The group's order p is a "safe prime", i.e., (p-1)/2 is also prime.
The last requirement is about the strength of the Diffie-Hellman algorithm, not the password encryption. It also makes it easy to verify that the generator is primitive 💅
Suitable groups are defined in Section 7.1 🎀
6.3. Mandatory Algorithms 💜
To keep things interoperable, the following algorithms are mandatory to implement 🫶
- ENCR_AES128_CBC (encryption algorithm)
- PRF_HMAC_SHA1 (pseudo-random function)
- MAC_HMAC_SHA1 (keyed message digest)
- DHGROUP_EKE_14 (DH-group)
7. IANA Considerations 🧚
IANA has allocated the EAP method type 53 from the range 1-191, for "EAP-EKE Version 1" 🦋
Per this document, IANA created the registries described in the following sub-sections. Values (other than private-use ones) can be added to these registries per Specification Required [RFC5226], with two exceptions: the Exchange and Failure Code registries can only be extended per RFC Required [RFC5226] 📋
7.1. Diffie-Hellman Group Registry 🌸
This section defines an IANA registry for Diffie-Hellman groups 💖
This table defines the initial contents of the registry. The Value column is used when negotiating the group. Additional groups may be defined through IANA allocation. Any future specification that defines a non-MODP group MUST specify its use within EAP-EKE and MUST demonstrate the group's security in this context. non-MODP groups have a whole vetting process, no shortcuts!! 🔍
+-----------------+---------+---------------------------------------+
| Name | Value | Description |
+-----------------+---------+---------------------------------------+
| Reserved | 0 | |
| DHGROUP_EKE_2 | 1 | The prime number of the 1024-bit |
| | | Group 2 [RFC5996], with the generator |
| | | 5 (decimal) |
| DHGROUP_EKE_5 | 2 | The prime number of the 1536-bit |
| | | Group 5 [RFC3526], g=31 |
| DHGROUP_EKE_14 | 3 | The prime number of the 2048-bit |
| | | Group 14 [RFC3526], g=11 |
| DHGROUP_EKE_15 | 4 | The prime number of the 3072-bit |
| | | Group 15 [RFC3526], g=5 |
| DHGROUP_EKE_16 | 5 | The prime number of the 4096-bit |
| | | Group 16 [RFC3526], g=5 |
| Available for | 6-127 | |
| allocation via | | |
| IANA | | |
| Reserved for | 128-255 | |
| Private Use | | |
+-----------------+---------+---------------------------------------+7.2. Encryption Algorithm Registry ✨
Okay bestie, now we're in the encryption algorithm registry 🔐 This is where IANA keeps the list of encryption algorithms, and it's set up like this:
+-----------------+---------+-----------------------------------+
| Name | Value | Definition |
+-----------------+---------+-----------------------------------+
| Reserved | 0 | |
| ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode |
| | 2-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-----------------+---------+-----------------------------------+7.3. Pseudo-Random Function Registry 🦋
This one is the pseudo-random function registry 💜 Here's the lineup:
+-------------------+---------+-------------------------------------+
| Name | Value | Definition |
+-------------------+---------+-------------------------------------+
| Reserved | 0 | |
| PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] |
| PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] |
| | 3-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-------------------+---------+-------------------------------------+So a pseudo-random function takes two inputs, K and S (the key and the input string, respectively). To be usable in this protocol, it has to be defined for every length of K from 0 up to 65,535 bits, inclusive. That's a lot of range, but it's the rule 🙈
Any future pseudo-random function MUST be based on the HMAC construct, since the security of HKDF is only known for such functions. Non-negotiable, no cap 🔒
7.4. Keyed Message Digest (MAC) Registry 🌸
Next up is the keyed message digest (MAC) registry, and it tracks key lengths too 🔑 Here's how it looks:
+-------------------+---------+--------------+----------------------+
| Name | Value | Key Length | Definition |
| | | (Octets) | |
+-------------------+---------+--------------+----------------------+
| Reserved | 0 | | |
| MAC_HMAC_SHA1 | 1 | 20 | HMAC SHA-1, as |
| | | | defined in [RFC2104] |
| MAC_HMAC_SHA2_256 | 2 | 32 | HMAC SHA-2-256 |
| Reserved | 3-127 | | Available for |
| | | | allocation via IANA |
| Reserved | 128-255 | | Reserved for Private |
| | | | Use |
+-------------------+---------+--------------+----------------------+7.5. Identity Type Registry 🎀
This is the identity type registry, and it's giving "who even are you" energy in the best way 🫶 Here are the types:
+-----------+---------+---------------------------------------------+
| Name | Value | Definition |
+-----------+---------+---------------------------------------------+
| Reserved | 0 | |
| ID_OPAQUE | 1 | An opaque octet string |
| ID_NAI | 2 | A Network Access Identifier, as defined in |
| | | [RFC4282] |
| ID_IPv4 | 3 | An IPv4 address, in binary format |
| ID_IPv6 | 4 | An IPv6 address, in binary format |
| ID_FQDN | 5 | A fully qualified domain name, see note |
| | | below |
| ID_DN | 6 | An LDAP Distinguished Name formatted as a |
| | | string, as defined in [RFC4514] |
| | 7-127 | Available for allocation via IANA |
| | 128-255 | Reserved for Private Use |
+-----------+---------+---------------------------------------------+An example of an ID_FQDN is example.com. The string MUST NOT contain any terminators (e.g., NULL, CR, etc.) 🚫 All characters in the ID_FQDN are ASCII. For an internationalized domain name, the syntax is as defined in [RFC5891], for example xn--tmonesimerkki-bfbb.example.net. Yes, that punycode string is giving main character energy 🌈
7.6. EAP-EKE Channel Binding Type Registry 💅
This is the Channel Binding Type registry, and it's a 16-bit long code, so think big numbers 🔢 The value 0x0000 is Reserved. Everything else up to and including 0xfeff is up for grabs from IANA. The leftover values, up to and including 0xffff, are for Private Use ✨
7.7. Exchange Registry 🧚
Now the EAP-EKE Exchange registry, which is an 8-bit long code 🍓 The initial values live in Section 4.1. Every value up to and including 0x7f is available for IANA allocation, and the rest, up to and including 0xff, is for private use 💖
7.8. Failure-Code Registry 💀
Last but not least, the Failure-Code registry, a 32-bit long code 😭 Its initial values are in Section 4.2.4. Every value up to and including 0xfeffffff is available for IANA allocation, and the remaining values, up to and including 0xffffffff, are for private use. Honestly the biggest registry in the whole doc, iconic 👑
8. Security Considerations 🔐✨
okay bestie, this part is SERIOUS 😭 any protocol that claims it solves password-authenticated key exchange must be resistant to active, passive, and dictionary attack, and it must have forward secrecy. here's what all of that means 💅
Resistance to Passive Attack: a passive attacker just relays messages back and forth between the peer and server, faithfully and without changing anything. the contents are visible to them, and that's it 👀 to resist this, the attacker must not be able to learn anything about the password or the resulting shared secret by watching repeated runs of the protocol. even if a passive attacker learns the password, she still can't figure out anything about the secret shared by the peer and server 🔒
Resistance to Active Attack: an active attacker can modify, add, delete, and replay messages between protocol participants 😤 for this protocol to resist that, the attacker must not learn anything about the password or the shared secret using any of its abilities. the attacker also must not be able to trick a protocol participant into thinking the exchange finished successfully. an active attacker can always block a message that's critical to finishing the exchange, but that's the same as dropping all messages, so it isn't an attack against the protocol 🙄
Resistance to Dictionary Attack: for this protocol to resist dictionary attacks, any advantage an adversary gains has to come from how many interactions she makes with an honest protocol participant, and not from computation 🧠 the adversary won't learn anything about the password except whether one guess from one protocol run was correct or incorrect 🎯
Forward Secrecy: compromising the password must not reveal anything about the secrets generated by earlier runs of the protocol 💜
okay so [RFC3748] says documents describing new EAP methods have to clearly spell out the method's security properties 📝 and for use with wireless LANs, [RFC4017] mandates and recommends several of these. here are the claims:
- Mechanism: password.
- Claims:
- Mutual authentication: the peer and server both authenticate each other by proving they possess a shared password. This is REQUIRED by [RFC4017].
- Forward secrecy: compromising the password does not reveal the secret keys (MSK and EMSK) from earlier runs of the protocol.
- Replay protection: an attacker can't replay messages from a previous exchange to learn the password or a key derived by the exchange. Similarly, the attacker can't make the peer or server believe the exchange has completed successfully when it hasn't 🙅♀️
- Key derivation: a shared secret is derived by performing a group operation in a finite cyclic group (e.g., exponentiation) using secret data contributed by both the peer and server. An MSK and EMSK are derived from that shared secret. This is REQUIRED by [RFC4017].
- Dictionary attack resistance: an attacker can only make one password guess per active attack, and the protocol is designed so the attacker doesn't get any confirmation of her guess by observing the decrypted y_s or y_p value (see below). the advantage she can gain comes from interaction, not computation. This is REQUIRED by [RFC4017].
- Session independence: this protocol resists active and passive attacks and doesn't let anyone compromise subsequent or prior MSKs or EMSKs, whether through passive or active attacks 🦋
- Denial-of-service resistance: it's possible for an attacker to make a server allocate state and consume CPU 😩 but that attack is gated by a requirement: the attacker first has to get connectivity through a lower-layer protocol (e.g., 802.11 authentication followed by 802.11 association, or 802.3 "link-up") and respond to two EAP messages: the EAP-ID/Request and the EAP-EKE-ID/Request.
- Man-in-the-Middle Attack resistance: this exchange resists active attack, and active attack is a requirement for launching a man-in-the-middle attack. This is REQUIRED by [RFC4017].
- Shared state equivalence: once EAP-EKE completes, the peer and server both agree on the MSK and EMSK values 🫶 the peer has authenticated the server based on the Server_ID, and the server has authenticated the peer based on the Peer_ID. That's because Peer_ID, Server_ID, and the generated shared secret all get combined into the authentication element that the peer and server must share for the exchange to complete. This is REQUIRED by [RFC4017].
- Fragmentation: this protocol doesn't define a technique for fragmentation and reassembly.
- Resistance to "Denning-Sacco" attack: learning keys distributed from an earlier run of the protocol, such as the MSK or EMSK, won't help an adversary learn the password 🔑
- Key strength: the strength of the resulting key depends on the finite cyclic group chosen. Sufficient key strength is REQUIRED by [RFC4017]. "Sufficient" strength changes over time, depending on how much computing power potential attackers are assumed to have ⏳
- Key hierarchy: MSKs and EMSKs are derived from the secret values generated during the protocol run, using a negotiated pseudo-random function 🧩
- Vulnerabilities (note that none of these are REQUIRED by [RFC4017]):
- Protected ciphersuite negotiation: the ciphersuite proposal made by the server is not protected from tampering by an active attacker. However, if an active attacker modified a proposal, the other party wouldn't be able to confirm the message, because each side binds the proposal into its Confirm message, and the protocol would fail as a result. Note that this assumes none of the proposed ciphersuites lets an attacker perform real-time cryptanalysis 🚨
- Confidentiality: none of the messages sent in this protocol are encrypted, though many of the protocol fields are 🙈
- Integrity protection: protocol messages aren't directly integrity protected. However, the ID and Commit exchanges are integrity protected through the Auth payloads exchanged in the Confirm exchange.
- Channel binding: this protocol enables the exchange of integrity-protected channel information that can be compared with values communicated via out-of-band mechanisms 📡
- Fast reconnect: this protocol doesn't provide a fast reconnect capability.
- Cryptographic binding: this protocol is not a tunneled EAP method, so it has no cryptographic information to bind.
- Identity protection: the EAP-EKE-ID exchange is not protected. An attacker will see the server's identity in the EAP-EKE-ID/Request and the peer's identity in the EAP-EKE-ID/Response. See also Section 8.4.
8.1. Cryptographic Analysis 🧪
okay so when we analyze the Commit exchange, the base security assumptions are different from "normal" cryptology. Normally, we assume the key has strong security properties and the data may have few or none. Here, we assume the key has weak security properties (the attacker may have a list of possible keys), so we need to make sure the data has strong properties (indistinguishable from random). This difference may mean conventional wisdom in cryptology doesn't apply here 🤯 it also puts severe constraints on the protocol, e.g., the mandatory use of random padding and the need to define specific finite groups.
8.2. Diffie-Hellman Group Considerations 🔢
the dictionary attack resistance is fundamentally tied to the Diffie-Hellman public values y_s and y_p being indistinguishable from a random string 💖 if that condition isn't met, a passive attacker can do trial-decryption of the encrypted DHComponent_P or DHComponent_S values based on a password guess. if they decrypt to a value that isn't a valid public value, they know the password guess was wrong ❌
for MODP groups, Section 6.2 gives conditions on the group to make sure this criterion is met. For other groups (for example, Elliptic Curve groups), some other means of ensuring it has to be used. The standard way of expressing Elliptic Curve public values doesn't meet this criterion, since a valid Elliptic Curve X coordinate can be told apart from a random string with a probability of approximately 0.5 😬
a future document might introduce a group representation, and/or a slight modification of the password encryption scheme, so Elliptic Curve groups can be accommodated 🌈 [BR02] presents several alternative solutions for this problem.
8.3. Resistance to Active Attacks 🛡️
an attacker, impersonating either the peer or the server, can always try to enumerate all possible passwords, for example with a dictionary 📖 to counter this very likely attack, both peer and server MUST implement rate-limiting mechanisms. We note that locking out the other party after a small number of tries would create a trivial denial-of-service opportunity 🚫
8.4. Identity Protection, Anonymity, and Pseudonymity 🥷
by default, the EAP-EKE-ID exchange is unprotected, so an eavesdropper can observe both parties' identities 👀 a future extension of this protocol may support anonymity, e.g., by letting the server send a temporary identity to the peer at the end of the exchange, so the peer can use that identity in later exchanges 🎭
EAP-EKE is different from tunneled methods in this respect. Tunneled methods typically give the peer unconditional identity protection by encrypting the identity exchange, but they reveal information in the server certificate. It's possible to use EAP-EKE as the inner method in a tunneled EAP method to reach this level of identity protection 💜
8.5. Password Processing and Long-Term Storage 🗄️
this document recommends that a password-equivalent (a hash of the password) be stored instead of the cleartext password. That solution gives a measure of security, but there are tradeoffs related to algorithm agility:
- Each stored password must identify the hash function that was used to compute the stored value.
- Complex deployments and migration scenarios might necessitate multiple stored passwords, one per each algorithm.
- Changing the algorithm can require, in some cases, that users manually change their passwords 😩
the reader is referred to Section 10 of [RFC3629] for security considerations related to parsing and processing UTF-8 strings 🫧
9. Acknowledgements ✨
Okay bestie, so a LOT of this doc was straight up borrowed from [RFC5931] and [EAP-SRP] 🫶 We have to thank the authors of those: Dan Harkins, Glen Zorn, James Carlson, Bernard Aboba, and Henry Haverinen. 💖
Huge thanks also to David Jacobson, Steve Bellovin, Russ Housley, Brian Weis, Dan Harkins, and Alexey Melnikov for their super useful comments. 🙌
And Lidar Herooty and Idan Ofrat actually implemented this protocol 🔥 They helped make it better by asking the right questions, so we love them both. 💅
10. References 📚
10.1. Normative References 💜
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication",
RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
Attributes", RFC 2548, March 1999.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")",
RFC 3454, December 2002.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular
Exponential (MODP) Diffie-Hellman groups for
Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[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.
[RFC4514] Zeilenga, K., "Lightweight Directory Access
Protocol (LDAP): String Representation of
Distinguished Names", RFC 4514, June 2006.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
August 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 5996, September 2010.
[SHA] National Institute of Standards and Technology,
U.S. Department of Commerce, "Secure Hash
Standard", NIST FIPS 180-3, October 2008.10.2. Informative References 🌸
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key
Exchange: Password-Based Protocols Secure Against
Dictionary Attacks", Proc. IEEE Symp. on Research
in Security and Privacy , May 1992.
[BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted
Key Exchange: A Password-Based Protocol Secure
against Dictionary Attacks and Password File
Compromise", Proc. 1st ACM Conference on Computer
and Communication Security , 1993.
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably
Secure Password Authenticated Key Exchange Using
Diffie-Hellman", Advances in Cryptology,
EUROCRYPT 2000 , 2000.
[BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary
Finite Domains", Proc. of the RSA Cryptographer's
Track (RSA CT '02), LNCS 2271 , 2002.
[EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP
SRP-SHA1 Authentication Protocol", Work
in Progress, July 2001.
[JAB96] Jablon, D., "Strong Password-Only Authenticated
Key Exchange", ACM Computer Communications
Review Volume 1, Issue 5, October 1996.
[LUC97] Lucks, S., "Open Key Exchange: How to Defeat
Dictionary Attacks Without Encrypting Public
Keys", Proc. of the Security Protocols
Workshop LNCS 1361, 1997.
[NIST.800-90.2007] National Institute of Standards and Technology,
"Recommendation for Random Number Generation
Using Deterministic Random Bit Generators
(Revised)", NIST SP 800-90, March 2007.
[PA97] Patel, S., "Number Theoretic Attacks On Secure
Password Schemes", Proceedings of the 1997 IEEE
Symposium on Security and Privacy , 1997.
[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.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan,
K., and J. Tardo, "Network Endpoint Assessment
(NEA): Overview and Requirements", RFC 5209,
June 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-
and-Expand Key Derivation Function (HKDF)",
RFC 5869, May 2010.
[RFC5931] Harkins, D. and G. Zorn, "Extensible
Authentication Protocol (EAP) Authentication
Using Only a Password", RFC 5931, August 2010.Authors' Addresses 💌
Yaron Sheffer
Independent
EMail: yaronf.ietf@gmail.com
Glen Zorn
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 87-040-4617
EMail: gwz@net-zen.net
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Scott Fluhrer
Cisco Systems.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
EMail: sfluhrer@cisco.com📦 where this page comes from
- ietf: rfc6124 2011-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms