RFC 5216
The EAP-TLS Authentication Protocol
RFC 5216: The EAP-TLS Authentication Protocol 🎀
Network Working Group 💖 This is an IETF document, and it's the Standards Track category ✨ (Request for Comments: 5216).
Authors: D. Simon, B. Aboba, and R. Hurst, all from Microsoft Corporation 👑
Date: March 2008 📅
Obsoletes: RFC 2716 💅
Status of This Memo 📜
okay so this is an Internet standards track protocol for the Internet community 🌈 It's open for discussion and suggestions for improvements, so bring your ideas! 💜 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) ⭐ Distribution of this memo is unlimited, so share it with everyone 🦋
Abstract ✨
bestie, the Extensible Authentication Protocol (EAP), defined in RFC 3748, gives us support for multiple authentication methods 🔥 Transport Layer Security (TLS) brings mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints 🫶 Put them together and you get EAP-TLS, which supports certificate-based mutual authentication and key derivation. It's giving security glow-up 💎
This document obsoletes RFC 2716, so it replaces that one 💅 If you want the full rundown of what changed between this document and RFC 2716, it's all in Appendix A 🌸
Table of Contents 🗂️
1. Introduction ....................................................2
1.1. Requirements ...............................................3
1.2. Terminology ................................................3
2. Protocol Overview ...............................................4
2.1. Overview of the EAP-TLS Conversation .......................4
2.1.1. Base Case ...........................................4
2.1.2. Session Resumption ..................................7
2.1.3. Termination .........................................8
2.1.4. Privacy ............................................11
2.1.5. Fragmentation ......................................14
2.2. Identity Verification .....................................16
2.3. Key Hierarchy .............................................17
2.4. Ciphersuite and Compression Negotiation ...................19
3. Detailed Description of the EAP-TLS Protocol ...................20
3.1. EAP-TLS Request Packet ....................................20
3.2. EAP-TLS Response Packet ...................................22
4. IANA Considerations ............................................23
5. Security Considerations ........................................24
5.1. Security Claims ...........................................24
5.2. Peer and Server Identities ................................25
5.3. Certificate Validation ....................................26
5.4. Certificate Revocation ....................................27
5.5. Packet Modification Attacks ...............................28
6. References .....................................................29
6.1. Normative References ......................................29
6.2. Informative References ....................................29
Acknowledgments ...................................................31
Appendix A -- Changes from RFC 2716 ...............................321. Introduction ✨
okay so EAP, described in [RFC3748], is the standard mechanism for supporting multiple authentication methods 🌸 Thanks to EAP, you can add all kinds of authentication schemes, like smart cards, Kerberos, Public Key, One Time Passwords, and more 🧚 EAP is built to run over a bunch of different lower layers: the Point-to-Point Protocol (PPP) [RFC1661], Layer 2 tunneling protocols like the Point-to-Point Tunneling Protocol (PPTP) [RFC2637] or Layer 2 Tunneling Protocol (L2TP) [RFC2661], IEEE 802 wired networks [IEEE-802.1X], and wireless tech like IEEE 802.11 [IEEE-802.11] and IEEE 802.16 [IEEE-802.16e] 🦋
While the EAP methods defined in [RFC3748] didn't support mutual authentication, wireless tech like [IEEE-802.11] changed the game and created a new set of requirements 😭 As described in "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs" [RFC4017], EAP methods used for wireless LAN authentication should ideally support mutual authentication and key derivation 💜 Other link layers can also use EAP to get mutual authentication and key derivation too 🔥
This document defines EAP-Transport Layer Security (EAP-TLS) 💖 It supports certificate-based mutual authentication and key derivation, and it uses the protected ciphersuite negotiation, mutual authentication, and key management capabilities of TLS, described in "The Transport Layer Security (TLS) Protocol Version 1.1" [RFC4346] ✨ EAP-TLS obsoletes RFC 2716 [RFC2716], but it's still backward compatible with it 🫶 Again, the full list of changes is in Appendix A 🌈
1.1. Requirements 📋
bestie, here's the important bit: 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] 👑 Those words are the ones with the real weight, so pay attention to them 💅
1.2. Terminology 📖
this document uses a bunch of terms a lot, so here they are 🎀
authenticator The entity initiating EAP authentication. 🚀
peer The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the Supplicant. 🦋
backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X]. 🧚
EAP server The entity that terminates the EAP authentication method with the peer. If there's no backend authentication server, the EAP server is part of the authenticator. If the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. 💜
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. 🔑
Extended Master Session Key (EMSK) Additional keying material derived between the EAP peer and server that is exported by the EAP method. 🗝️
2. Protocol Overview 🌊
2.1. Overview of the EAP-TLS Conversation 💬
As described in [RFC3748], the EAP-TLS conversation will typically start with the authenticator and the peer negotiating EAP 🌸 Then the authenticator will typically send an EAP-Request/Identity packet to the peer, and the peer responds with an EAP-Response/Identity packet to the authenticator, which contains the peer's user-Id 🫶
From this point forward, the EAP conversation is nominally between the EAP authenticator and the peer, but the authenticator MAY act as a pass-through device 🔥 In that case, the EAP packets received from the peer are encapsulated for transmission to a backend authentication server 😭 In the discussion that follows, we'll use the term "EAP server" to mean the ultimate endpoint talking to the peer 👑 Stay tuned, because the good stuff is coming! 💖
2.1.1. Base Case ✨
okay so once the EAP server has the peer's Identity, it MUST respond with an EAP-TLS/Start packet 🎀. That's an EAP-Request packet with EAP-Type=EAP-TLS, the Start (S) bit set, and no data. Then the EAP-TLS conversation kicks off: the peer sends an EAP-Response with EAP-Type=EAP-TLS, and its data field wraps up one or more TLS records in TLS record layer format, carrying a TLS client_hello handshake message 💅.
Until then, the cipher spec is TLS_NULL_WITH_NULL_NULL with null compression 🌸. That stays the same until a change_cipher_spec message says the records after it use the negotiated attributes for the rest of the handshake. It's giving "wait for the signal" energy 🦋.
The client_hello carries the peer's TLS version number, a sessionId, a random number, and a set of ciphersuites the peer supports. The version offered by the peer MUST correspond to TLS v1.0 or later 💖.
The EAP server then replies with an EAP-Request packet with EAP-Type=EAP-TLS. Its data field wraps one or more TLS records holding a TLS server_hello handshake message, possibly followed by TLS certificate, server_key_exchange, certificate_request, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message ✨. The server_hello has a TLS version number, another random number, a sessionId, and a ciphersuite. The version offered by the server MUST correspond to TLS v1.0 or later 🌈.
Now the sessionId drama 👑. If the peer's sessionId is null or unrecognized by the server, the server MUST choose the sessionId to establish a new session. Otherwise, the sessionId matches the one the peer offered, which means the previous session is being resumed 🧚. The server also picks a ciphersuite from the ones the peer offered. If the session matches the peer's, then the ciphersuite MUST match the one negotiated during the handshake that originally established the session 🔥.
If the EAP server is NOT resuming a session, it MUST include a TLS certificate handshake message, and a server_hello_done handshake message MUST be the last handshake message in that EAP-Request packet 🍓.
The certificate message holds a public key certificate chain for either a key exchange public key (like RSA or Diffie-Hellman) or a signature public key (like RSA or Digital Signature Standard (DSS)). In the signature case, a TLS server_key_exchange handshake message MUST also be included so the key exchange can happen 🫶.
The certificate_request message shows up when the server wants the peer to authenticate itself with a public key. The EAP server SHOULD require peer authentication, but it's not mandatory 🙈. There are situations where peer authentication isn't needed (like emergency services, described in [UNAUTH]), or where the peer authenticates some other way.
If the peer supports EAP-TLS and is set up to use it, it MUST respond to the EAP-Request with an EAP-Response packet of EAP-Type=EAP-TLS 💜. If the server_hello in the previous EAP-Request did not signal resumption, the data field MUST wrap one or more TLS records containing client_key_exchange, change_cipher_spec, and finished messages 😭. If the EAP server sent a certificate_request in that earlier packet, then unless the peer is configured for privacy (see Section 2.1.4), the peer MUST also send certificate and certificate_verify messages. The first has a certificate for the peer's signature public key, and the second has the peer's signed authentication response to the EAP server 🎀. After getting this packet, the EAP server verifies the peer's certificate and digital signature, if one was requested 🔍.
If the server_hello in the previous EAP-Request DID signal resumption, then the peer MUST send only the change_cipher_spec and finished handshake messages. The finished message holds the peer's authentication response to the EAP server 🌸.
When EAP-TLS mutual authentication succeeds, the conversation goes like this 🦋:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success2.1.2. Session Resumption 🔁
The whole point of the sessionId in TLS is efficiency 💅. It helps when a peer keeps trying to authenticate to an EAP server within a short window. This model was built for HTTP authentication, but it can also give you "fast reconnect" functionality, as defined in Section 7.2.1 of [RFC3748] ✨.
The peer gets to decide whether to try continuing a previous session, which makes the TLS conversation shorter 🌈. Usually that call is based on how much time has passed since the last authentication attempt to that EAP server ⏰. The EAP server then looks at the sessionId the peer picked, plus the time elapsed since the last authentication, and decides whether to allow the continuation or pick a new session 👑.
If the EAP server and authenticator live on the same device, the peer can only continue sessions when it connects to that same authenticator 🧚. If the authenticators are set up in a rotary or round-robin way, the peer might not know in advance which authenticator it'll land on, so it might not know which sessionId to reuse 💀. Because of that, the continuation attempt will probably fail. When EAP authentication is remoted, though, continuation is way more likely to work, since multiple authenticators share the same backend authentication server 🍓.
If the EAP server is resuming a previously established session, it MUST include only a TLS change_cipher_spec message and a TLS finished handshake message after the server_hello message 🫶. The finished message holds the EAP server's authentication response to the peer 💜.
When a previous session is being resumed and both sides authenticate successfully, the conversation looks like this 🎀:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- EAP-Success2.1.3. Termination ✨
Okay so, if the peer's authentication fails, the EAP server SHOULD send an EAP-Request packet with EAP-Type=EAP-TLS, wrapping a TLS record that holds the right TLS alert message 🚨. It SHOULD send that alert right away to end the convo, so the peer can tell the user, log what went wrong, and maybe try again later 🔄.
To make sure the peer actually gets that alert, the EAP server MUST wait for the peer to reply with an EAP-Response packet 👀. The peer's reply MAY carry a TLS client_hello, and if it does, the EAP server MAY let the EAP-TLS conversation restart 🔁. Or the reply MAY be an EAP-Response with EAP-Type=EAP-TLS and no data, and then the EAP-Server MUST send an EAP-Failure packet and end the conversation 💀.
Whether restarts are allowed is totally up to the EAP server, and so is how many times a conversation can restart 🤷♀️. An EAP Server that can restart conversations SHOULD put a per-peer limit on the number of restarts, so nobody can spam it into a denial-of-service attack 🛡️. Protecting your server is so iconic 💅.
If the peer authenticates successfully, the EAP server MUST respond with an EAP-Request packet with EAP-Type=EAP-TLS 🎉. If this is a new TLS session, that response includes one or more TLS records with the TLS change_cipher_spec and finished handshake messages 🧁. The finished message is where the EAP server's own authentication response to the peer lives 🫶. The peer then checks that finished message to authenticate the EAP server ✨.
If EAP server authentication fails, the peer SHOULD delete the session from its cache, so the sessionId can't be reused 🗑️. The peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message that explains why the authentication failed 🙈. The peer MAY also send that TLS alert instead of bailing immediately, so the EAP server can log the error for the system administrator to look at later 📋.
To make sure the EAP Server gets that TLS alert message, the peer MUST wait for the EAP Server to reply before ending the conversation 🫠. The EAP Server MUST reply with an EAP-Failure packet, because a server authentication failure is a terminal condition 🚫.
If the EAP server authenticates successfully, the peer MUST send an EAP-Response packet of EAP-Type=EAP-TLS with no data 🙌. Then the EAP Server MUST respond with an EAP-Success message 🏆.
Here's what it looks like when the server authenticates fine but the peer fails to authenticate back 😭:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Request
EAP-Type=EAP-TLS
(TLS Alert message)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Failure
(User Disconnected)And here's the one where server authentication fails 💔:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Alert message) ->
<- EAP-Failure
(User Disconnected)2.1.4. Privacy 🕵️♀️
EAP-TLS peer and server implementations MAY support privacy 🔐. The username stays hidden by using a privacy Network Access Identifier (NAI) [RFC4282] in the EAP-Response/Identity, and by sending the peer certificate inside a TLS session that provides confidentiality 🤐.
To keep the peer username private, an EAP-TLS peer that's configured for privacy MUST negotiate a TLS ciphersuite that supports confidentiality 🔒. It MUST also send a client certificate list with no entries in response to the initial certificate_request from the EAP-TLS server 🫣.
An EAP-TLS server that supports privacy MUST NOT treat an empty certificate list as a terminal condition 🙅♀️. Instead, it MUST bring up the TLS session and then send a hello_request 👋. After that the handshake carries on as normal: the peer sends a client_hello, and the server replies with a server_hello, certificate, server_key_exchange, certificate_request, server_hello_done, and so on 🔁.
For calculating exported keying material (see Section 2.3), the master_secret that was derived in the second handshake is the one that gets used 🗝️.
An EAP-TLS peer that supports privacy MUST provide a certificate list with at least one entry in response to the later certificate_request from the server 📜. If an EAP-TLS server that supports privacy doesn't get a client certificate in response to that later certificate_request, it MUST abort the session 🛑.
EAP-TLS privacy support is designed so that EAP-TLS peers which don't support privacy can still work with EAP-TLS servers that do 🤝. EAP-TLS servers that support privacy MUST request a client certificate, and MUST be able to accept a client certificate offered by the EAP-TLS peer, so they stay interoperable with EAP-TLS peers that don't support privacy 🧩.
Now the catch, bestie 🙈: an EAP-TLS peer configured for privacy usually can't successfully authenticate with an EAP-TLS server that doesn't support privacy. That's because a server like that will usually treat the refusal to give a client certificate as a terminal error 😩. So, unless failing authentication is considered better than revealing the username, EAP-TLS peers SHOULD only be configured for privacy on networks known to support it 🧐.
The easiest way to pull this off is with EAP lower layers that support network advertisement, so the network and the right privacy configuration can be figured out 📡. On link layers that don't support network advertisement (like IEEE 802 wired networks), it may be useful to look at information in the server certificate, such as the subject and subjectAltName fields, or at identity selection hints [RFC4284], to work out the correct configuration 🔍.
Here's how the conversation goes when both the peer and the server support privacy and mutual authentication 🫶✨:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (Anonymous NAI) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate (no cert),
TLS client_key_exchange,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
finished,
hello_request)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
TLS server_key_exchange,
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success2.1.5. Fragmentation ✨
Okay bestie, so a single TLS record can be up to 16384 octets 🎀, but a TLS message can span multiple TLS records, and a TLS certificate message can in principle be as long as 16 MB 😭. That means the group of EAP-TLS messages sent in a single round can be bigger than the MTU size or the maximum Remote Authentication Dail-In User Service (RADIUS) packet size of 4096 octets 💀. So an EAP-TLS implementation MUST provide its own support for fragmentation and reassembly 🫶. Still, for interoperability with existing implementations, TLS handshake messages SHOULD NOT be fragmented into multiple TLS records if they fit within a single TLS record 🌸.
To guard against reassembly lockup and denial-of-service attacks 🙈, it may be desirable for an implementation to set a maximum size for one of these groups of TLS messages. A single certificate is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, so a reasonable choice of maximum acceptable message length might be 64 KB 🦋.
EAP is a simple ACK-NAK protocol, so adding fragmentation support is pretty straightforward 💅. Fragments that get lost or damaged in transit just get retransmitted, and since the Identifier field in EAP already gives us sequencing info, we don't need a fragment offset field like the one IPv4 has 🧚.
EAP-TLS fragmentation support comes from a flags octet in the EAP-Response and EAP-Request packets, plus a four-octet TLS Message Length field 🌈. The flags are the Length included (L), More fragments (M), and EAP-TLS Start (S) bits. The L flag says the four-octet TLS Message Length field is present, and it MUST be set for the first fragment of a fragmented TLS message or set of messages 🔥. The M flag is set on all but the last fragment. The S flag is only set within the EAP-TLS start message sent from the EAP server to the peer. The TLS Message Length field is four octets and gives the total length of the TLS message or set of messages being fragmented, which makes buffer allocation way easier 👑.
When an EAP-TLS peer gets an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and no data. That's the fragment ACK ✨. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. To keep fragment processing from going sideways, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments keep the same Identifier value 💜.
It works the other way too 🦋. When the EAP server gets an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS and no data, which is its fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. To prevent errors in fragment processing, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response 🎀.
Here's what the conversation looks like when mutual authentication succeeds and fragmentation is needed 👀:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
(Fragment 1: L, M bits set)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Request/
EAP-Type=EAP-TLS
(Fragment 2: M bit set)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Request/
EAP-Type=EAP-TLS
(Fragment 3)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished)(Fragment 1:
L, M bits set)->
<- EAP-Request/
EAP-Type=EAP-TLS
EAP-Response/
EAP-Type=EAP-TLS
(Fragment 2)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success2.2. Identity Verification ✨
As noted in Section 5.1 of [RFC3748] 📖:
It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response.
During the TLS negotiation, the server shows the peer its certificate, and if mutual authentication is requested, the peer shows the server its certificate too 🔐. So EAP-TLS gives us a way to figure out both the peer identity (Peer-Id in [KEYFRAME]) and the server identity (Server-Id in [KEYFRAME]) 💖. For the details, check out Section 5.2.
Now, the identity in the EAP-Response/Identity doesn't have to match the identity in the peer certificate 🙃. So EAP-TLS implementations SHOULD NOT require that they be identical. If they're not identical, though, the identity in the EAP-Response/Identity is unauthenticated info, and it SHOULD NOT be used for access control or accounting purposes 🚫. Don't trust that one, bestie 💅.
2.3. Key Hierarchy 🗝️
Figure 1 shows the TLS Key Hierarchy, which is described in [RFC4346] Section 6.3 ✨. The derivation goes like this:
master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random) key_block =
TLS-PRF-X(master_secret, "key expansion",
server.random || client.random)Where:
TLS-PRF-X = TLS pseudo-random function defined in [RFC4346],
computed to X octets.In EAP-TLS, the MSK, EMSK, and Initialization Vector (IV) are derived from the TLS master secret through a one-way function 🌸. This means the TLS master secret can't be derived from the MSK, EMSK, or IV unless the one-way function (TLS PRF) is broken 🔒. The flip side is that since the MSK and EMSK come from the TLS master secret, if the TLS master secret is compromised, the MSK and EMSK are compromised too 😭.
The MSK is split into two halves: the "Peer to Authenticator Encryption Key" (Enc-RECV-Key, 32 octets) and the "Authenticator to Peer Encryption Key" (Enc-SEND-Key, 32 octets) 🦋.
The IV is a 64-octet quantity with a known value. Octets 0-31 are the "Peer to Authenticator IV" or RECV-IV, and octets 32-63 are the "Authenticator to Peer IV", or SEND-IV 🧚.
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<----+
| | (TMS) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| key_block |
| label == "key expansion" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV
| | | | | |
V V V V V V
Figure 1 - TLS [RFC4346] Key HierarchyEAP-TLS derives exported keying material and parameters like this 🎀:
Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
client.random || server.random)
MSK = Key_Material(0,63)
EMSK = Key_Material(64,127)
IV = TLS-PRF-64("", "client EAP encryption",
client.random || server.random)
Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK in [IEEE-802.11].
Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key
(MS-MPPE-Send-Key in [RFC2548])
RECV-IV = IV(0,31) = Peer to Authenticator Initialization Vector
SEND-IV = IV(32,63) = Authenticator to Peer Initialization
Vector
Session-Id = 0x0D || client.random || server.random
Where:
Key_Material(W,Z) = Octets W through Z inclusive of the key material.
IV(W,Z) = Octets W through Z inclusive of the IV.
MSK(W,Z) = Octets W through Z inclusive of the MSK.
EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
TLS-PRF-X = TLS PRF function computed to X octets.
client.random = Nonce generated by the TLS client.
server.random = Nonce generated by the TLS server. | | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<----+
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MSK, EMSK |
| label == "client EAP encryption" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| MSK(0,31) | MSK(32,63) | EMSK(0,63)
| | |
| | |
V V V
Figure 2 - EAP-TLS Key HierarchyThe use of these keys depends on the lower layer, as described in Section 2.1 of [KEYFRAME] 🌈.
2.4. Ciphersuite and Compression Negotiation ✨
okay bestie, first things first 💅 EAP-TLS implementations MUST support TLS v1.0. no exceptions, no cap 🔥
they don't necessarily have to support every single TLS ciphersuite from [RFC4346] though 🫶 not all of them are supported by the available TLS toolkits, and some might need licenses, which is so annoying 😭
for interop to actually work, peers and servers MUST support this mandatory-to-implement ciphersuite:
TLS_RSA_WITH_3DES_EDE_CBC_SHApeers and servers SHOULD also support and be able to negotiate these ones 🌸
TLS_RSA_WITH_RC4_128_SHA [RFC4346]
TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268]and EAP-TLS servers SHOULD support and be able to negotiate this one too 🎀
TLS_RSA_WITH_RC4_128_MD5 [RFC4346]so here's the tea 🍓 TLS does ciphersuite negotiation, so peers that finish the TLS negotiation will have picked a ciphersuite, and that includes the encryption and hashing methods. but the ciphersuite negotiated inside EAP-TLS only applies to the EAP conversation itself. so TLS ciphersuite negotiation MUST NOT be used to negotiate the ciphersuites used to secure data. main character energy for keeping those two things separate 👑
TLS also does compression, but during the EAP-TLS conversation the EAP peer and server MUST NOT request or negotiate compression. no compression in here, periodt ✨
3. Detailed Description of the EAP-TLS Protocol 🦋
3.1. EAP-TLS Request Packet
ok so here's what the EAP-TLS Request packet looks like 💖 the fields go left to right, like reading a book 📖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code
the Code is 1 🌈
Identifier
the Identifier is one octet and it helps match responses to requests 🧚 the Identifier MUST be changed on each Request packet. every new request gets a fresh one, bestie 💜
Length
the Length is two octets and tells you how long the EAP packet is, counting the Code, Identifier, Length, Type, and Data fields. octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception. so padding that's hanging out past the Length? ignore it, it's not your business 💅
Type
the Type is 13, which is EAP-TLS 🎀
Flags
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|L M S R R R R R|
+-+-+-+-+-+-+-+-+- L = Length included
- M = More fragments
- S = EAP-TLS start
- R = Reserved
ok the L bit (length included) gets set to say the four-octet TLS Message Length field is there, and it MUST be set for the first fragment of a fragmented TLS message or set of messages 🔥 the M bit (more fragments) is set on all but the last fragment. the S bit (EAP-TLS start) is set in an EAP-TLS Start message, and that's how you tell a Start apart from a fragment acknowledgment 🫶 implementations of this specification MUST set the reserved bits to zero, and MUST ignore them on reception. zero them out, ignore them on arrival, easy 🌸
TLS Message Length
the TLS Message Length is four octets, and it only shows up if the L bit is set. it's the total length of the TLS message or set of messages that's getting fragmented 🍓
TLS data
the TLS data is the encapsulated TLS packet in TLS record format 💖
3.2. EAP-TLS Response Packet
here's the EAP-TLS Response packet, same vibe as the Request but with its own flags ✨ the fields still go left to right 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code
the Code is 2 💜
Identifier
the Identifier is one octet and it MUST match the Identifier field from the corresponding request. no mismatched ids, that's just chaos 🙈
Length
the Length is two octets and tells you how long the EAP packet is, counting the Code, Identifier, Length, Type, and Data fields. octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception. same padding rule as the Request, iconic consistency 👑
Type
the Type is 13, which is EAP-TLS 🎀
Flags
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|L M R R R R R R|
+-+-+-+-+-+-+-+-+- L = Length included
- M = More fragments
- R = Reserved
the L bit (length included) gets set to say the four-octet TLS Message Length field is present, and it MUST be set for the first fragment of a fragmented TLS message or set of messages 🌸 the M bit (more fragments) is set on all but the last fragment. implementations of this specification MUST set the reserved bits to zero, and MUST ignore them on reception 🫶
TLS Message Length
the TLS Message Length is four octets, and it's only there if the L bit is set. it's the total length of the TLS message or set of messages being fragmented ✨
TLS data
the TLS data is the encapsulated TLS packet in TLS record format 🧚
4. IANA Considerations 🌈
IANA has allocated EAP Type 13 for EAP-TLS. the allocation has been updated to reference this document. the paperwork is all done, bestie 💅
5. Security Considerations 🔥
this part is serious, so let's go 🫶 no skipping!
5.1. Security Claims
EAP security claims are defined in Section 7.2.1 of [RFC3748]. the security claims for EAP-TLS are below 💖
Auth. mechanism: Certificates
Ciphersuite negotiation: Yes [4]
Mutual authentication: Yes [1]
Integrity protection: Yes [1]
Replay protection: Yes [1]
Confidentiality: Yes [2]
Key derivation: Yes
Key strength: [3]
Dictionary attack prot.: Yes
Fast reconnect: Yes
Crypt. binding: N/A
Session independence: Yes [1]
Fragmentation: Yes
Channel binding: NoNotes
[1] okay this one is a big deal 😭 a formal proof of the security of EAP-TLS when used with [IEEE-802.11] is provided in [He]. the proof relies on the assumption that the private key pairs used by the EAP peer and server are not shared with other parties or applications. so for example, a backend authentication server supporting EAP-TLS SHOULD NOT utilize the same certificate with https. don't reuse certs across services, bestie, that's the whole thing 🙈
[2] privacy is an optional feature, described in Section 2.1.4 🌸
[3] Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or Diffie-Hellman (DH) module and Digital Signature Algorithm (DSA) subgroup size in bits, for a given level of attack resistance in bits. for example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength 🔥 the National Institute of Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
[4] EAP-TLS inherits the secure ciphersuite negotiation features of TLS, including key derivation function negotiation when utilized with TLS v1.2 [RFC4346bis] 👑
5.2. Peer and Server Identities
the EAP-TLS peer name (Peer-Id) represents the identity used for access control and accounting purposes 🎀 the Server-Id represents the identity of the EAP server. together, the Peer-Id and Server-Id name the entities involved in deriving the MSK/EMSK 💖
in EAP-TLS, the Peer-Id and Server-Id come from the subject or subjectAltName fields in the peer and server certificates. for details, see Section 4.1.2.6 of [RFC3280]. where the subjectAltName field is present in the peer or server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName. if subject naming information is present only in the subjectAltName extension of a peer or server certificate, then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical ✨ this is the kind of detail that makes or breaks an implementation, so don't skip it 🫶
where the peer identity represents a host, a subjectAltName of type dnsName SHOULD be present in the peer certificate. where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in Section 2.1 of [RFC4282]. if a dnsName or rfc822Name are not available, other field types (for example, a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used 🌸
a server identity will typically represent a host, not a user or a resource. as a result, a subjectAltName of type dnsName SHOULD be present in the server certificate. if a dnsName is not available, other field types (for example, a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used 🧚
conforming implementations generating new certificates with Network Access Identifiers (NAIs) MUST use the rfc822Name in the subject alternative name field to describe such identities. the use of the subject name field to contain an emailAddress Relative Distinguished Name (RDN) is deprecated, and MUST NOT be used 🙈 the subject name field MAY contain other RDNs for representing the subject's identity 💜
where it is non-empty, the subject name field MUST contain an X.500 distinguished name (DN). if subject naming information is present only in the subject name field of a peer certificate and the peer identity represents a host or device, the subject name field SHOULD contain a CommonName (CN) RDN or serialNumber RDN. if subject naming information is present only in the subject name field of a server certificate, then the subject name field SHOULD contain a CN RDN or serialNumber RDN 🎀
it's possible for more than one subjectAltName field to be present in a peer or server certificate, in addition to an empty or non-empty subject distinguished name. EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOULD export all the subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also export a non-empty subject distinguished name field within the Peer-Ids or Server-Ids. all of the exported Peer-Ids and Server-Ids are considered valid 🌈
EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOULD export Peer-Ids and Server-Ids in the same order in which they appear within the certificate. that canonical ordering would aid in comparison operations and would enable using those identifiers for key derivation, if that's deemed useful 🦋 however, the ordering of fields within the certificate SHOULD NOT be used for access control. don't let cert field order decide who gets in, that's a vibe check fail 💀
5.3. Certificate Validation 🔍
Okay so, the EAP-TLS server is usually hanging out on the Internet, which means it SHOULD support validating the peer certificate using RFC 3280 [RFC3280] compliant path validation, including the ability to retrieve intermediate certificates that may be necessary to validate the peer certificate. For details, see Section 4.2.2.1 of [RFC3280]. 💖
Now, if the EAP-TLS server can't retrieve those intermediate certificates, it either needs to be pre-configured with the necessary intermediate certificates to finish path validation, or it will rely on the EAP-TLS peer to send that info as part of the TLS handshake (see Section 7.4.6 of [RFC4346]). 🧚
The EAP-TLS peer is a different story because it may not have Internet connectivity. So the EAP-TLS server SHOULD provide its entire certificate chain minus the root so the peer can do certificate validation. The EAP-TLS peer SHOULD support validating the server certificate using RFC 3280 [RFC3280] compliant path validation. 🌸
Once a TLS session is established, EAP-TLS peer and server implementations MUST validate that the identities represented in the certificate are appropriate and authorized for use with EAP-TLS. Authorization uses the contents of the certificates plus other contextual information. Authorization requirements will vary from deployment to deployment, but it is RECOMMENDED that implementations be able to authorize based on the EAP-TLS Peer-Id and Server-Id determined as described in Section 5.2. 👑
For the EAP-TLS peer, this means making sure the certificate presented by the EAP-TLS server was actually meant to be a server certificate. Implementations SHOULD use the Extended Key Usage (see Section 4.2.1.13 of [RFC3280]) extension and make sure at least one of the following is true: 🎀
- The certificate issuer included no Extended Key Usage identifiers in the certificate.
- The issuer included the anyExtendedKeyUsage identifier in the certificate (see Section 4.2.1.13 of [RFC3280]).
- The issuer included the id-kp-serverAuth identifier in the certificate (see Section 4.2.1.13 [RFC3280]).
When performing this comparison, implementations MUST follow the validation rules specified in Section 3.1 of [RFC2818]. For the server, it's the same vibe but flipped: it has to make sure the certificate presented by the EAP-TLS peer was meant to be a client certificate. Implementations SHOULD use the Extended Key Usage (see Section 4.2.1.13 [RFC3280]) extension and make sure at least one of the following is true: 🦋
- The certificate issuer included no Extended Key Usage identifiers in the certificate.
- The issuer included the anyExtendedKeyUsage identifier in the certificate (see Section 4.2.1.13 of [RFC3280]).
- The issuer included the id-kp-clientAuth identifier in the certificate (see Section 4.2.1.13 of [RFC3280]).
5.4. Certificate Revocation 🥀
Certificates are long-lived assertions of identity, so it's super important for EAP-TLS implementations to be able to check whether those assertions have been revoked. 🔥
EAP-TLS peer and server implementations MUST support the use of Certificate Revocation Lists (CRLs); for details, see Section 3.3 of [RFC3280]. They SHOULD also support the Online Certificate Status Protocol (OCSP), described in "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP" [RFC2560]. OCSP messages are typically much smaller than CRLs, which can shorten connection times, especially in bandwidth-constrained environments. EAP-TLS servers are usually connected to the Internet during the EAP conversation, but an EAP-TLS peer may not have Internet connectivity until authentication completes. 🌈
Now, if the peer is starting a voluntary Layer 2 tunnel using PPTP [RFC2637] or L2TP [RFC2661], it will typically already have a PPP interface and Internet connectivity set up at the time the tunnel starts. ✨
But if the EAP-TLS peer is trying to get network access, it has no network connectivity, so it can't check for certificate revocation until after authentication completes and connectivity is available. For this reason, EAP-TLS peers and servers SHOULD implement Certificate Status Request messages, as described in "Transport Layer Security (TLS) Extensions", Section 3.6 of [RFC4366]. To enable revocation checking when servers don't support Certificate Status Request messages and there's no network connectivity before authentication completes, peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available, and they SHOULD utilize this capability by default. 💅
5.5. Packet Modification Attacks 💀
The integrity protection of EAP-TLS packets does NOT extend to the EAP header fields (Code, Identifier, Length) or the Type or Flags fields. So an attacker can modify these fields. Not okay. 🙈
Modifying the Code or Identifier fields will mostly just cause a denial-of-service attack. But an attacker can add extra data to an EAP-TLS packet so it's longer than the Length field says. EAP peers, authenticators, or servers that don't check for this could be vulnerable to a buffer overrun.
Heads up: the buffer overrun bit is the scary part. Checking the Length field is not optional vibes, it's the difference between safe and vulnerable. 😭
An attacker can also modify the Type or Flags fields. By changing the Type field, an attacker could make one TLS-based EAP method get negotiated instead of another. For example, the EAP-TLS Type field (13) could be changed to indicate another TLS-based EAP method. Unless the alternative TLS-based EAP method uses a different key derivation formula, an EAP method conversation altered by a man-in-the-middle could run all the way to completion without anyone noticing. And unless the ciphersuite selection policies are identical for all TLS-based EAP methods using the same key derivation formula, an attacker might be able to pull off a successful downgrade attack, making the peer use an inferior ciphersuite or TLS-based EAP method. 🍓
6. References 📚
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
C. Adams, "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 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.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, Ed., "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.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.6.2. Informative References
[IEEE-802.1X] Institute of Electrical and Electronics Engineers,
"Local and Metropolitan Area Networks: Port-Based
Network Access Control", IEEE Standard 802.1X-2004,
December 2004.
[IEEE-802.11] 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 Std.
802.11-2007, 2007.
[IEEE-802.16e] Institute of Electrical and Electronics Engineers,
"IEEE Standard for Local and Metropolitan Area
Networks: Part 16: Air Interface for Fixed and Mobile
Broadband Wireless Access Systems: Amendment for
Physical and Medium Access Control Layers for Combined
Fixed and Mobile Operations in Licensed Bands", IEEE
802.16e, August 2005.
[He] He, C., Sundararajan, M., Datta, A., Derek, A. and J.
Mitchell, "A Modular Correctness Proof of IEEE 802.11i
and TLS", CCS '05, November 7-11, 2005, Alexandria,
Virginia, USA
[KEYFRAME] Aboba, B., Simon, D. and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management
Framework", Work in Progress, November 2007.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
Attributes", RFC 2548, March 1999.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J.,
Little, W., and G. Zorn, "Point-to-Point Tunneling
Protocol (PPTP)", RFC 2637, July 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 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.
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen,
"Identity Selection Hints for the Extensible
Authentication Protocol (EAP)", RFC 4284, January
2006.
[SP800-57] National Institute of Standards and Technology,
"Recommendation for Key Management", Special
Publication 800-57, May 2006.
[RFC4346bis] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.2", Work in Progress, February 2008.
[UNAUTH] Schulzrinne. H., McCann, S., Bajko, G. and H.
Tschofenig, "Extensions to the Emergency Services
Architecture for dealing with Unauthenticated and
Unauthorized Devices", Work in Progress, November
2007.Acknowledgments 🫶
Huge thanks to Terence Spies, Mudit Goel, Anthony Leibovitz, and Narendra Gidwani of Microsoft, Glen Zorn of NetCube, Joe Salowey of Cisco, and Pasi Eronen of Nokia for the useful discussions of this problem space. You all literally made this happen. 🌟
Appendix A -- Changes from RFC 2716 📝✨
okay so this appendix is basically the "what's new since RFC 2716" changelog 🎀 bestie, the vibe is: EAP stopped being a PPP-only thing and grew up into a multi-lower-layer icon 🦋 Minor stuff like style, grammar, spelling, and editorial fixes is not listed here, so don't look for it 💅
- EAP is now used over a bunch of lower layers, not just PPP (the one it was first designed for) 🌈 So PPP only comes up when we're talking PPP-specific behavior, and other lower layers like IEEE 802.11 and IEEE 802.16 get their own mentions 🧚
- The document now cites TLS v1.1 as a normative reference (see Sections 1 and 6.1) 🔥
- The terminology section now matches the definitions in [RFC3748] (Section 1.2) and the EAP Key Management Framework [KEYFRAME] (Section 1.2) 📚
- Use for peer unauthenticated access is clarified (Section 2.1.1) 🙈
- Privacy is supported as an optional feature (Section 2.1.4) 🫶
- It is no longer recommended that the identity in the EAP-Response/Identity be compared to the identity in the peer certificate (Section 2.2). Honestly this one is a glow-up 💖
- The EAP-TLS key hierarchy is defined using terminology from [RFC3748] 🔑 This includes formulas for TEKs, plus the MSK, EMSK, IV, and Session-Id (Section 2.3) 👑
- Mandatory and recommended TLS ciphersuites are now provided. Using TLS ciphersuite negotiation to determine the lower layer ciphersuite is prohibited (Section 2.4) 🚫💅
- The Start bit is not set within an EAP-Response packet (Section 3.2) ⭐
- There's a new section on security claims, plus advice on key strength (Section 5.1) 💪
- The Peer-Id and Server-Id are now defined (Section 5.2), and requirements for certificate validation (Section 5.3) and revocation (Section 5.4) are provided 🎀
- Packet modification attacks are described (Section 5.5) 😭
- The examples got a refresh to match typical messages in the described scenarios 🌸 For example, where mutual authentication happens, the EAP-TLS server is shown requesting a client certificate, and the peer is shown providing a certificate_verify message 🦋 A privacy example was added, and two faulty examples of session resume failure were removed 🧚✨
Authors' Addresses 💌
Dan Simon Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Phone: +1 425 882 8080 Fax: +1 425 936 7329 EMail: dansimon@microsoft.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Phone: +1 425 706 6605 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com
Ryan Hurst Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Phone: +1 425 882 8080 Fax: +1 425 936 7329 EMail: rmh@microsoft.com
Full Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information 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; nor does it 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. 🫶🌈
📦 where this page comes from
- ietf: rfc5216 2008-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms