RFC 5281
Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)
Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) 🦋
Okay bestie, the title block first! 💅 This is RFC 5281, published in August 2008 by the Network Working Group. It's written by P. Funk (Unaffiliated) and S. Blake-Wilson (SafeNet). The category is Informational, so it's sharing info with the Internet community and is not an Internet standard. ✨ The header doesn't list anything it obsoletes or updates.
Status of This Memo 🌸
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🫶
Abstract 💜
okay so EAP-TTLS is an EAP (Extensible Authentication Protocol) method that wraps up a TLS (Transport Layer Security) session, and that session has two phases: a handshake and a data phase. 🎀 In the handshake phase, the server gets authenticated to the client (or the two of them mutually authenticate) using standard TLS procedures. Keying material gets generated too, so they can build a cryptographically secure tunnel for swapping info in the data phase. 🔐
In the data phase, the client gets authenticated to the server (or they mutually authenticate again) using an arbitrary authentication mechanism that's tucked inside that secure tunnel. That inner mechanism can be EAP itself, or something else like PAP, CHAP, MS-CHAP, or MS-CHAP-V2. 🧚 Basically, EAP-TTLS lets old-school password-based auth protocols work with the existing authentication databases, while also protecting them against eavesdropping, man-in-the-middle, and other attacks. It's giving security glow-up! ✨ The data phase can also be used for extra arbitrary data exchange. 🍓
Table of Contents 🧚
1. Introduction ....................................................4
2. Motivation ......................................................5
3. Requirements Language ...........................................7
4. Terminology .....................................................7
5. Architectural Model .............................................9
5.1. Carrier Protocols .........................................10
5.2. Security Relationships ....................................10
5.3. Messaging .................................................11
5.4. Resulting Security ........................................12
6. Protocol Layering Model ........................................12
7. EAP-TTLS Overview ..............................................13
7.1. Phase 1: Handshake ........................................14
7.2. Phase 2: Tunnel ...........................................14
7.3. EAP Identity Information ..................................15
7.4. Piggybacking ..............................................15
7.5. Session Resumption ........................................16
7.6. Determining Whether to Enter Phase 2 ......................17
7.7. TLS Version ...............................................18
7.8. Use of TLS PRF ............................................18
8. Generating Keying Material .....................................19
9. EAP-TTLS Protocol ..............................................20
9.1. Packet Format .............................................20
9.2. EAP-TTLS Start Packet .....................................21
9.2.1. Version Negotiation ................................21
9.2.2. Fragmentation ......................................22
9.2.3. Acknowledgement Packets ............................22
10. Encapsulation of AVPs within the TLS Record Layer .............23
10.1. AVP Format ...............................................23
10.2. AVP Sequences ............................................25
10.3. Guidelines for Maximum Compatibility with AAA Servers ....25
11. Tunneled Authentication .......................................26
11.1. Implicit Challenge .......................................26
11.2. Tunneled Authentication Protocols ........................27
11.2.1. EAP ...............................................27
11.2.2. CHAP ..............................................29
11.2.3. MS-CHAP ...........................................30
11.2.4. MS-CHAP-V2 ........................................30
11.2.5. PAP ...............................................32
11.3. Performing Multiple Authentications ......................33
11.4. Mandatory Tunneled Authentication Support ................34
11.5. Additional Suggested Tunneled Authentication Support .....34
12. Keying Framework ..............................................35
12.1. Session-Id ...............................................35
12.2. Peer-Id ..................................................35
12.3. Server-Id ................................................35
13. AVP Summary ...................................................35
14. Security Considerations .......................................36
14.1. Security Claims ..........................................36
14.1.1. Authentication Mechanism ..........................36
14.1.2. Ciphersuite Negotiation ...........................37
14.1.3. Mutual Authentication .............................37
14.1.4. Integrity Protection ..............................37
14.1.5. Replay Protection .................................37
14.1.6. Confidentiality ...................................37
14.1.7. Key Derivation ....................................37
14.1.8. Key Strength ......................................37
14.1.9. Dictionary Attack Protection ......................38
14.1.10. Fast Reconnect ...................................38
14.1.11. Cryptographic Binding ............................38
14.1.12. Session Independence .............................38
14.1.13. Fragmentation ....................................38
14.1.14. Channel Binding ..................................38
14.2. Client Anonymity .........................................38
14.3. Server Trust .............................................39
14.4. Certificate Validation ...................................39
14.5. Certificate Compromise ...................................40
14.6. Forward Secrecy ..........................................40
14.7. Negotiating-Down Attacks .................................40
15. Message Sequences .............................................41
15.1. Successful Authentication via Tunneled CHAP ..............41
15.2. Successful Authentication via Tunneled
EAP/MD5-Challenge ........................................43
15.3. Successful Session Resumption ............................46
16. IANA Considerations ...........................................47
17. Acknowledgements ..............................................48
18. References ....................................................48
18.1. Normative References .....................................48
18.2. Informative References ...................................491. Introduction 💖
Okay so Extensible Authentication Protocol (EAP) [RFC3748] defines a standard message exchange that lets a server authenticate a client using an authentication method that both parties agreed on. 🎀 EAP can get extra authentication methods added by registering them with IANA, or by defining vendor-specific methods. Super extensible, no cap! 🌈
Transport Layer Security (TLS) [RFC4346] is an authentication protocol. It can do client authentication of a server, or mutual authentication of client and server, and it also handles secure ciphersuite negotiation and key exchange between the two parties. 🔐 TLS has been defined as an authentication protocol for use within EAP, and that combo is called EAP-TLS [RFC5216]. 👑
Other authentication protocols are also widely deployed. They're typically password-based, and there's a huge installed base of support for them in credential databases. Those databases can be accessed by RADIUS [RFC2865], Diameter [RFC3588], or other AAA servers. 🍓 The non-EAP protocols in this group are PAP [RFC1661], CHAP [RFC1661], MS-CHAP [RFC2433], and MS-CHAP-V2 [RFC2759]. The EAP protocols include MD5-Challenge [RFC3748]. 🧚
EAP-TTLS is an EAP method that gives you functionality beyond what EAP-TLS offers. It's been widely deployed, and this spec basically documents what existing implementations already do. 💅 It does have some limitations and vulnerabilities, though. Those get addressed in EAP-TTLS extensions and in ongoing work on standardized tunneled EAP methods at the IETF. Users of EAP-TTLS are strongly encouraged to think about these in their deployments. 🙈
⚠️ Heads up, bestie: the limitations and vulnerabilities above matter, so please don't skip them when you deploy EAP-TTLS. 💀
In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP-TTLS extends that authentication negotiation by using the secure connection the TLS handshake creates, so client and server can swap extra info. ✨ In EAP-TTLS, the TLS authentication may be mutual, or it may be one-way, where only the server gets authenticated to the client. 🦋 The secure connection from the handshake can then let the server authenticate the client using existing, widely deployed authentication infrastructures. The client's authentication may itself be EAP, or it may be another protocol like PAP, CHAP, MS-CHAP, or MS-CHAP-V2. 💜
Thus, EAP-TTLS lets legacy password-based authentication protocols run against existing authentication databases, while protecting those legacy protocols against eavesdropping, man-in-the-middle, and other attacks. 🛡️ It's giving main character energy for old protocols! 👑
EAP-TTLS also lets client and server establish keying material for use in the data connection between the client and the access point. 🌸 That keying material gets established implicitly between client and server, based on the TLS handshake. Iykyk! 🫶
In EAP-TTLS, client and server communicate using attribute-value pairs that are encrypted within TLS. This generality means arbitrary functions beyond authentication and key exchange can be added to the EAP negotiation, in a way that stays compatible with the AAA infrastructure. 🌈 Literally so flexible! 😭
The main limitation of EAP-TTLS is that its base version doesn't support cryptographic binding between the outer and inner authentication. 🔥 Check out Section 14.1.11 for the details and the conditions where this vulnerability exists. It's worth knowing that an extension for EAP-TTLS [TTLS-EXT] fixed this vulnerability. Users of EAP-TTLS are strongly encouraged to adopt that extension. 🎀 No notes, just do it! 💅
2. Motivation 💅✨
Okay so bestie, let me tell you why this whole thing exists 🫶. Most password-based protocols out there right now work on a hash of the password plus a random challenge 🔐. The server sends a challenge, the client hashes that challenge together with the password and sends back a response, and then the server checks that response against the user's password pulled from its database. This is basically the vibe for CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5-Challenge, and EAP/One-Time Password 🎀.
Here's the problem though 😭. An eavesdropper who sees both the challenge and the response can run a dictionary attack. They test random passwords against the known challenge until one of them produces the known response 💀. Passwords are usually low entropy, so in practice these attacks can easily crack a lot of them 🙈.
Now, this has been known for ages, but nobody really panicked about it because eavesdropping wasn't very likely in most places 🌸. Users on wired or dial-up connections to their service providers never worried that the line was being watched 🧚. People were also totally fine trusting their service provider with their passwords, or at least letting the provider see the challenges and hashed responses that got forwarded to their home authentication servers (using something like proxy RADIUS) 💜. The provider wasn't going to run dictionary attacks on that stuff. And since a user usually has a relationship with just one service provider, that trust was totally manageable ✨.
Then wireless happened, and everything changed 📡🔥.
- Wireless connections are way more open to eavesdropping and man-in-the-middle attacks 👀. These can enable dictionary attacks on low-entropy passwords. They can also enable channel hijacking, where an attacker takes over the communications channel after authentication is already done and gets in without permission 😤.
- Existing authentication protocols often start by sending the client's username in the clear 🙅♀️. When someone is eavesdropping on the wireless channel, that can wreck the client's anonymity and locational privacy 🫣.
- In wireless networks, the access point often isn't in the administrative domain of the service provider the user has a relationship with 🏨. Think airports, coffee shops, or hotels offering public access over 802.11 [802.11] ☕. So even if password authentication is protected on the wireless leg, it can still be eavesdropped on inside the untrusted wired network behind the access point 😬.
- In the old wired world, the user picked a service provider on purpose by dialing its phone number, and that provider could route the authentication to the user's home domain 📞. In wireless, though, the user doesn't get to choose the access domain. They just connect to whatever access point is nearby 📶. Routing the authentication from an arbitrary access point back to the user's home domain can be a real challenge 🧩.
So, the authentication requirements for a wireless environment that EAP-TTLS is trying to handle look like this 🦋:
- Legacy password protocols must be supported, so it's easy to deploy against existing authentication databases 🗄️.
- Password-based information must not be observable in the communications channel between the client node and a trusted service provider, to protect the user against dictionary attacks 🛡️.
- The user's identity must not be observable in the communications channel between the client node and a trusted service provider, to protect the user against surveillance, unwanted marketing info, and that kind of thing 🕵️♀️.
- The authentication process must result in distributing shared keying information to the client and access point, so the wireless data connection can be encrypted and validated after authentication. That keeps it safe from eavesdroppers and stops channel hijacking 🔑.
- The authentication mechanism must support roaming among access domains the user has no relationship with, and which have limited capabilities for routing authentication requests 🌍.
3. Requirements Language 📝
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] 🎀.
4. Terminology 📚
AAA
Authentication, Authorization, and Accounting. These are the functions generally required to control access to a network and to support billing and auditing 💰.
AAA protocol
A network protocol used to communicate with AAA servers. Examples include RADIUS and Diameter 📨.
AAA server
A server that performs one or more AAA functions: authenticating a user before granting network service, providing authorization (policy) information about the type of network service the user is allowed to get, and accumulating accounting information about actual usage 🧾.
AAA/H
A AAA server in the user's home domain, where authentication and authorization for that user are administered 🏠.
access point
A network device that gives users a point of entry into the network. It may enforce access control and policy based on information returned by a AAA server 🚪. Since the access point terminates the server side of the EAP conversation, it's equivalent to the "authenticator" from the EAP specification [RFC3748] for this document. Since the access point acts as a client to a AAA server, it's also equivalent to the "Network Access Server (NAS)" used in AAA specifications like [RFC2865] 🤝.
access domain
The domain, including access points and other devices, that gives users their first point of entry into the network. A wireless hot spot is a good example 🔥.
client
A host or device that connects to a network through an access point. Since it terminates the client side of the EAP conversation, it's equivalent to the "peer" from the EAP specification [RFC3748] for this document 📱.
domain
A network and its associated devices under the administrative control of an entity, like a service provider or the user's home organization 🏢.
link layer
A protocol used to carry data between hosts connected within a single network segment. Examples include PPP and Ethernet 🔗.
NAI
A Network Access Identifier [RFC4282], normally made up of the user's name and, optionally, the user's home realm 🪪.
proxy
A server that can route AAA transactions to the right AAA server, possibly in another domain, usually based on the realm portion of an NAI 🗺️.
realm
The optional part of an NAI that says which domain the AAA transaction should be routed to, normally the user's home domain 🏡.
service provider
An organization that the user has a business relationship with and that provides network or other services. The service provider may provide the access equipment the user connects through, may perform authentication or other AAA functions, may proxy AAA transactions to the user's home domain, and so on 💼.
TTLS server
A AAA server that implements EAP-TTLS. This server may also be able to do user authentication itself, or it may proxy the user authentication to a AAA/H 🧚♀️.
user
The person operating the client device. The line gets blurry sometimes, but "user" refers to the human who has an identity (username), password, or other authenticating info, and "client" refers to the device that uses that info to negotiate network access 🙋♀️. Some clients don't have a human operator. In that case, "user" is just a handy abstraction 🤖.
5. Architectural Model 🏗️
Here's the network architectural model for EAP-TTLS usage and the kind of security it gives you 👑:
+----------+ +----------+ +----------+ +----------+
| | | | | | | |
| client |<---->| access |<---->| TTLS AAA |<---->| AAA/H |
| | | point | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
<---- secure password authentication tunnel --->
<---- secure data tunnel ---->The entities in that diagram are logical entities, and they may or may not match separate network components 🧩. For example, the TTLS server and AAA/H server could be one entity. The access point and TTLS server could be one entity too. Or the functions of the access point, TTLS server, and AAA/H server could all be combined into one physical device 📦. The diagram shows how the work is divided among entities in a general way, and how a distributed system might be built. Real systems might be simpler though 🌈.
Also, one or more AAA proxy servers might be deployed between the access point and TTLS server, or between the TTLS server and AAA/H server 🔀. These proxies typically do aggregation or are needed for realm-based message routing. They play no direct role in EAP-TTLS, though, so they aren't shown 🙈.
5.1. Carrier Protocols 📮
The entities above talk to each other using carrier protocols that can encapsulate EAP 💌. The client and access point usually communicate using a link layer carrier protocol like PPP or EAPOL (EAP over LAN) 🔌. The access point, TTLS server, and AAA/H server communicate using a AAA carrier protocol like RADIUS or Diameter 📡.
EAP, and therefore EAP-TTLS, MUST be initiated via the carrier protocol between client and access point 🚀. In PPP or EAPOL, for example, EAP starts when the access point sends an EAP-Request/Identity packet to the client 👋.
The keying material used to encrypt and authenticate the data connection between the client and access point is developed implicitly between the client and TTLS server as a result of the EAP-TTLS negotiation 🔐. This keying material MUST be communicated to the access point by the TTLS server using the AAA carrier protocol 💖.
5.2. Security Relationships ✨
okay so the client and access point have no pre-existing security relationship 🙈 they're total strangers at the start, no cap.
The access point, TTLS server, and AAA/H server each have a pre-existing security association with the adjacent entity they talk to. With RADIUS, for example, this is done with shared secrets. It is essential for these security relationships to permit secure key distribution 🔑 bestie, that part is non-negotiable.
The client and AAA/H server have a security relationship based on the user's credentials, like a password 🫶
The client and TTLS server can have a one-way security relationship, where the TTLS server proves it holds a private key backed by a CA certificate the user trusts. Or they can go mutual, with certificates for both parties 🦋 it's giving options.
5.3. Messaging 💬
The client and access point start an EAP conversation to negotiate the client's access to the network. Typically, the access point sends an EAP-Request/Identity to the client, and the client replies with an EAP-Response/Identity. ngl this is the classic opener. Note that the client doesn't need to put the user's actual identity in that EAP-Response/Identity packet, except for routing purposes (like realm information; see Section 7.3 and [RFC3748], Section 5.1). The user's actual identity doesn't need to be sent until an encrypted channel has been set up 🔐 patience is a virtue, periodt.
The access point now acts as a passthrough device 🚪, letting the TTLS server negotiate EAP-TTLS with the client directly. Main character energy for the TTLS server.
During the first phase of the negotiation, the TLS handshake protocol authenticates the TTLS server to the client and, optionally, the client to the TTLS server, based on public/private key certificates 🎀 this is the handshake glow-up. When it's done, the client and TTLS server have shared keying material and an agreed TLS record layer cipher suite to secure all the later EAP-TTLS stuff ✨
During the second phase, the client and TTLS server use that secure TLS record layer channel as a tunnel to swap information encapsulated in attribute-value pairs. They do additional stuff here like authentication (one-way or mutual), validating the client's integrity and configuration, and provisioning info needed for data connectivity, etc. 🌈
If a tunneled client authentication happens, the TTLS server de-tunnels the authentication info and forwards it to the AAA/H. If the AAA/H throws a challenge, the TTLS server tunnels that challenge info back to the client. The AAA/H server can be a legacy device and doesn't need to know anything about EAP-TTLS 💅 it only has to authenticate the client using commonly used authentication protocols. Iconic behavior honestly.
The keying material for the later data connection between the client and access point (the Master Session Key / Extended Master Session Key (MSK/EMSK); see Section 8) is generated from secret info developed during the TLS handshake between the client and TTLS server 🔥 after a successful authentication, the TTLS server can send this keying material to the access point, encrypted based on the existing security associations between those devices (e.g., RADIUS).
Last step: the client and access point now share keying material they can use to encrypt data traffic between them 🦋 mission complete.
5.4. Resulting Security 🛡️
As the diagram above indicates, EAP-TTLS lets user identity and password info get sent securely between the client and TTLS server 💖 it also generates keying material so network data sent after authentication can be transmitted securely between the client and access point. Literally the whole point, slay.
6. Protocol Layering Model 🧁
okay so EAP-TTLS packets get encapsulated within EAP, and EAP needs a carrier protocol to transport it 📦 EAP-TTLS packets themselves encapsulate TLS, and TLS is then used to encapsulate attribute-value pairs (AVPs), which can carry user authentication or other info. So EAP-TTLS messaging can be described as a layered model, where each layer is encapsulated by the layer beneath it. Layers all the way down, it's giving onion 🧅 Here's the picture:
+-----------------------------------------------------------+
| AVPs, including authentication (PAP, CHAP, MS-CHAP, etc.) |
+-----------------------------------------------------------+
| TLS |
+-----------------------------------------------------------+
| EAP-TTLS |
+-----------------------------------------------------------+
| EAP |
+-----------------------------------------------------------+
| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
+-----------------------------------------------------------+When the user authentication protocol is itself EAP, the layering looks like this:
+-----------------------------------------------------------+
| EAP Method (MD-Challenge, etc.) |
+-----------------------------------------------------------+
| AVPs, including EAP |
+-----------------------------------------------------------+
| TLS |
+-----------------------------------------------------------+
| EAP-TTLS |
+-----------------------------------------------------------+
| EAP |
+-----------------------------------------------------------+
| Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) |
+-----------------------------------------------------------+Methods for encapsulating EAP within carrier protocols are already defined 🎉 for example, PPP [RFC1661] or EAPOL [802.1X] can carry EAP between the client and access point, and RADIUS [RFC2865] or Diameter [RFC3588] carry EAP between the access point and TTLS server. Everyone has their role, no drama.
7. EAP-TTLS Overview 🦋
okay so an EAP-TTLS negotiation has two phases 💜 the TLS handshake phase and the TLS tunnel phase.
During phase 1, TLS authenticates the TTLS server to the client and, optionally, the client to the TTLS server. Phase 1 activates a cipher suite, which lets phase 2 proceed securely over the TLS record layer. (Heads up: how much security you get in phase 2 depends on the cipher suite negotiated in phase 1. If the null cipher suite is negotiated, there will be no security at all! 💀)
During phase 2, the TLS record layer tunnels information between the client and TTLS server to do all kinds of functions 🌸 these might include user authentication, client integrity validation, negotiating data communication security capabilities, key distribution, communicating accounting info, etc. The info gets swapped as attribute-value pairs (AVPs) that are compatible with RADIUS and Diameter, so any function you can build with those AVPs can easily be done ✨
EAP-TTLS specifies how user authentication happens during phase 2. The user authentication can itself be EAP, or it can be a legacy protocol like PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Phase 2 user authentication isn't always necessary, since the user may already have been authenticated through the mutual authentication option of the TLS handshake 🫶
Functions other than authentication MAY also be performed during phase 2. This document doesn't define any of those; however, any organization or standards body is free to specify how additional functions can be done using appropriate AVPs 🧚
EAP-TTLS also specifies how keying material for the data connection between the client and access point gets generated. The keying material is developed implicitly between the client and TTLS server based on the results of the TLS handshake, and the TTLS server then communicates that keying material to the access point over the carrier protocol 🔐
7.1. Phase 1: Handshake 🤝
In phase 1, the TLS handshake protocol authenticates the TTLS server to the client and, optionally, the client to the TTLS server.
The TTLS server kicks off the EAP-TTLS method with an EAP-TTLS/Start packet, which is an EAP-Request with Type = EAP-TTLS and the S (Start) bit set 🎬 this tells the client it's time to begin the TLS handshake by sending a ClientHello message.
EAP packets keep getting exchanged between the client and TTLS server to finish the TLS handshake, as described in [RFC5216]. Phase 1 is complete when the client and TTLS server exchange ChangeCipherSpec and Finished messages. At this point, additional info can be securely tunneled 💖
As part of the TLS handshake protocol, the TTLS server sends its certificate along with a chain of certificates leading to the certificate of a trusted CA. The client needs to be configured with the certificate of the trusted CA in order to do the authentication 📜
If the client should be authenticated with a certificate, the client must have been issued a certificate and must have the private key associated with that certificate 🗝️
7.2. Phase 2: Tunnel 🚇
In phase 2, the TLS record layer securely tunnels information between the client and TTLS server. This info gets wrapped in sequences of attribute-value pairs (AVPs), whose use and format are described in later sections 🎀
Any type of information can be exchanged during phase 2, depending on what the system needs. (Applications that use EAP-TTLS are expected to specify what info must be exchanged and therefore which AVPs must be supported 📋) The client starts the phase 2 exchange by encoding info into a sequence of AVPs, passing that sequence to the TLS record layer for encryption, and sending the result to the TTLS server.
The TTLS server recovers the AVPs in clear text from the TLS record layer. If the AVP sequence includes authentication info, the TTLS server forwards it to the AAA/H server using the AAA carrier protocol. Note that the EAP-TTLS server and AAA/H server can be one and the same, in which case the server just processes the info locally 🏠
The TTLS server can reply with its own sequence of AVPs. It passes that sequence to the TLS record layer for encryption and sends the result to the client. For example, the TTLS server might forward an authentication challenge it got from the AAA/H 🙌
This keeps going until the AAA/H either accepts or rejects the client. The TTLS server then finishes the EAP-TTLS negotiation and tells the encapsulating EAP protocol whether it succeeded or failed (which normally means a final EAP-Success or EAP-Failure gets sent to the client) ✅
The TTLS server sends the data connection keying info and other authorization info to the access point in the same AAA carrier protocol message that carries the final EAP-Success or other success indication. Everything arrives together, very efficient 👑
7.3. EAP Identity Information 🎀
Okay so the user's identity only shows up in phase 2, where it's hidden inside the TLS tunnel 🔒. But before EAP-TTLS even starts, the client usually sends an EAP-Response/Identity packet, and that one goes out in clear text 👀. To keep users anonymous from eavesdroppers, this packet SHOULD NOT include the actual name of the user. It SHOULD use a blank or placeholder like "anonymous" 🙈. The privacy rule doesn't cover routing info though! So the EAP-Response/Identity MAY include the realm name of a trusted provider where EAP-TTLS packets should get forwarded, like "anonymous@myisp.com" 🧚
Note that the EAP method hasn't been picked yet when the initial EAP-Response/Identity gets sent 🤔. If the client is also up for EAP methods that don't support user anonymity, then the client MAY include the name of the user in the EAP-Response/Identity so it meets the requirements of those other candidate EAP methods 💅
7.4. Piggybacking 🥞
Describing EAP-TTLS messaging as two phases is super convenient, but sometimes a single EAP-TTLS packet has to carry both phase 1 and phase 2 TLS messages 🫶
This is called "piggybacking," and it happens when the party that finishes the handshake also has AVPs to send. For example, when a resumed TLS session is being negotiated, the TTLS server sends its ChangeCipherSpec and Finished messages first. Then the client sends its own ChangeCipherSpec and Finished messages to wrap up the handshake ✨. If the client has authentication or other AVPs for the TTLS server, it MUST tunnel those AVPs in the same EAP-TTLS packet, right after its Finished message. If it doesn't, the TTLS server will wrongly assume the client has nothing to send, and the outcome of the negotiation could get messed up 😭
7.5. Session Resumption 🔁
When a client and TTLS server that already negotiated an EAP-TTLS session start a new one, they MAY agree to resume the previous session. This saves a ton of time setting up the new session ⚡ It can happen when the client connects to a new access point, or when an access point wants a connected client to reauthenticate 💜
Session resumption uses the standard TLS mechanism. The client says it wants to resume by putting the session ID of the session it wants in its ClientHello message. The TTLS server says "yep, I'm down" by echoing that same session ID back in its ServerHello message 🌸
If the TTLS server doesn't want to resume, it just doesn't echo the session ID, and a brand new session gets negotiated instead. That might happen if the TTLS server is set not to resume sessions, if it doesn't have the state for the requested session anymore, or if the session is considered stale 🥀 A TTLS server may decide a session is stale based on its own configuration, or based on session-limiting info it got from the AAA/H (for example, the RADIUS Session-Timeout attribute) ⏰
Tunneled authentication is specifically NOT done for resumed sessions 🙅 The idea is that knowing the master secret (which is proven by being able to resume the session) already counts as authentication enough. That's why session resumption can happen without any messaging between the TTLS server and the AAA/H ✨ If periodic reauthentication to the AAA/H is wanted, the AAA/H must tell the TTLS server about it when the original session is set up. For example, it can use the RADIUS Session-Timeout attribute to do that 🧚
The client MAY send other AVPs in its first phase 2 message of a session resumption, to kick off non-authentication functions. If it doesn't, the TTLS server, if it wants, MAY send AVPs to the client to start non-authentication functions, or MAY simply complete the EAP-TTLS negotiation and tell the encapsulating EAP protocol whether it was a success or a failure 💅
The TTLS server MUST keep the authorization info the AAA/H returned, so it can be used in resumed sessions. A resumed session MUST run under the same authorizations as the original session, and the TTLS server has to be ready to send the right info back to the access point. Authorization info might include the maximum session time, the maximum allowed bandwidth, packet filter info, and stuff like that. The TTLS server is responsible for changing time values, like Session-Timeout, correctly for each resumed session 🕰️
A TTLS server MUST NOT let a session be resumed if that session didn't result in a successful authentication of the user during phase 2. Getting this wrong would be CATASTROPHIC 💀 Any attacker could easily get network access by starting a session that succeeds in the TLS handshake but fails phase 2 authentication, and then resuming that session.
[Implementation note: Toolkits that implement TLS often cache resumable TLS sessions automatically. Implementers must take care to override such automatic behavior, and prevent sessions from being cached for possible resumption until the user has been positively authenticated during phase 2.] 🙈
7.6. Determining Whether to Enter Phase 2 🚪
Entering phase 2 is optional, and either the client or the TTLS server can start it. If no further authentication or info exchange is needed once phase 1 is done, the EAP-TTLS negotiation can totally finish without ever entering phase 2 or tunneling any AVPs 🎉
Phase 2 is never entered in these situations:
- Successful session resumption, with no additional info exchange needed,
- Authentication of the client via client certificate during phase 1, with no additional authentication or info exchange needed.
The client always gets the first chance to start phase 2 once phase 1 is done. If the client has no AVPs to send, it either sends an Acknowledgement (see Section 9.2.3) if the TTLS server sent the final phase 1 message, or it just doesn't piggyback a phase 2 message when it sends the final phase 1 message (which is what happens during session resumption) 🫶
If the client doesn't start phase 2, the TTLS server can, if it wants, either finish the EAP-TTLS negotiation without entering phase 2, or start phase 2 by tunneling AVPs to the client 🌈
Here's an example. Say a successful session resumption happens in phase 1. These sequences are possible:
- Neither the client nor the TTLS server has more info to swap. The client finishes phase 1 without piggybacking phase 2 AVPs, and the TTLS server signals success to the encapsulating EAP protocol without entering phase 2 ✅
- The client has no more info to swap, but the TTLS server does. The client finishes phase 1 without piggybacking phase 2 AVPs, but the TTLS server keeps the EAP-TTLS negotiation going into phase 2 by tunneling AVPs in its next EAP-TTLS message 🧚
- The client has more info to swap, and it piggybacks phase 2 AVPs with its final phase 1 message, which pushes the negotiation into phase 2 🔥
7.7. TLS Version 🔐
TLS version 1.0 [RFC2246], 1.1 [RFC4346], or any later version MAY be used within EAP-TTLS. TLS has its own version negotiation mechanism built in, so that's handled ✨
For maximum interoperability, EAP-TTLS implementations SHOULD support TLS version 1.0 💖
7.8. Use of TLS PRF 🧁
EAP-TTLSv0 uses a pseudo-random function (PRF) to generate keying material (Section 8) and to generate implicit challenge material for certain authentication methods (Section 11.1). The PRF used in these computations is the TLS PRF from the TLS handshake negotiation that kicks off the EAP-TTLS exchange 🌸
TLS versions 1.0 [RFC2246] and 1.1 [RFC4346] define the same PRF function, so any EAP-TTLSv0 implementation based on those versions of TLS must use the PRF defined there. It's expected that future versions of, or extensions to, the TLS protocol will let alternative PRF functions get negotiated. If an alternative PRF function is specified for the underlying TLS version, or has been negotiated during the TLS handshake negotiation, then that alternative PRF function must be used in EAP-TTLSv0 computations instead of the TLS 1.0/1.1 PRF 👑
The TLS PRF function used in this specification is written like this:
PRF-nn(secret, label, seed)where:
nn is the number of generated octets
secret is a secret key
label is a string (without null-terminator)
seed is a binary sequence.The TLS 1.0/1.1 PRF has invariant output no matter how many octets get generated. However, alternative PRF functions might include the size of the output sequence as input to the PRF function. That means generating 32 octets and generating 64 octets from the same input parameters won't give you identical first 32 octets anymore 🙈 For this reason, the PRF is always specified with an "nn", which shows the number of generated octets 🫶
8. Generating Keying Material 🔑
Once an EAP-TTLS negotiation wraps up successfully, 128 octets of keying material are generated and exported, so the data connection between client and access point can be secured 🔒 The first 64 octets of the keying material are the MSK, and the second 64 octets are the EMSK 💜
The keying material is generated with the TLS PRF function [RFC4346]. The inputs are the TLS master secret, the ASCII-encoded constant string "ttls keying material", the TLS client random, and the TLS server random. The constant string is not null-terminated ✨
Keying Material = PRF-128(SecurityParameters.master_secret, "ttls
keying material", SecurityParameters.client_random +
SecurityParameters.server_random)
MSK = Keying Material [0..63]
EMSK = Keying Material [64..127]Note that the order of client_random and server_random for EAP-TTLS is reversed from the TLS protocol's order [RFC4346]. This ordering follows the key derivation method of EAP-TLS [RFC5216]. Flipping the order of the randoms avoids namespace collisions between constant strings defined for EAP-TTLS and the ones defined for the TLS protocol 🦋
The TTLS server passes this keying material to the access point through the AAA carrier protocol. When RADIUS is the AAA carrier protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes [RFC2548] may be used to hand over the first 32 octets and the second 32 octets of the MSK, respectively 🌈
9. EAP-TTLS Protocol 🦋
9.1. Packet Format ✨
okay so here's the EAP-TTLS packet layout 🎀 everything gets sent left to right, bestie, so read it in that order 💅
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 | Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Length | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code🦋 It's1for a request and2for a response. Simple and iconic.Identifier🧚 This one's a single octet and it's how responses get matched up with their requests, so the vibes stay connected 🫶 TheIdentifierMUST be changed for each request packet, and it MUST be echoed in each response packet. No lazy copy-paste, periodt 💅Length📏 Two octets, and it counts the whole EAP packet, from theCodefield all the way through theDatafield.Type🌈 It's21, which means EAP-TTLS. We stan.Flags🚩 This is the part where it gets spicy. The flags look like this:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| L | M | S | R | R | V |
+---+---+---+---+---+---+---+---+L means Length included, M means More fragments, S means Start, R is Reserved, and V is the Version (000 for EAP-TTLSv0). So the L bit is set to say the four-octet TLS Message Length field is there 🍓 The M bit says more fragments are coming. The S bit says it's a Start message. The V field holds the version of EAP-TTLS, and for EAP-TTLSv0 it's 000 ✨
Message Length🧮 This is four octets, and it only shows up if the L bit is set. It gives the total length of the raw data message sequence before any fragmentation happens.Data💜 For every packet except a Start packet, theDatafield holds the raw TLS message sequence, or a fragment of it. For a Start packet, theDatafield may optionally contain an AVP sequence.
9.2. EAP-TTLS Start Packet 🌸
okay this is the packet that kicks the whole EAP-TTLS party off 🎉 The S bit MUST be set on the first packet the server sends to start the protocol. It MUST NOT be set on any other packet, so don't go sprinkling it everywhere 😭
This packet MAY contain extra info in the form of AVPs, and that can be super helpful hints for the client 💖 For example, the server identity can help the client pick the right TLS session ID for session resumption. Each AVP must begin on a four-octet boundary, counted from the first AVP in the sequence. If an AVP isn't a multiple of four octets, it must be padded with zeros up to the next four-octet boundary 🧸
9.2.1. Version Negotiation 👑
the version gets negotiated in the very first exchange between server and client, and it's giving handshake energy 🤝 The server puts the highest EAP-TTLS version number it supports in the V field of its Start message (for EAP-TTLSv0, that's 0). Then, in its first EAP response, the client sets the V field to the highest version it supports that's no higher than what the server offered. If the server doesn't accept the client's version, the client sends an EAP-Failure to end the EAP session 💀 Otherwise, the version the client sent is the version of EAP-TTLS that MUST be used, and both server and client MUST set the V field to that version number in all subsequent EAP messages. Main character energy 👑
9.2.2. Fragmentation 🧩
each EAP-TTLS message is one leg of a half-duplex conversation, meaning one side talks and then the other side talks 🗣️ The EAP carrier protocol (like PPP, EAPOL, or RADIUS) might put limits on how long an EAP message can be. So sometimes an EAP-TTLS message has to get chopped up across multiple EAP messages 🔪
Each fragment except the last one MUST have the M bit set, to say more data is coming. The final fragment MUST NOT have the M bit set 🏁
If there are multiple fragments, the first fragment MUST have the L bit set, and it has to include the length of the entire raw message before fragmentation. Fragments other than the first MUST NOT have the L bit set. Unfragmented messages MAY have the L bit set and include the message length, though that info is kinda redundant 🙈
Whenever a packet with the M bit set comes in, the receiver MUST transmit an Acknowledgement packet. The receiver is also the one in charge of putting fragmented packets back together 🫶
9.2.3. Acknowledgement Packets 🦋
an Acknowledgement packet is an EAP-TTLS packet with no extra data beyond the Flags octet, and the L, M, and S bits of that Flags octet are all set to 0. (But note, the V field MUST still be set to the correct version number, so don't forget it 💅)
Acknowledgement packets get sent for these reasons:
- A Fragment Acknowledgement goes out in response to an EAP packet that has the M bit set.
- When the TTLS server sends the final EAP packet of the EAP-TTLS negotiation, the client must respond with an Acknowledgement packet. This lets the TTLS server carry on with EAP once EAP-TTLS is done, which usually means sending a final EAP-Success or EAP-Failure to the client (or causing one to be sent) 🎀
10. Encapsulation of AVPs within the TLS Record Layer ✨
okay so once the TLS handshake is done, info can get tunneled between the client and the TTLS server using attribute-value pairs (AVPs) that are encrypted inside the TLS record layer 🔐 It's giving secret-passing-notes energy 🤫
The AVP format picked for EAP-TTLS is compatible with the Diameter AVP format. That does NOT mean every device or server in an EAP-TTLS negotiation has to support Diameter 🙅♀️ Using this format is just a convenience. Diameter is a superset of RADIUS and includes the RADIUS attribute namespace by definition. It doesn't limit the size of an AVP the way RADIUS does, though. RADIUS is a widely deployed AAA protocol, and attribute definitions exist for all the commonly used password authentication protocols, EAP included 🍓
So, Diameter isn't normative here unless this document says so. Specifically, the way the Data field of an AVP is represented in EAP-TTLS is identical to Diameter's 💖
Using the RADIUS/Diameter namespace makes it easy for a TTLS server to translate between the AVPs it uses to talk to clients and the protocol needs of the widely deployed AAA servers 🧚 Plus, it gives vendors a well-understood way to extend that namespace for their own needs ✨
The AVP Codes in EAP-TTLS are expected to carry roughly the same meaning they do in Diameter and, by extension, RADIUS. But even though EAP-TTLS uses the same AVP Codes and syntax as Diameter, the semantics might differ, and most Diameter AVPs have no well-defined semantics in EAP-TTLS 🙈 There's a separate "EAP-TTLS AVP Usage" registry that lists which AVPs can be used within EAP-TTLS and what they mean in this context (see Section 16 for details) 📚
A TTLS server that copies AVPs between an EAP-TTLS exchange and a Diameter or RADIUS exchange with a backend MUST NOT make assumptions about AVPs whose usage it doesn't understand, in either EAP-TTLS or the backend protocol. Therefore, a TTLS server MUST NOT copy an AVP between an EAP-TTLS exchange and a Diameter or RADIUS exchange unless the semantics of that AVP are understood and defined in both contexts. Not me copying things I don't understand 💀
10.1. AVP Format ✨
the AVP layout is shown below. Everything is in network, or big-endian, order, which means the most significant octet comes first 🧠
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+AVP Code 🔢 The AVP Code is four octets. Combined with the Vendor-ID field (if it's there), it identifies the attribute uniquely. The first 256 AVP numbers are attributes defined in RADIUS [RFC2865]. AVP numbers 256 and up are defined in Diameter [RFC3588].
AVP Flags 🚩 The AVP Flags field is one octet, and it gives the receiver the info it needs to interpret the AVP.
The 'V' (Vendor-Specific) bit says whether the optional Vendor-ID field is present. When it's set to 1, the Vendor-ID field is there, and the AVP Code gets interpreted according to the namespace of the vendor named in the Vendor-ID field 🏷️
The 'M' (Mandatory) bit says whether the receiver has to support the AVP. If this bit is set to 0, the AVP may be safely ignored if the receiving party doesn't understand or support it, so no drama 🫠 If it's set to 1, the receiving party MUST fail the negotiation if it doesn't understand the AVP. For a TTLS server, that means returning EAP-Failure. For a client, it means abandoning the negotiation 😭
The 'r' (reserved) bits are unused. They MUST be set to 0 by the sender, and they MUST be ignored by the receiver 🤫
AVP Length 📏 The AVP Length field is three octets, and it gives the length of this AVP, counting the AVP Code, AVP Length, AVP Flags, Vendor-ID (if present), and Data.
Vendor-ID 🏭 The Vendor-ID field is only there if the V bit is set in the AVP Flags field. It's four octets, and it holds the vendor's IANA-assigned "SMI Network Management Private Enterprise Codes" [RFC3232] value. Vendors who define their own AVPs must keep a consistent namespace for those AVPs across RADIUS, Diameter, and EAP-TTLS 💜
A Vendor-ID value of zero is the same as the Vendor-ID field not being there at all 🙃
Also, the M bit is what lets EAP-TTLS grow new features while keeping backward compatibility when that's wanted 🦄 By setting the M bit of the right AVP(s) to 0 or 1, the party starting the function is saying whether support from the other side is optional or required 🎀
10.2. AVP Sequences 🧸
Data encapsulated within the TLS record layer must consist entirely of a sequence of zero or more AVPs. Each AVP must begin on a four-octet boundary, counted from the first AVP in the sequence. If an AVP isn't a multiple of four octets, it must be padded with zeros up to the next four-octet boundary 🌈
Note that the AVP Length does not include the padding 💅
10.3. Guidelines for Maximum Compatibility with AAA Servers 🎀
okay so if you want your AVPs to get along with AAA servers, here are the vibes to follow for maximum compatibility 💅
- Non-vendor-specific AVPs intended for use with AAA servers should be selected from the set of attributes defined for RADIUS; that is, attributes with codes less than 256. This provides compatibility with both RADIUS and Diameter. ✨
- Vendor-specific AVPs intended for use with AAA servers should be defined in terms of RADIUS. Vendor-specific RADIUS attributes translate to Diameter (and, hence, to EAP-TTLS) automatically; the reverse is not true. RADIUS vendor-specific attributes use RADIUS attribute 26 and include Vendor-ID, vendor-specific attribute code, and length; see [RFC2865] for details. 🌸
11. Tunneled Authentication 🦋
EAP-TTLS lets user authentication info ride inside the TLS record layer between the client and the TTLS server, so it stays safe from both active and passive attacks on that link 🔐 The TTLS server decrypts it and forwards it to the AAA/H over the AAA carrier protocol. iykyk, it's giving secure tunnel 🫶
Literally any type of password or other authentication can be tunneled. You can also do multiple tunneled authentications, which is so iconic 👑 Normally, tunneled authentication is used when the client hasn't been issued a certificate and the TLS handshake only gives one-way authentication of the TTLS server to the client. BUT, in certain cases you might want certificate authentication of the client during the TLS handshake too, plus tunneled user authentication afterwards 💜
11.1. Implicit Challenge 🧚
Some authentication protocols use a challenge/response mechanism, and the challenge material is not generated by the authentication server. So that material needs special handling, no cap 🍓
In CHAP, MS-CHAP, and MS-CHAP-V2, for example, the access point issues a challenge to the client. The client then hashes the challenge with the password and sends the response back to the access point. The access point then forwards both the challenge and the response to a AAA server. But because the AAA server did not generate the challenge itself, these protocols are susceptible to replay attack 😭
If the client were able to create both challenge and response, anyone who could observe a CHAP or MS-CHAP exchange could pose as that user, even when using EAP-TTLS. Not me getting impersonated 💀
To make these protocols secure under EAP-TTLS, you need a mechanism that produces a challenge the client cannot control or predict. This is done with the same technique described above for generating data connection keying material ✨
When a challenge-based authentication mechanism is used, both the client and the TTLS server use the pseudo-random function to generate as many octets as are required for the challenge. They use the constant string "ttls challenge", based on the master secret and random values established during the handshake:
EAP-TTLS_challenge = PRF-nn(SecurityParameters.master_secret,
"ttls challenge",
SecurityParameters.client_random +
SecurityParameters.server_random);The number of octets to be generated (nn) depends on the authentication method, and it's listed below for each authentication method that needs implicit challenge generation 🌈
11.2. Tunneled Authentication Protocols 💖
This section covers how to tunnel specific authentication protocols within EAP-TTLS 🎀
For the sake of explanation, it's assumed that the TTLS server and AAA/H use RADIUS as the AAA carrier protocol between them. However, this is not a requirement, and any AAA protocol that can carry the required information may be used 🫶
The client decides which authentication protocol gets used through the initial AVPs it sends to the server, as described in the following sections ✨
Heads up: some of the authentication protocols below use vendor-specific AVPs that were originally defined for RADIUS. RADIUS and Diameter encode vendor-specific AVPs differently. RADIUS uses the vendor-specific attribute (code 26), while Diameter uses the V bit to signal that a Vendor-ID is present. The RADIUS form of the vendor-specific attribute can always be converted into a Diameter AVP with the V bit set. All vendor-specific AVPs described below MUST be encoded using the preferred Diameter V bit mechanism. In other words, AVP Code of 26 MUST NOT be used to encode vendor-specific AVPs within EAP-TTLS 🚨
⚠️ Vendor-specific AVPs in EAP-TTLS use the Diameter V bit, not the RADIUS code 26 form. No exceptions, bestie.
11.2.1. EAP 🌸
When EAP is the tunneled authentication protocol, each tunneled EAP packet between the client and the TTLS server gets wrapped in an EAP-Message AVP before it's tunneled through the TLS record layer 🎁
Diameter AVPs aren't limited to 253 octets of data the way RADIUS attributes are, so the RADIUS trick of concatenating multiple EAP-Message attributes to carry an EAP packet longer than 253 octets isn't appropriate in EAP-TTLS. Instead, a tunneled EAP packet within a single EAP-TTLS message MUST be contained in a single EAP-Message AVP 💅
The client starts EAP by tunneling EAP-Response/Identity to the TTLS server. Depending on what the inner method requires, the client MAY now put the actual username in this packet, and the privacy of the user's identity is guaranteed by TLS encryption. This username is typically a Network Access Identifier (NAI) [RFC4282], which usually looks like this:
username@realmThe @realm part is optional and lets the TTLS server forward the EAP packet to the right AAA/H 🦋
Also, the client gets two chances to specify realms 👑 The first is in the initial, untunneled EAP-Response/Identity packet sent before EAP-TTLS starts, and it tells you the realm of the TTLS server. The second happens during the EAP exchange inside the EAP-TTLS tunnel, and it tells you the realm of the client's home network. So the access point only needs to know how to route to the TTLS server's realm, and the TTLS server is assumed to know how to route to the client's home realm. This serial routing setup is expected to be super useful in roaming environments, since access points or AAA proxies behind them can be configured with just a small number of realms 🌍 (Check out Section 7.3 for more on telling the untunneled and tunneled versions of EAP-Response/Identity packets apart.)
TTLS handling of the initial identity exchange is different from plain EAP, and the TTLS state machine is different too 🧚 Still, the server side is expected to handle client initiation just fine, since even normal EAP runs are client-initiated over AAA. On the client side there are a few implementation techniques for dealing with the differences. Even a TTLS-unaware EAP method could be used, as long as TTLS makes it look like an EAP-Request/Identity message was actually received. That's similar to what authenticators do when they sit between a client and a AAA server 🫶
When the TTLS server gets the tunneled EAP-Response/Identity, it forwards it to the AAA/H in a RADIUS Access-Request 📨
The AAA/H might immediately respond with an Access-Reject. If so, the TTLS server wraps things up by sending an EAP-Failure to the access point 😭 This could happen if the AAA/H doesn't recognize the user's identity or doesn't support EAP.
If the AAA/H does recognize the user's identity and supports EAP, it responds with an Access-Challenge containing an EAP-Request. The Type and Type-Data fields are set according to the EAP protocol the AAA/H wants to use to authenticate the client, such as MD5-Challenge, One-Time Password (OTP), or Generic Token Card 🔑
The EAP authentication between the client and AAA/H carries on as normal, as described in [RFC3748], with the TTLS server acting as a passthrough device. Each EAP-Request the AAA/H sends in an Access-Challenge gets tunneled by the TTLS server to the client. Each EAP-Response the client tunnels gets decrypted and forwarded by the TTLS server to the AAA/H in an Access-Request 💖
This keeps going until the AAA/H issues an Access-Accept or Access-Reject 🎉
EAP-TTLS doesn't impose any special rules on EAP Notification packets, so they MAY be used within a tunneled EAP exchange according to the rules in [RFC3748] 📣
EAP-TTLS gives you a reliable transport for the tunneled EAP exchange. But [RFC3748] assumes an unreliable transport for EAP messages (see Section 3.1), and it provides for silent discard of any EAP packet that violates the protocol or fails a method-specific integrity check. The idea is that such a packet is probably a counterfeit sent by an attacker. But since the tunnel is a reliable transport for the inner EAP authentication, errors that would cause a silent discard under [RFC3748] presumably represent implementation errors when they happen inside the tunnel. They SHOULD be treated that way instead of being silently discarded 🙈 Honestly, silently discarding an EAP message inside the tunnel just halts the exchange and leads to long timeouts in cases that should fail immediately 😩
11.2.2. CHAP 🍓
The CHAP algorithm is described in [RFC1661], and RADIUS attribute formats are described in [RFC2865] 📖
Both the client and the TTLS server generate 17 octets of challenge material, using the constant string "ttls challenge" as described above. Those octets get used like this:
CHAP-Challenge [16 octets]
CHAP Identifier [1 octet]The client starts CHAP by tunneling User-Name, CHAP-Challenge, and CHAP-Password AVPs to the TTLS server. The CHAP-Challenge value comes from the challenge material. The CHAP-Password is made of the CHAP Identifier, taken from the challenge material, and the CHAP response, computed according to the CHAP algorithm 🎀
When the TTLS server receives these AVPs from the client, it must verify that the value of the CHAP-Challenge AVP and the value of the CHAP Identifier in the CHAP-Password AVP are equal to the values generated as challenge material. If either item doesn't match exactly, the TTLS server must reject the client 🙅♀️ Otherwise, it forwards the AVPs to the AAA/H in an Access-Request ✨
The AAA/H will respond with an Access-Accept or Access-Reject 💜
11.2.3. MS-CHAP ✨
okay so MS-CHAP is described in [RFC2433], and the RADIUS attribute formats are in [RFC2548] 💅
both the client and the TTLS server generate 9 octets of challenge material using the constant string "ttls challenge" (see above) 🎀 those octets get split up like this:
MS-CHAP-Challenge [8 octets]
Ident [1 octet]the client starts MS-CHAP by tunneling the User-Name, MS-CHAP-Challenge and MS-CHAP-Response AVPs to the TTLS server 📦 the MS-CHAP-Challenge value comes from the challenge material. the MS-CHAP-Response is made of Ident (from the challenge material), Flags (set according to the client preferences), and LM-Response and NT-Response (computed with the MS-CHAP algorithm) 🧚
once the TTLS server gets these AVPs, it MUST verify that the MS-CHAP-Challenge value and the Ident in the client's MS-CHAP-Response are equal to the values it generated as challenge material 🔍 if either one doesn't match exactly, the TTLS server MUST reject the client 🙅 otherwise, it forwards the AVPs to the AAA/H in an Access-Request 💌
the AAA/H will reply with an Access-Accept or an Access-Reject ✨
11.2.4. MS-CHAP-V2 💜
the MS-CHAP-V2 algorithm is described in [RFC2759], and the RADIUS attribute formats are in [RFC2548] 🦋
again, both client and TTLS server generate 17 octets of challenge material using the constant string "ttls challenge" (see above) 🌸 those get used like so:
MS-CHAP-Challenge [16 octets]
Ident [1 octet]the client kicks off MS-CHAP-V2 by tunneling the User-Name, MS-CHAP-Challenge, and MS2-Response AVPs... well, MS-CHAP2-Response AVPs to the TTLS server 🫶 the MS-CHAP-Challenge value is taken from the challenge material. the MS-CHAP2-Response consists of Ident (from the challenge material), Flags (set to 0), Peer-Challenge (set to a random value), and Response (computed with the MS-CHAP-V2 algorithm) 🎲
the TTLS server MUST verify that the MS-CHAP-Challenge value and the Ident in the client's MS-CHAP2-Response are equal to the values it generated as challenge material 👀 if either one doesn't match exactly, the TTLS server MUST reject the client 💀 otherwise it forwards the AVPs to the AAA/H in an Access-Request 📨
if the authentication succeeds, the AAA/H responds with an Access-Accept that contains the MS-CHAP2-Success attribute 🎉 this attribute is a 42-octet string that authenticates the AAA/H to the client based on the Peer-Challenge. the TTLS server tunnels this AVP to the client. ⚠️ heads up, the authentication is NOT done yet, bestie. the client still has to accept the AAA/H's authentication response 👑
the authentication isn't complete until the client accepts the AAA/H's response. don't skip this step!
once the client gets the MS-CHAP2-Success AVP, it can authenticate the AAA/H 🔐 if that works, the client sends an EAP-TTLS packet to the TTLS server with no data (aka a zero-length Data field) 📭 when the TTLS server gets that empty EAP-TTLS packet, it considers MS-CHAP-V2 authentication to have succeeded 🥳
if authentication fails, the AAA/H responds with an Access-Challenge containing the MS-CHAP-Error attribute 😬 this attribute holds a new Ident and a string with extra info like the error reason and whether a retry is allowed. the TTLS server tunnels this AVP to the client. if the error reason is an expired password and a retry is allowed, the client may go ahead and change the user's password 🔑 if the error reason is anything else, or the client doesn't want to change the password, it just abandons the EAP-TTLS negotiation 🚪
if the client does want to change the password, it tunnels the MS-CHAP-NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS server 🔄 the MS-CHAP2-CPW AVP is derived from the new Ident and Challenge received in the MS-CHAP-Error AVP. the MS-CHAP-Challenge AVP just echoes the new Challenge 🔁
the TTLS server MUST verify that the MS-CHAP-Challenge value and the Ident in the client's MS-CHAP2-CPW AVP match the values it sent in the MS-CHAP-Error AVP 🧐 if either one doesn't match exactly, the TTLS server MUST reject the client 🚫 otherwise it forwards the AVPs to the AAA/H in an Access-Request 🚀
if this one succeeds, the AAA/H responds with an Access-Accept containing the MS-CHAP2-Success attribute 🎊 at this point the negotiation goes back to what we covered above: the TTLS server tunnels the MS-CHAP2-Success to the client, and the client authenticates the AAA/H based on this AVP. then the client either abandons the negotiation on failure, or sends an EAP-TTLS packet with no data (a zero-length Data field), which makes the TTLS server consider MS-CHAP-V2 authentication to have succeeded 🌈
ps: the AAA/H may send additional AVPs associated with MS-CHAP-V2, like MS-CHAP-Domain 🧃 the TTLS server MUST tunnel these authentication-related attributes along with the MS-CHAP2-Success 🫧
11.2.5. PAP 🧁
the client starts PAP by tunneling the User-Name and User-Password AVPs to the TTLS server 🍓
normally in RADIUS, User-Password gets null-padded to a multiple of 16 octets and then encrypted using a shared secret and other packet info 🔒
an EAP-TTLS client doesn't RADIUS-encrypt the password, because those RADIUS variables just aren't available 🤷♀️ and that's totally fine, not a security weakness, since TLS encrypts the password anyway 🔐 the client SHOULD still null-pad the password to a multiple of 16 octets, though, to obfuscate its length 🙈
when the TTLS server gets these AVPs from the client, it forwards them to the AAA/H in a RADIUS Access-Request. (heads up: in that Access-Request, the TTLS server must encrypt the User-Password attribute using the shared secret between the TTLS server and the AAA/H 🗝️)
the AAA/H may immediately respond with an Access-Accept or Access-Reject ⚡ then the TTLS server wraps up the negotiation by sending an EAP-Success or EAP-Failure to the access point using the AAA carrier protocol 🎀
the AAA/H may also respond with an Access-Challenge 🧩 then the TTLS server tunnels the AVPs from that challenge to the client. when the client gets them, it tunnels User-Name and User-Password again, with User-Password holding new info in response to the challenge. this loop keeps going until the AAA/H sends an Access-Accept or Access-Reject 🔁
at least one of the AVPs tunneled to the client upon a challenge MUST be Reply-Message 💬 normally the AAA/H sends this as part of the challenge. but if the AAA/H didn't send a Reply-Message, the TTLS server MUST issue one, with a null value 🫳 that way the client knows a challenge response is needed 🙌
note that if the AAA/H includes a Reply-Message as part of an Access-Accept or Access-Reject, the TTLS server doesn't tunnel it to the client 🙅♀️ instead, that AVP and all other AVPs the AAA/H sends as part of an Access-Accept or Access-Reject get sent to the access point via the AAA carrier protocol 📬
11.3. Performing Multiple Authentications 🌈
sometimes you want to do multiple user authentications 🧠 for example, an AAA/H might want to authenticate the user by password first, and then by token card 🪙
the AAA/H can do any number of extra user authentications using EAP, just by issuing an EAP-Request with a new EAP type once the previous authentication finishes 🔄 note that each new EAP method is subject to negotiation, which means the client may answer an EAP request for a new EAP type with an EAP-Nak, as described in [RFC3748] 🙅♀️
for example, an AAA/H that wants to run an MD5-Challenge followed by Generic Token Card would first issue an EAP-Request/MD5-Challenge and get a response 🧁 if that response is satisfactory, it then issues an EAP-Request/Generic Token Card and gets a response. if that one is also satisfactory, it accepts the user ✅
the whole inner EAP exchange with multiple authentications counts as a single EAP sequence. that means each subsequent request MUST contain a distinct EAP Identifier from the previous request, even while one authentication wraps up and another begins 🆔
the peer identity from the original EAP-Response/Identity that started the EAP sequence is meant to apply to each of the sequential authentications 🪪 unless an application profile standard says otherwise, additional EAP-Identity exchanges SHOULD NOT happen 🙅
whether the overall thing counts as a success or failure when there are multiple authentications is a matter of policy on both client and server 📋 so either party can require that all inner authentications succeed, or that at least one of them succeeds, as the condition for overall success 🏆
each EAP method is meant to run to completion 🏁 if the TTLS server abandons a method and starts a new one, the client behaviour isn't defined in this document. it's up to client policy 🤷♀️
heads up: it isn't always possible to use the same EAP method twice in a row 🫣 if the EAP type doesn't change, it might be impossible to tell when the first authentication ends and the new one begins. some EAP methods, like EAP-TLS, use a Start bit to mark the first request, so each new authentication of that type can be told apart from the last one 🚩 other methods, like EAP-MS-CHAP-V2, end in a well-defined way, so a second authentication of the same type can start unambiguously 💫 using the same EAP method for multiple authentications is pretty unlikely, but implementers should know about the issues and avoid anything that would cause ambiguity ⚠️
using non-EAP methods, or mixing EAP and non-EAP methods, for multiple authentications isn't defined in this document, and it's not known whether anyone has implemented such an approach 🤔
11.4. Mandatory Tunneled Authentication Support 🔐
to make sure things interoperate, unless an application profile standard says otherwise, an implementation that complies with this specification MUST implement EAP as a tunneled authentication method, and MUST implement MD5-Challenge as an EAP type 💖 that said, such an implementation MAY let an administrator enable or disable EAP, any EAP type, or any other tunneled authentication method, on either the client or the TTLS server 🎛️
also, unless an application profile standard says otherwise, an implementation that complies with this specification MUST let an administrator configure tunneled authentication without the M (Mandatory) bit set on any AVP 🙌
11.5. Additional Suggested Tunneled Authentication Support 🍓
the following info is non-normative guidance, based on what the authors and reviewers of this spec learned from existing EAP-TTLSv0 implementations 📚
these authentication methods are commonly used, so servers that want broad interoperability across multiple media should consider implementing them 🫶
- PAP (both for password and token authentication) 🔑
- MS-CHAP-V2 💜
- EAP-MS-CHAP-V2 🦋
- EAP-GTC ✨
12. Keying Framework 🔑
okay so, [RFC5247] is the one that sets the rules here, and in that spirit we're defining three ID things: Session-Id, Peer-Id, and Server-Id. bestie, these are the keys to the whole keying vibe 🗝️✨
12.1. Session-Id 🆔
The Session-Id is how you tell one authentication exchange apart from another between the client and the TTLS server. It's built like this:
Session-Id = 0x15 || client.random || server.randomIt's giving unique fingerprint energy 🦋
12.2. Peer-Id 🎀
The Peer-Id is the identity used for access control and accounting. So if the client shows a certificate during the TLS handshake, the Peer-Id comes from the info inside that certificate, following Section 5.2 of [RFC5216] 📜. If there's no client certificate, the Peer-Id is null. No drama, just null 💅
12.3. Server-Id 🖥️
The Server-Id is how the TTLS server identifies itself. Same deal as the Peer-Id: if the TTLS server presents a certificate during the TLS handshake, the Server-Id is pulled from that certificate, per Section 5.2 of [RFC5216]. Otherwise? Null 🌸
13. AVP Summary 📋
okay, this table is the AVP cheat sheet 🧚 It lists every AVP in this document, whether it can show up in a server-to-client packet ("Request") and/or a client-to-server packet ("Response"), and whether it MUST be implemented ("MI"). Yes, the MUST is capitalized in the original, so it stays exactly like that 💜
Name Request Response MI
---------------------------------------------------
User-Name X
User-Password X
CHAP-Password X
Reply-Message X
CHAP-Challenge X
EAP-Message X X X
MS-CHAP-Response X
MS-CHAP-Error X
MS-CHAP-NT-Enc-PW X
MS-CHAP-Domain X
MS-CHAP-Challenge X
MS-CHAP2-Response X
MS-CHAP2-Success X
MS-CHAP2-CPW X14. Security Considerations 🛡️
bestie, this part is SERIOUS. Like, people's credentials are on the line 😭 Read every word, no skipping.
14.1. Security Claims 🔐
Per RFC 3748, here are the security claims for EAP-TTLSv0. Literally the whole report card:
Authentication mechanism: TLS plus arbitrary additional protected
authentication(s)
Ciphersuite negotiation: Yes
Mutual authentication: Yes, in recommended implementation
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes
Key strength: Up to 384 bits
Dictionary attack prot.: Yes
Fast reconnect: Yes
Cryptographic binding: No
Session independence: Yes
Fragmentation: Yes
Channel binding: No14.1.1. Authentication Mechanism 🎭
EAP-TTLSv0 uses negotiated underlying auth protocols, both in the phase 1 TLS handshake and the phase 2 tunneled authentication. In a typical setup, at minimum the TTLS server authenticates to the client in phase 1, and the client authenticates to the AAA/H server in phase 2. Phase 1 server auth is usually by certificate. The client may optionally authenticate to the TTLS server by certificate too. Phase 2 client auth to the AAA/H server is usually by password or security token, through EAP or a supported non-EAP mechanism. That mechanism can also authenticate the AAA/H server to the client, which gives you mutual authentication 🤝✨
14.1.2. Ciphersuite Negotiation 🧩
Ciphersuite negotiation is inherited from TLS. Easy, we don't have to redo it 💅
14.1.3. Mutual Authentication 🤝
In the recommended minimum configuration, the TTLS server gets authenticated to the client in phase 1, and then the client and AAA/H server mutually authenticate in phase 2. Both sides check each other 👀💖
14.1.4. Integrity Protection 🔒
Integrity protection is inherited from TLS. TLS got us covered 🫶
14.1.5. Replay Protection 🔁
Replay protection is inherited from TLS too. No replaying old messages, periodt 🙅♀️
14.1.6. Confidentiality 🤫
Confidentiality is inherited from TLS. BUT, and this is a big but 🚨, EAP-TTLSv0 has no provision for encrypting success or failure EAP packets. So keep that in mind.
14.1.7. Key Derivation 🗝️
Both MSK and EMSK are derived. The key derivation PRF is inherited from TLS, and how crypto-agile this is depends on the crypto-agility of the TLS PRF. Basically it's only as flexible as TLS 🌈
14.1.8. Key Strength 💪
Key strength is capped by the size of the TLS master secret, which is 48 octets (384 bits) for versions 1.0 and 1.1. The effective strength might be lower though, depending on how resistant the negotiated Diffie-Helman (DH) group, certificate RSA/DSA group, etc. are to attacks. BCP 86 [RFC3766], Section 5, has advice on the required RSA or DH module and DSA subgroup size in bits for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended for 128-bit equivalent key strength 🔑🔥 The National Institute for Standards and Technology (NIST) also gives advice on key sizes in [SP800-57].
14.1.9. Dictionary Attack Protection 🛡️
Phase 2 password auth is protected against eavesdropping, and therefore against offline dictionary attacks, by TLS encryption. Shielded 🙈
14.1.10. Fast Reconnect ⚡
Fast reconnect comes from TLS session resumption. Quick and easy ✨
14.1.11. Cryptographic Binding 🕵️
Okay, this one is a bit spicy 🌶️ [MITM] describes a vulnerability typical of tunneled auth protocols. An attacker can authenticate as a client through a tunneled protocol by posing as an authenticator to a legitimate client using a non-tunneled protocol. If the same proof of credentials works in both authentications, the attacker just shuttles that proof between them. EAP-TTLSv0 is vulnerable to this. So be careful not to use the same auth protocols and associated credentials both as inner TTLSv0 methods and as untunneled methods 🚫
Extensions to EAP-TTLSv0, or a future version of EAP-TTLS, should be defined to cryptographically bind the keying material generated by inner auth methods to the keying material generated by the TLS handshake. That avoids the man-in-the-middle problem when you use key-generating inner methods. Such an extension mechanism has been proposed [TTLS-EXT] 💡
14.1.12. Session Independence 🧘
TLS guarantees session independence of its master secret, which is where the EAP-TTLSv0 MSK/EMSK comes from. Each session stands on its own 💜
14.1.13. Fragmentation 🧩
Provision is made for fragmenting lengthy EAP packets. Big messages get split up, no problem 📦
14.1.14. Channel Binding 🔗
Support for channel binding may be added later as a future extension, using appropriate AVPs. Maybe someday, bestie 🌱
14.2. Client Anonymity 🥷
Unlike other EAP methods, EAP-TTLS does NOT send a username in the clear in the initial EAP-Response/Identity. This is designed to support anonymity and location privacy from attackers eavesdropping on the network path between the client and the TTLS server. HOWEVER 😤, implementers should know that other factors, both inside EAP-TTLS and outside it, may still compromise a user's identity. For example, if a user authenticates with a certificate during phase 1, the subject name in that certificate may reveal who they are. Outside EAP-TTLS, the client's fixed MAC address (or, on wireless connections, the client's radio signature) may also give things away. Also, implementers should know that a user's identity is not hidden from the EAP-TTLS server, and it may be sent in the clear in AAA messages between the access point, the EAP-TTLS server, and the AAA/H server 🫣
Now, if a client authenticating with a certificate wants to shield its certificate (and so its identity) from eavesdroppers, it can use the technique in Section 2.1.4 ("Privacy") of [RFC5216]. The client sends an empty certificate list, and the TTLS server issues a ServerHello once the TLS handshake completes, to start a second, encrypted handshake. During that second handshake, the client sends its certificate list. Heads up though: for this to work, the client has to know in advance that the TTLS server supports it 🎭
14.3. Server Trust 🏰
The client establishes trust in the server through a server certificate conveyed during the TLS handshake. The client should have a way of figuring out which server identities are authorized to act as a TTLS server and can be trusted. It should also refuse to authenticate with servers it doesn't trust. If it goes ahead with a hostile server anyway, the inner authentication gets exposed to attack, e.g., an offline dictionary attack against the client password 🙅♀️😱
14.4. Certificate Validation 📜
When either the client or the server presents a certificate during the TLS handshake, it should include the entire certificate chain minus the root, so the other party can validate it 🔗
When either the client or the server receives a certificate during the TLS handshake, it should validate the certification path to a trusted root. If the sender didn't provide intermediate certificates, the receiver may use cached or pre-configured copies if it has them, or it may retrieve them from the Internet if that's feasible 🌐
Clients and servers should implement policies around the Extended Key Usage (EKU) extension [RFC5280] of the certificates they receive. This makes sure the other party's certificate is used for its purpose. Typically, a client EKU, when present, would be expected to include id-kp-clientAuth. A server EKU, when present, would be expected to include id-kp-serverAuth. And note: if the EKU extension is absent, or its value is anyExtendedKeyUsage, that means there's no constraint on the certificate's purpose 🎀
14.5. Certificate Compromise 🚨
Certificates should be checked for revocation, to cut down on imposture using compromised certificates 🙅♀️
Checking a server certificate against the most recent revocation list during authentication isn't always possible for a client, because it might not have network access until authentication is done. The Online Certificate Status Protocol (OCSP) [RFC2560] can help with this during the TLS handshake, as described in [RFC4366] 🦋
14.6. Forward Secrecy 🌙
With forward secrecy, revealing a secret doesn't compromise session keys that were negotiated earlier based on that secret. So when the TLS key exchange algorithm provides forward secrecy, if a TTLS server certificate's private key is eventually stolen or cracked, tunneled user password info stays secure as long as that certificate isn't in use anymore. Diffie-Hellman key exchange is an example of an algorithm that provides forward secrecy 💖 A forward secrecy algorithm should be considered if attacks against recorded auth or data sessions are seen as a significant threat ⏳
14.7. Negotiating-Down Attacks ⬇️
EAP-TTLS negotiates its own protocol version before the TLS tunnel exists, so it happens outside the security the tunnel gives. In principle, that makes it open to a negotiating-down attack. In this attack, an intermediary changes messages in transit so a lower version gets agreed on, with each party assuming the other doesn't support as high a version as it actually does 😬
The version of EAP-TTLS described in this document is 0, so it isn't subject to such an attack. However, any new version using a number higher than 0 should define a mechanism to guard against this. One possible mechanism is for the TTLS server to repeat the protocol version it proposed in an AVP within the tunnel. That AVP should be inserted with M bit clear, even when version 0 is agreed upon 🌈✨
15. Message Sequences ✨
okay so this section is where we get to SEE EAP-TTLS in action 🎀 it's a bunch of message sequences for different negotiation scenarios. they're not every possible scenario, just the main ones, so don't panic if your situation isn't here 💅
assumed setup: RADIUS is the AAA carrier protocol both between the access point and the TTLS server, AND between the TTLS server and AAA/H. so the access point is basically just relaying stuff, and it's not reading the tunneled bits 🔒
quick legend bc these diagrams get busy 🦋
- passthrough = EAP packets the access point forwards unchanged between client and TTLS server
- {} curly braces = AVPs securely tunneled inside the TLS record layer
?after an item = optional+after an item = can show up multiple times
15.1. Successful Authentication via Tunneled CHAP
this one is the classic: the client does one-way TLS auth of the TTLS server (only the server gets verified), and CHAP is the tunneled user auth mechanism 🧚
client access point TTLS server AAA/H
------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
{User-Name}
{CHAP-Challenge}
{CHAP-Password}
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
User-Name
CHAP-Challenge
CHAP-Password
-------------------->
RADIUS Access-Accept
<--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
EAP-Success
<--------------------so the user name, challenge, and password all ride inside the {} tunnel, and the AAA/H only sees them when the TTLS server forwards them over RADIUS 🌸
15.2. Successful Authentication via Tunneled EAP/MD5-Challenge
same vibe as 15.1, the TLS handshake is one-way (server only), but this time the tunneled user auth is EAP/MD5-Challenge instead of CHAP 💜
client access point TTLS server AAA/H
------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientKeyExchange
ChangeCipherSpec
Finished
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ChangeCipherSpec
Finished
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
{EAP-Response/Identity}
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Request:
EAP-Response/Identity
-------------------->
RADIUS Access-Challenge
EAP-Request/
MD5-Challenge
<--------------------
RADIUS Access-Challenge:
EAP-Request/TTLS:
{EAP-Request/MD5-Challenge}
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
{EAP-Response/MD5-Challenge}
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge
EAP-Response/
MD5-Challenge
-------------------->
RADIUS Access-Accept
<--------------------
RADIUS Access-Accept:
EAP-Success
<--------------------
EAP-Success
<--------------------notice how the inner EAP exchange (Identity, then MD5-Challenge) bounces between the TTLS server and the AAA/H over RADIUS, while the client only ever sees it wrapped up inside the tunnel 🦋
15.3. Successful Session Resumption
this is the glow-up one ✨ instead of doing the whole handshake again, the client and server pick up a previous TLS session. the session ID to resume goes out in the ClientHello, and the server says "yep, resuming that one" by sending the same session ID back in its ServerHello 🔥
client access point TTLS server AAA/H
------ ------------ ----------- -----
EAP-Request/Identity
<--------------------
EAP-Response/Identity
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS-Start
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ClientHello
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Challenge:
EAP-Request/TTLS:
ServerHello
ChangeCipherSpec
Finished
<--------------------
EAP-Request passthrough
<--------------------
EAP-Response/TTLS:
ChangeCipherSpec
Finished
-------------------->
RADIUS Access-Request:
EAP-Response passthrough
-------------------->
RADIUS Access-Accept:
EAP-Success
<--------------------
EAP-Success
<--------------------no Certificate or key exchange in this one, which is why it's so much quicker 💖
16. IANA Considerations 🌈
IANA gave the EAP-TTLS protocol the method type number 21 (decimal) 🍓 for new RADIUS and Diameter AVPs and AVP values, the rules are in [RFC2865] and [RFC3588], respectively. nothing else new gets registered in this document, it's giving minimalism 💅
Section 11 of this document explains how certain authentication mechanisms can run inside the secure EAP-TTLS tunnel. New mechanisms and other functions MAY also be performed inside that tunnel 🫶 BUT if an extension uses AVPs that aren't vendor-specific, its semantics must be specified in new RFCs. so yes, the same AVP can already exist for RADIUS or DIAMETER and STILL need its own TTLS-specific processing rules for each one 😭
here's the new registry: EAP-TTLS AVP Usage, managed by IANA 🎀 it lists every non-vendor-specific RADIUS/Diameter AVP used within EAP-TTLS, with a reference to the RFC or other document that defines what it means. the starting list is the AVPs in Section 13 of this document. the whole point is to stop the same AVP from causing confusion when it's used in different functional contexts 🔥 this registry doesn't assign any AVP numbers, those still come from the RADIUS and Diameter namespaces as described in [RFC2865] and [RFC3588]. only top-level AVPs (ones not inside Grouped AVPs) get registered. AVPs should be added to this registry through IETF Review as defined in [RFC5226] 🧚
17. Acknowledgements 💜
big thank you to Bernard Aboba, Jari Arkko, Lakshminath Dondeti, Stephen Hanna, Ryan Hurst, Avi Lior, and Gabriel Montenegro for their careful reviews and useful comments 🫶✨
18. References 🦋
18.1. Normative References
okay bestie, these are the docs this spec leans on so hard it can't function without them 🫶 here's the normative list, every single entry exactly as written:
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
2759, January 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is
Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[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.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.18.2. Informative References
these ones are the helpful background reads 📚 not strictly required, but super useful for context:
[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.
[802.11] 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, 2007.
[TTLS-EXT] Hanna, S. and P. Funk, "Key Agility Extensions for EAP-
TTLSv0", Work in Progress, September 2007.
[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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[MITM] Asokan, N., Niemi, V., and Nyberg, K., "Man-in-the-
Middle in Tunneled Authentication",
http://www.saunalahti.fi/~asokan/research/mitm.html,
Nokia Research Center, Finland, October 24, 2002.
[SP800-57] National Institute of Standards and Technology,
"Recommendation for Key Management", Special Publication
800-57, May 2006.Authors' Addresses
meet the people who wrote this 💜 here's how to reach them:
Paul Funk
43 Linnaean St.
Cambridge, MA 02138
EMail: PaulFunk@alum.mit.edu
Simon Blake-Wilson
SafeNet
Amstelveenseweg 88-90
1054XV, Amsterdam
The Netherlands
EMail: sblakewilson@nl.safenet-inc.comFull Copyright Statement
the legal bit, kept word for word 🎀
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 IP section, also verbatim ✨
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: rfc5281 2008-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms