RFC 4746
Extensible Authentication Protocol (EAP) Password Authenticated Exchange
RFC 4746: Extensible Authentication Protocol (EAP) Password Authenticated Exchange 💖
okay bestie, let's start with the title block 🎀 This is RFC 4746, and it's all about a whole EAP method called EAP-PAX. It was written by T. Clancy (LTS) and W. Arbaugh (UMD), dated November 2006. It's Informational, so it shares info for the Internet community and doesn't set an Internet standard 💅 The header doesn't list anything it obsoletes or updates, so it's standing on its own 🦋
Status of This Memo ✨
This memo is here to provide information for the Internet community. It is not an Internet standard of any kind, and anyone can distribute it freely 🌸
Copyright Notice 🌈
Copyright (C) The IETF Trust (2006).
Copyright Notice 🌈
Copyright (C) The Internet Society (2006).
Abstract 💜
This doc defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). It's a lightweight shared-key authentication protocol, with optional support for key provisioning, key management, identity protection, and authenticated data exchange 🧚
Table of Contents 📖
1. Introduction ....................................................2
1.1. Language Requirements ......................................3
1.2. Terminology ................................................3
2. Overview ........................................................5
2.1. PAX_STD Protocol ...........................................6
2.2. PAX_SEC Protocol ...........................................7
2.3. Authenticated Data Exchange ................................9
2.4. Key Derivation ............................................10
2.5. Verification Requirements .................................11
2.6. PAX Key Derivation Function ...............................12
3. Protocol Specification .........................................13
3.1. Header Specification ......................................13
3.1.1. Op-Code ............................................13
3.1.2. Flags ..............................................14
3.1.3. MAC ID .............................................14
3.1.4. DH Group ID ........................................14
3.1.5. Public Key ID ......................................15
3.1.6. Mandatory to Implement .............................15
3.2. Payload Formatting ........................................16
3.3. Authenticated Data Exchange (ADE) .........................18
3.4. Integrity Check Value (ICV) ...............................19
4. Security Considerations ........................................19
4.1. Server Certificates .......................................20
4.2. Server Security ...........................................20
4.3. EAP Security Claims .......................................21
4.3.1. Protected Ciphersuite Negotiation ..................21
4.3.2. Mutual Authentication ..............................21
4.3.3. Integrity Protection ...............................21
4.3.4. Replay Protection ..................................21
4.3.5. Confidentiality ....................................21
4.3.6. Key Derivation .....................................21
4.3.7. Key Strength .......................................22
4.3.8. Dictionary Attack Resistance .......................22
4.3.9. Fast Reconnect .....................................22
4.3.10. Session Independence ..............................22
4.3.11. Fragmentation .....................................23
4.3.12. Channel Binding ...................................23
4.3.13. Cryptographic Binding .............................23
4.3.14. Negotiation Attack Prevention .....................23
5. IANA Considerations ............................................23
6. Acknowledgments ................................................24
7. References .....................................................24
7.1. Normative References ......................................24
7.2. Informative References ....................................25
Appendix A. Key Generation from Passwords ........................ 27
Appendix B. Implementation Suggestions ........................... 27
B.1. WiFi Enterprise Network ................................... 27
B.2. Mobile Phone Network ...................................... 281. Introduction ✨
EAP-PAX (Password Authenticated eXchange) is an Extensible Authentication Protocol (EAP) method [RFC3748] made for authentication with a shared key 🔑 It has two separate subprotocols, PAX_STD and PAX_SEC. PAX_STD is simple and lightweight, does mutual authentication with a shared key, and supports Authenticated Data Exchange (ADE) 💖 PAX_SEC complements it by adding shared-key provisioning and identity protection, using a server-side public key 🦋
The big idea behind EAP-PAX is device authentication that's bootstrapped by a simple Personal Identification Number (PIN) 🎀 If a weak key is used, or an expiration period has elapsed, the authentication server forces a key update. Instead of a symmetric key exchange, the client and server do a Diffie-Hellman key exchange, which gives forward secrecy. Iconic behaviour 👑
Setting up a Public Key Infrastructure (PKI) can be a total hassle, so PAX_SEC has multiple client security policies you can pick based on your threat model 💅 In the weakest mode, PAX_SEC lets you use raw public keys, so there's no PKI needed at all 🌸 In the strongest mode, EAP servers have to use certificates signed by a trusted Certification Authority (CA). In the weaker modes, PAX_SEC is vulnerable to a man-in-the-middle dictionary attack during provisioning 💀 In the strongest mode, EAP-PAX is provably secure under the Random Oracle model 🔥
EAP-PAX supports generation of strong key material, mutual authentication, and resistance to desynchronization, dictionary, and man-in-the-middle attacks. It also has ciphersuite extensibility with protected negotiation, identity protection, and authenticated exchange of data, which is useful for channel binding ✨ These features cover the EAP method requirements for wireless LANs [RFC4017], which makes EAP-PAX a great fit for wireless environments like IEEE 802.11 [IEEE.80211] 📶
1.1. Language Requirements 🧚
In this document, a few words are used to signal the requirements of the spec. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] 📜
1.2. Terminology 📚
This section breaks down the variables and functions used in the EAP-PAX protocol. They come up a lot in later sections, so bookmark this one 🔖
Variables:
CID: user-supplied client ID, specified as a Network Access Identifier (NAI) [RFC4282], restricted to 65535 octetsg: public Diffie-Hellman generator, typically the integer 2 [RFC2631]M: 128-bit random integer generated by the serverN: 128-bit random integer generated by the clientX: 256-bit random integer generated by the serverY: 256-bit random integer generated by the client
Keys:
AK: authentication key shared between the client and EAP serverAK': new authentication key generated during a key updateCertPK: EAP server's certificate containing public keyPKCK: Confirmation Key generated from theMKand used during authentication to prove knowledge ofAKEMSK: Extended Master Session Key, also generated from theMK, containing additional keying materialIV: Initialization Vector used to seed ciphers, exported to the authenticatorMID: Method ID used to construct the EAP Session ID, which in turn names all the exported keys [IETF.KEY]MK: Master Key between the client and EAP server, from which all other EAP method session keys are derivedMSK: Master Session Key generated from theMKand exported by the EAP method to the authenticatorPK: EAP server's public key
Operations:
enc_X(Y): encryption of messageYwith public keyXMAC_X(Y): keyed message authentication code computed over messageYwith symmetric keyXPAX-KDF-W(X, Y, Z): PAX Key Derivation Function, computed using secretX, identifierY, and seedZ, producingWoctets of output||: string or binary data concatenation
2.1. PAX_STD Protocol 🔐
okay so PAX_STD is the simple one 💖 It's a nonce-based authentication that uses the strong long-term key. The client and server each send 256 bits of random data, and that randomness seeds the PAX-KDF to make the session keys 🔑 The random stuff changes depending on whether a key update is happening. If there's no key update, then:
A = XB = YE = X || Y
So A and B are 256-bit values, and E is their 512-bit concatenation ✨ But if a key update is happening, it gets extra secure (forward secrecy, obsessed 😭). Then it's:
A = g^XB = g^YE = g^(XY)
Here A and B are Diffie-Hellman exponents, and their length depends on the Diffie-Hellman group size 🧮 A goes from the server to the client, and B goes from the client to the server. E is the entropy each side computes, and it's used in Section 2.4 for key derivation 🌸
The whole protocol goes like this 🦋
PAX_STD-1 : client <- server : A
PAX_STD-2 : client -> server : B, CID, MAC_CK(A, B, CID),
[optional ADE]
PAX_STD-3 : client <- server : MAC_CK(B, CID), [optional ADE]
PAX-ACK : client -> server : [optional ADE]For the ADE bit, check Section 2.3, and for the key derivation (including how CK gets made), check Section 2.4 🧚
2.2. PAX_SEC Protocol 👑
PAX_SEC is the high-security one, and it's giving identity protection plus support for provisioning 🛡️ It needs a server-side public key, and it does public-key operations for every single authentication. Main character energy, honestly 💅
PAX_SEC can run with or without a key update. A, B, and E are defined the same way as in the previous section 🎀
Here's how the exchanges go:
PAX_SEC-1 : client <- server : M, PK or CertPK
PAX_SEC-2 : client -> server : Enc_PK(M, N, CID)
PAX_SEC-3 : client <- server : A, MAC_N(A, CID)
PAX_SEC-4 : client -> server : B, MAC_CK(A, B, CID), [optional
ADE]
PAX_SEC-5 : client <- server : MAC_CK(B, CID), [optional ADE]
PAX-ACK : client -> server : [optional ADE]Again, Section 2.3 has the ADE details and Section 2.4 has the key derivation, including CK 🫶
Using CertPK is optional in PAX_SEC, but ngl, you should think really carefully before skipping it 🙈 Here's the risk breakdown for going certificate-free:
Certificate | Provisioning | Identity
Mode | | Protection
==================+=====================+======================
No Certificate | MiTM offline | ID reveal attack
| dictionary attack |
------------------+---------------------+---------------------
Self-Signed | MiTM offline | ID reveal attack
Certificate | dictionary attack |
------------------+---------------------+---------------------
Certificate/PK | MiTM offline | ID reveal attack
Caching | dictionary attack | during first auth
------------------+---------------------+---------------------
CA-Signed | secure mutual | secure mutual
Certificate | authentication | authentication
Figure 2: Table of Different Security Modes💀 Yikes, the no-certificate and self-signed rows both leave you open to a MiTM offline dictionary attack during provisioning, and the ID reveal attack is right there too. Be careful, bestie.
If you're provisioning with a weak key, a CA-signed certificate is RECOMMENDED 📜 If you aren't using one, the initial authentication is open to an offline man-in-the-middle (MiTM) dictionary attack, which is not it 😤
If you're using PAX_SEC for identity protection, then either a CA-signed certificate or key caching is RECOMMENDED ✨ Caching means the client records the EAP server's public key and checks that it stays consistent between sessions. It's kind of like Secure SHell (SSH) Protocol [RFC4252] 🔒 Without it, an attacker can spoof an EAP server mid-session and learn a client's identity. Not cute 💀
Whenever certificates are used, clients MUST validate that the certificate's extended key usage, KeyPurposeID, is either "eapOverPPP" or "eapOverLAN" [RFC3280][RFC4334]. If the underlying EAP transport protocol is known, then the client MUST differentiate between these values 🎯 For example, an IEEE 802.11 supplicant SHOULD require KeyPurposeID == eapOverLAN. If you don't tell them apart, a client could accept an unauthorized server certificate, and that is a whole disaster 😭
When you're using EAP-PAX with Wireless LAN, clients SHOULD validate that the certificate's wlanSSID extension matches the SSID of the network they're authenticating to right now 📶
To make packet validation easier to talk about, three client security policies for PAX_SEC are defined 🧁
open: Clients support both PK and CertPK. If CertPK is used, the client MUST validate the KeyPurposeID.caching: Clients save PK for each EAP server the first time they meet it, and they SHOULD NOT authenticate to EAP servers whose public key has changed. If CertPK is used, the client MUST validate the KeyPurposeID.strict: In strict mode, clients require servers to present a valid certificate signed by a trusted CA. Like the other modes, the KeyPurposeID MUST be validated.
Servers SHOULD support the PAX_SEC mode of operation, and they SHOULD support both PK and CertPK with PAX_SEC 🌈 Clients MUST support PAX_SEC, and MUST be capable of accepting both raw public keys and certificates from the server. Local security policy decides which forms of key or certificate authentication are allowed 🔐 Default configurations SHOULD require at least the caching security policy, and MAY require strict.
EAP-PAX handles key management on the AK through AK', but managing the server public key is out of scope for this document 🙃 If you're using self-signed certificates, deployers should be aware that expired certificates may be hard to replace when caching mode is in use 🥲
For more on security considerations, see Section 4 🖤
2.3. Authenticated Data Exchange 🦋
Messages PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK all carry the optional ADE component ✨ It's there so the client and server can pass authenticated data back and forth during the authentication.
The Authenticated Data Exchanged (ADE) can do all sorts of things, including channel bindings 🧩 Channel bindings let the EAP client and server securely check link-layer network properties while the authentication session is happening.
Here's the catch: ADE is not encrypted, so anything in it is not confidential 🙈 BUT since all these packets are protected by the Integrity Check Value (ICV), authenticity is guaranteed ✅
The ADE element is made of an arbitrary number of subelements, and each one has a length and a type. If the subelements are too many or too big, packet fragmentation will be needed 📦 Vendor-specific options are supported too. See Section 3.3 🌸
Heads up, more than 1.5 round-trips might be needed to run a particular authenticated protocol inside EAP-PAX 🎢 In that case, instead of sending an EAP-Success after the PAX_ACK, the server can keep sending PAX_ACK messages with attached elements. The client answers each of those with PAX_ACK messages that might carry more ADE elements. It goes something like this:
+--------+ +--------+
| | PAX_STD-1 | |
| |<------------------------------------| |
| | PAX_STD-2(ADE[1]) | |
| |------------------------------------>| |
| | PAX_STD-3(ADE[2]) | |
| |<------------------------------------| |
| | PAX_ACK(ADE[3]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[4]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | PAX_ACK(ADE[i]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[i+1]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 3: Extended Diagram of EAP-PAX Packet Exchanges2.4. Key Derivation 🗝️
Keys are derived no matter which authentication mechanism was used 💜 The process uses the entropy value E we computed above. Session and authentication keys come out like this:
AK' = PAX-KDF-16(AK, "Authentication Key", E)
MK = PAX-KDF-16(AK, "Master Key", E)
CK = PAX-KDF-16(MK, "Confirmation Key", E)
ICK = PAX-KDF-16(MK, "Integrity Check Key", E)
MID = PAX-KDF-16(MK, "Method ID", E)
MSK = PAX-KDF-64(MK, "Master Session Key", E)
EMSK = PAX-KDF-64(MK, "Extended Master Session Key", E)
IV = PAX-KDF-64(0x00^16, "Initialization Vector", E)The IV gets computed using a 16-octet NULL key 🫧 AK' only replaces AK if a key update is happening. The EAP Method ID is written in ASCII as 32 hexadecimal characters, with no octet delimiters like colons or dashes 🔢
The EAP Key Management Framework [IETF.KEY] recommends specifying key names and scope 🏷️ The EAP-PAX Method-ID is the MID value we just computed. The EAP peer name is the CID value exchanged in PAX_STD-2 and PAX_SEC-2. The EAP server name is an empty string ✨
2.5. Verification Requirements 🔐
Okay so, for EAP-PAX to be secure, MACs need to be properly verified every single step of the way 💅. Any packet with an ICV (see Section 3.4) that fails validation must be silently discarded. After ICV validation, these checks must be performed:
PAX_STD-2: The server MUST validate the included MAC, because it's what authenticates the client to the server 🫶. If that validation fails, the server MUST send an EAP-Failure message.PAX_STD-3: The client MUST validate the included MAC, because it's what authenticates the server to the client ✨. If that validation fails, the client MUST send an EAP-Failure message.PAX_SEC-1: The client MUST validate PK or CertPK in whatever way its local security policy specifies (see Section 2.2). If this validation fails, the client MUST send an EAP-Failure message.PAX_SEC-2: The server MUST verify that the decrypted value of M matches the value transmitted inPAX_SEC-1🔍. If this validation fails, the server MUST send an EAP-Failure message.PAX_SEC-3: The client MUST validate the included MAC, because it's how replay attacks get prevented 🙈. If this validation fails, the client MUST send an EAP-Failure message.PAX_SEC-4: The server MUST validate the included MAC, because it authenticates the client to the server 💜. If this validation fails, the server MUST send an EAP-Failure message.PAX_SEC-5: The client MUST validate the included MAC, because it authenticates the server to the client 🌸. If this validation fails, the client MUST send an EAP-Failure message.PAX-ACK: If a PAX-ACK comes back in response to a message fragment, the receiver keeps the protocol going 🦋. If a PAX-ACK comes back in response toPAX_STD-3orPAX_SEC-5, then the server MUST send an EAP-Success message. That's the sign that PAX ran successfully 👑.
2.6. PAX Key Derivation Function 🧚
The PAX-KDF is a secure key derivation function, and its whole job is to generate various keys from the provided entropy and shared key 🔑.
PAX-KDF-W(X, Y, Z)
W length, in octets, of the desired output
X secret key used to protect the computation
Y public identifier for the key being derived
Z exchanged entropy used to seed the KDFLet's define some variables and functions:
M_i = MAC_X(Y || Z || i), where i is an 8-bit unsigned integerL = ceiling(W/16)F(A, B) = first A octets of binary data B
We define PAX-KDF-W(X, Y, Z) = F(W, M_1 || M_2 || ... || M_L).
So for the two values of W used in this document, we get:
PAX-KDF-16(X, Y, Z) = MAC_X(Y || Z || 0x01)PAX-KDF-64(X, Y, Z) = MAC_X(Y || Z || 0x01) || MAC_X(Y || Z || 0x02) || MAC_X(Y || Z || 0x03) || MAC_X(Y || Z || 0x04)
The MAC used in the PRF is extensible, and it's the same MAC used in the rest of the protocol 🌈. It's specified in the EAP-PAX header.
3. Protocol Specification 🎀
In this section, we define the packet format and content for the EAP-PAX messages 📦.
EAP-PAX packets have the following structure:
--- bit offset --->
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 | OP-Code | Flags | MAC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH Group ID | Public Key ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ICV ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP-PAX Packet Structure3.1. Header Specification 📋
The Code, Identifier, Length, and Type fields are all part of the EAP header, and they're defined in [RFC3748]. IANA has allocated EAP Method Type 46 for EAP-PAX, so the Type field in the EAP header MUST be 46 💖.
3.1.1. Op-Code 🎯
The OP-Code field is one of the following values:
0x01:PAX_STD-10x02:PAX_STD-20x03:PAX_STD-30x11:PAX_SEC-10x12:PAX_SEC-20x13:PAX_SEC-30x14:PAX_SEC-40x15:PAX_SEC-50x21:PAX-ACK
3.1.2. Flags 🚩
The flags field is broken up into 8 bits, and each bit represents a binary flag. The field is defined as the Logical OR of the following values:
0x01: more fragments (MF)0x02: certificate enabled (CE)0x04: ADE Included (AI)0x08 - 0x80: reserved
The MF flag is set if the current packet required fragmentation and further fragments still need to be transmitted 🧩. If a packet doesn't require fragmentation, the MF flag is not set.
When a payload requires fragmentation, each fragment is transmitted, and the receiving party responds with a PAX-ACK packet for each received fragment 🫧.
When using PAX_STD, the CE flag MUST be zero. When using PAX_SEC, the CE flag MUST be set if PAX_SEC-1 includes CertPK. It MUST NOT be set if PAX_SEC-1 includes PK. If CE is set in PAX_SEC-1, it MUST be set in PAX_SEC-2, PAX_SEC-3, PAX_SEC-4, and PAX_SEC-5. If either party detects an inconsistent value of the CE flag, they MUST send an EAP-Failure message and discontinue the session 🚫.
The AI flag indicates the presence of an ADE element 🍓. AI MUST only be set on packets PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK if an ADE element is included. On packets of other types, ADE elements MUST be silently discarded, because they can't be authenticated 🙅♀️.
3.1.3. MAC ID 🔏
The MAC field specifies the cryptographic hash used to generate the keyed hash value. The following are currently supported:
0x01: HMAC_SHA1_128 [FIPS198] [FIPS180]0x02: HMAC_SHA256_128 [FIPS180]
3.1.4. DH Group ID 🤝
The Diffie-Hellman group field specifies the group used in the Diffie-Hellman computations. The following are currently supported:
0x00: NONE (iff not performing a key update)0x01: 2048-bit MODP Group (IANA DH Group 14) [RFC3526]0x02: 3072-bit MODP Group (IANA DH Group 15) [RFC3526]0x03: NIST ECC Group P-256 [FIPS186]
If no key update is being performed, the DH Group ID field MUST be zero. Otherwise, the DH Group ID field MUST NOT be zero 🌙.
3.1.5. Public Key ID 🗝️
The Public Key ID field specifies the cipher used to encrypt the client's EAP-Response in PAX_SEC-2. The following are currently supported:
0x00: NONE (if using PAX_STD)0x01: RSAES-OAEP [RFC3447]0x02: RSA-PKCS1-V1_5 [RFC3447]0x03: El-Gamal Over NIST ECC Group P-256 [FIPS186]
If PAX_STD is being executed, the Public Key ID field MUST be zero. If PAX_SEC is being executed, the Public Key ID field MUST NOT be zero 💫.
When using RSAES-OAEP, the hash algorithm and mask generation algorithm used SHALL be the MAC specified by the MAC ID, keyed using an all-zero key. The label SHALL be null.
The RSA-based schemes specified here don't dictate the length of the public keys. DER encoding rules specify the key size in the key or certificate [X.690]. Key sizes SHOULD be used that reflect the desired level of security 🔐.
3.1.6. Mandatory to Implement 💪
The following ciphersuite is mandatory to implement, and it achieves roughly 112 bits of security:
- HMAC_SHA1_128
- IANA DH Group 14 (2048 bits)
- RSA-PKCS1-V1_5 (RECOMMEND 2048-bit public key)
The following ciphersuite is RECOMMENDED, and it achieves 128 bits of security 👑:
- HMAC_SHA256_128
- IANA DH Group 15 (3072 bits)
- RSAES-OAEP (RECOMMEND 3072-bit public key)
3.2. Payload Formatting 🎀
okay so this section is about how to pack up the payload field 📦 Depending on the packet type, different values get sent, and Sections 2.1 and 2.2 tell you which fields exist and what order to glue them together in. To keep things simple (bc so many field lengths change with the ciphersuite), every value gets a 2-octet length in front of it, encoded as an integer like we'll see below. That length field MUST equal the length in octets of the value that follows it. 💖
--- octet offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---------------------
|len| value ....
+---+--------Figure 5: Length Encoding for Data Elements
All integers are stored as octet arrays in network-byte order, so the most significant octet goes first. Integers get padded on the most significant end until they hit an octet boundary. ✨
Public keys and certificates SHALL be in X.509 format [RFC3280] encoded using the Distinguished Encoding Rules (DER) format [X.690]. 🔐
Strings are not null-terminated and are encoded using UTF-8. Binary data, like message authentication codes, gets transmitted as-is 🦋
MACs are computed by concatenating the specified values in the specified order. Here's the tea ☕: for MACs, the length fields are NOT included, but the resulting MAC will have its own length field. The values are encoded as described above, just without a length field on them. 🙈
Okay now the example! 🧚 This shows the encoding of the payload for PAX_STD-2. There are three basic steps: computing the MAC, forming the payload, and encrypting the payload. ✨
To make the MAC, we first have to build the buffer that's getting MACed. For this example, assume no key update is happening and HMAC_SHA1_128 is used, so the result is a 16-octet value. 🌸
--- octet offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... variable length CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||
||
CK --> MAC
||
\/
--- octet offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-octet MAC output |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Example Encoding of PAX_STD-2 MAC Data
Now we can make the encoded payload 💅
--- octet offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|32 | 32-octet integer B
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L | |
+-+-+-+-+ +
| |
... L-octet CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|16 | MAC computed above |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Example Encoding of PAX_STD-2 Packet
These 52+L octets then get attached to the packet as the payload 🍓 The ICV is computed by MACing the packet headers and payload, and then it gets appended after the payload (see Section 3.4). 🫶
3.3. Authenticated Data Exchange (ADE) 🌈
This section is about formatting ADE elements. ADE elements can ONLY show up on packets of type PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK. Values included in other packets MUST be silently ignored. 🙅♀️
The ADE element is preceded by its 2-octet length L. Each subelement has a 2-octet length Li first, then a 2-octet type Ti. The whole ADE element looks like this 👑
--- octet offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L |L1 |T1 | |
+-+-+-+-+-+-+ +
| |
... subADE-1, type T1, length L1 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |L2 |T2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... subADE-2, type T2, length L2 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | more subADE elements... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: Encoding of ADE Components
These are the type values that have been allocated 🎯
0x01 : Vendor Specific0x02 : Client Channel Binding Data0x03 : Server Channel Binding Data
A subADE using type code 0x01 must have its first three octets be the vendor's Enterprise Number [RFC3232] as registered with IANA. The format for that kind of subADE goes like this 🏢
--- octet offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Li | 1 | ENi | |
+-+-+-+-+-+-+-+ +
| |
... subADE-i, type Vendor Specific, length Li, vendor ENi ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: Encoding of Vendor-specific ADE
Channel binding subADEs haven't been defined yet 🔮 Future IETF documents will specify the format for these subADE fields. ✨
3.4. Integrity Check Value (ICV) 🔒
The ICV is computed as the MAC over the entire EAP packet, which includes the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC is keyed using the 16-octet ICK, using the MAC type specified by the MAC ID in the EAP-PAX header. For packets of type PAX_STD-1, PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3, where the MK has not yet been derived, the MAC is keyed using a zero-octet NULL key. 🫧
If the ICV field is incorrect, the receiver MUST silently discard the packet. 🗑️
4. Security Considerations 🚨
Any authentication protocol, especially one built for wireless environments, has to assume that adversaries have LOTS of capabilities 😭 In general, you have to assume that every message between the client and server gets delivered via the adversary. That lets passive attackers eavesdrop on all the traffic, while active attackers can modify data in any way before it's delivered. 👀
In this section we talk through the security properties and requirements of EAP-PAX against that threat model. Also, the security of PAX can be proved using under the Random Oracle model. 🧠
4.1. Server Certificates 🎀
PAX_SEC can be used in several configurations. It can be used with or without a server-side certificate. Section 2.2 details the possible modes and the resulting security risk. 💅
When using PAX_SEC for identity protection and NOT using a CA-signed certificate, an attacker can convince a client to reveal his username. To pull this off, an attacker can just forge a PAX_SEC-1 message and send it to the client. The client would respond with a PAX_SEC-2 message containing his encrypted username. The attacker can then use his associated private key to decrypt the client's username 💀 Using key caching can reduce the risk of identity revelation, because it lets clients detect when the EAP server they're accustom to has a different public key.
When provisioning with PAX_SEC and NOT using a CA-signed certificate, an attacker could first forge a PAX_SEC-1 message and send it to the client. The client would respond with a PAX_SEC-2 message. Using the decrypted value of N, an attacker could forge a PAX_SEC-3 message. Once the client responds with a PAX_SEC-4 message, an attacker can guess values of the weak AK and compute CK = PAX-KDF(AK, "Confirmation Key", g^XY). Given enough time, the attacker can obtain both the old AK and new AK' and forge a responding PAX_SEC-5. 😱
4.2. Server Security 🏰
To keep a reasonable security policy, the server should manage five pieces of information about each user, most obviously the username and current key. In addition, the server must keep a bit that indicates whether the current key is weak. Weak keys must be updated prior to key derivation. Also, the server should track the date of the last key update. To implement the coarse-grained forward secrecy, the authentication key must be updated on a regular basis, and this field can be used to expire keys. Last, the server should track the previous key, to prevent attacks where an adversary desynchronizes the key state by interfering with PAX-ACK packets. See Appendix B for more suggested implementation strategies that prevent key desynchronization attacks. 🔑
Since the client keys are stored in plaintext on the server, special care should be given to the overall security of the authentication server. An operating system-level attack that yields root access to an intruder would result in the compromise of ALL client credentials. 🚨🚨
4.3. EAP Security Claims 📜
This section describes EAP-PAX in terms of specific security terminology, as required by [RFC3748]. 🦋
4.3.1. Protected Ciphersuite Negotiation 🛡️
In the initial packet from the server, the server specifies the ciphersuite in the packet header. The server is in total control of the ciphersuite, so a client that doesn't support the specified ciphersuite won't be able to authenticate. On top of that, each client's local security policy should specify the secure ciphersuites the client will accept. The ciphersuite specified in PAX_STD-1 and PAX_SEC-1 MUST remain the same in successive packets within the same authentication session. Since later packets are covered by an ICV keyed with the ICK, the server can verify that the originally transmitted ciphersuite was not altered by an adversary. 🔍
4.3.2. Mutual Authentication 🤝
Both PAX_STD and PAX_SEC authenticate the client and the server, and consequently achieve explicit mutual authentication. 💜
4.3.3. Integrity Protection 🛡️
okay so the ICV from Section 3.4 gives you integrity protection 🔒 once the integrity check key has been derived. The header values in the unprotected packets can be verified when an ICV shows up later in the session. no cap, that's the whole glow-up 💖
4.3.4. Replay Protection 🔁
EAP-PAX is inherently designed to avoid replay attacks ✨ by cryptographically binding each packet to the previous one. Also, the EAP sequence number is covered by the ICV, which adds extra strength against replay attacks. double layer of protection, bestie 🫶
4.3.5. Confidentiality 🤫
With identity protection enabled, PAX_SEC provides full confidentiality. literally the vault 🔐
4.3.6. Key Derivation 🗝️
Session keys are derived using the PAX-KDF and fresh entropy supplied by both the client and the server. Since the key hierarchy is derived from the shared password, only someone who knows that password (or can guess it) is able to derive the session keys. one of the best parts of PAX_SEC is that it lets you bootstrap a strong shared secret from a weak password while preventing offline dictionary attacks 💅
4.3.7. Key Strength 💪
Authentication keys are 128 bits. The key generation is protected by a Diffie-Hellman key exchange. It is believed that a 3000-bit MODP public-key scheme is roughly equivalent [RFC3766] to a 128-bit symmetric-key scheme. Consequently, EAP-PAX requires the use of a Diffie-Hellman group with modulus larger than 3000. Also, the exponent used as the private DH parameter must be at least twice as large as the key eventually generated. Consequently, EAP-PAX uses 256-bit DH exponents. Thus, the authentication keys contain the full 128 bits of security. 🔥
Future ciphersuites defined for EAP-PAX MUST contain a minimum of 128 bits of security. strong rule, no exceptions 👑
4.3.8. Dictionary Attack Resistance 🙅♀️
EAP-PAX is resistant to dictionary attacks, except for the case where a weak password is initially used and the server is not using a certificate for authentication. See Section 4.1 for more information on resistance to dictionary attacks. so the cert is kinda the main character here 🎀
4.3.9. Fast Reconnect ⚡
Although a specific fast reconnection option is not included, execution of PAX_STD requires very little computation time and is therefore bound primarily by the latency of the Authentication, Authorization, and Accounting (AAA) server. the AAA server is the real bottleneck, not the crypto 🙈
4.3.10. Session Independence 🦋
This protocol easily achieves backward secrecy through, among other things, use of the PAX-KDF. Given a current session key, attackers can discover neither the entropy used to generate it nor the key used to encrypt that entropy as it was transmitted across the network. so nothing leaks backwards ✨
This protocol has coarse-grained forward secrecy. Compromised session keys are only useful on data for that session, and one cannot derive AK from them. If an attacker can discover AK, that value can only be used to compromise session keys derived using that AK. Reasonably frequent password updates will help mitigate such attacks. 🔄
Session keys are independently generated using fresh nonces for each session, and therefore the sessions are independent. every session gets its own fresh start 🌸
4.3.11. Fragmentation 🧩
Fragmentation and reassembly is supported through the fragmentation flag in the header. 📦
4.3.12. Channel Binding 🔗
EAP-PAX can be extended to support channel bindings through the use of its subADE fields. ✨
4.3.13. Cryptographic Binding 🚫
EAP-PAX does not include any cryptographic binding. This is relevant only for tunneled methods. so not the move for tunnels, babe 🙅♀️
4.3.14. Negotiation Attack Prevention 🕵️♀️
EAP is susceptible to an attack where an attacker uses NAKs to convince an EAP client and server to use a less secure method. This can be prevented using method-specific integrity protection on NAK messages. Since EAP-PAX does not have suitable keys derived for this integrity protection at the beginning of a PAX conversation, this is not included. the attacker really tried to downgrade us 💀
5. IANA Considerations 📋
This document requires IANA to maintain the namespace for the following header fields: MAC ID, DH Group ID, Public Key ID, and ADE type. The initial namespace populations are as follows.
MAC ID Namespace:
o 0x01 : HMAC_SHA1_128
o 0x02 : HMAC_SHA256_128
DH Group ID Namespace:
o 0x00 : NONE
o 0x01 : IANA DH Group 14
o 0x02 : IANA DH Group 15
o 0x03 : NIST ECC Group P-256
Public Key ID Namespace:
o 0x00 : NONE
o 0x01 : RSAES-OAEP
o 0x02 : RSA-PKCS1-V1_5
o 0x03 : El-Gamal Over NIST ECC Group P-256
ADE Type Namespace:
o 0x01 : Vendor Specific
o 0x02 : Client Channel Binding Data
o 0x03 : Server Channel Binding DataAllocation of values for these namespaces shall be reviewed by a Designated Expert appointed by the IESG. The Designated Expert will post a request to the EAP WG mailing list (or a successor designated by the Designated Expert) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable. 🧐
6. Acknowledgments 💜
The authors would like to thank Jonathan Katz for discussion with respect to provable security, Bernard Aboba for technical guidance, Jari Arkko for his expert review, and Florent Bersani for feedback and suggestions. Finally, the authors would like to thank the Defense Information Systems Agency for initially funding this work. big thank-yous all around 🫶🌈
7. References 📚
7.1. Normative References
- [FIPS180] National Institute for Standards and Technology, "Secure Hash Standard", Federal Information Processing Standard 180-2, August 2002.
- [FIPS186] National Institute for Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standard 186, May 1994.
- [FIPS198] National Institute for Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", Federal Information Processing Standard 198, March 2002.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
- [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, February 2006.
- [X.690] International Telecommunications Union, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", Data Networks and Open System Communication Recommendation X.690, July 2002.
7.2. Informative References
- [IETF.KEY] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress.
- [IEEE.80211] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-1997, 1997.
- [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
- [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.
- [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
Appendix A. Key Generation from Passwords 🔐
If a 128-bit key is not available to bootstrap the authentication process, then one must be generated from some sort of weak preshared key. Note that the security of the hashing process is unimportant, as long as it does not significantly decrease the password's entropy. Resistance to dictionary attacks is provided by PAX_SEC. Consequently, computing the SHA-1 of the password and truncating the output to 128 bits is RECOMMENDED as a means of converting a weak password to a key for provisioning. 🫧
When using other preshared credentials, such as a Kerberos Data Encryption Standard (DES) key, or an MD4-hashed Microsoft Challenge Handshake Authentication Protocol (MSCHAP) password, to provision clients, these keys SHOULD still be put through SHA-1 before being used. This serves to protect the credentials from possible compromise, and also keeps things uniform. As an example, consider provisioning using an existing Kerberos credential. The initial key computation could be SHA1_128(string2key(password)). The KDC, storing string2key(password), would also be able to compute this initial key value. 🎀
Appendix B. Implementation Suggestions 🧚
In this section, two implementation strategies are discussed. The first describes how best to implement and deploy EAP-PAX in an enterprise network for IEEE 802.11i authentication. The second describes how to use EAP-PAX for device authentication in a 3G-style mobile phone network. 📱✨
B.1. WiFi Enterprise Network ✨
okay so for this section, a wireless enterprise network is basically defined by these vibes 🏢📶:
- Users want network access through IEEE 802.11 access points.
- Users might have multiple devices (laptops, PDAs, etc.) they want to authenticate. 💻
- A preexisting authentication framework already exists, like a Microsoft Active Directory domain or a Kerberos realm. 🔐
Okay, so the two biggest challenges in an enterprise WiFi network are key provisioning and supporting multiple devices, and that's literally the whole drama 😭. So it's recommended that the client's Network Access Identifier (NAI) use the format username/KID@realm, where KID is a key ID that can tell different devices apart. Iconic. 💅
The client's supplicant can grab the KID from a bunch of places. The better picks would likely be the computer's NETBIOS name or the local Ethernet adapter's MAC address. 🖥️ The wireless adapter's address might be a suboptimal choice, though, since the user may only have one PCCARD adapter that gets shuffled between multiple systems. Not it. 🙅♀️
Now here's the best part 🫶. Since there's already an authentication system in place, there's a natural choice for the provisioned key: the clients can just authenticate with their existing password. When the server sees a new KID, it can create a new key record and use the user's current password as the provisioned key. For example, with Active Directory, the supplicant could use Microsoft's NtPasswordHash function to generate a key the server can verify. It's suggested that this key then get run through SHA1_128 before it's used in a non-Microsoft authentication protocol. Main character energy for real. 🎀
After a key update, the server should keep track of both the old and new authentication keys. When two keys exist, the server should try using both of them to validate the MACs on transmitted packets. Once a client successfully authenticates with the new key, the server should throw out the old one. This is how you prevent desynchronization attacks, and honestly, I'm obsessed with how clean that is ✨🔥.
B.2. Mobile Phone Network 📱
In a mobile phone system, we don't have to worry about supporting multiple keys per identity anymore 🙌. Presumably each mobile device has a unique identity, so that's a relief. However, if someone does want multiple devices per identity, a method similar to the one in Section B.1 could be used. 🧚
Provisioning could be super easy too: just issue customers a 6-digit PIN they can type into their phone's keypad. 🌸
Authors' Addresses 🦋
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmeade Drive College Park, MD 20740 USA
EMail: clancy@ltsnet.net
William A. Arbaugh University of Maryland Department of Computer Science College Park, MD 20742 USA
EMail: waa@cs.umd.edu
Full Copyright Statement 📜
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔍
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💌
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶
📦 where this page comes from
- ietf: rfc4746 2006-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms