RFC 2716
PPP EAP TLS Authentication Protocol
Okay bestie, welcome to RFC 2716! 🎀✨
Title Block 📄
- Title: PPP EAP TLS Authentication Protocol 💖
- RFC number: 2716
- Series: Network Working Group. The header literally says "Requests for Commments" 💀 (typo alert!)
- Authors: B. Aboba and D. Simon, both from Microsoft 👑
- Category: Experimental 🧪
- Date: October 1999 🍓
- Obsoletes / Updates: The title block doesn't list anything this RFC obsoletes or updates, so it stands on its own 🦋
Status of This Memo 🌸
Okay so this memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind, so don't treat it like one 🙈 The authors are literally asking for discussion and suggestions for improvement, which is very giving "help me make this better" energy 🫶 Distribution of this memo is unlimited, so share the tea 🍵
Copyright Notice 💅
Copyright (C) The Internet Society (1999). All Rights Reserved. Very official, very legal, very 1999 ✨
1. Abstract 🧚
Okay, the vibe here is that PPP (the Point-to-Point Protocol) is the standard way to carry multi-protocol datagrams across point-to-point links 🦋 PPP also comes with an extensible Link Control Protocol (LCP), which can negotiate authentication methods. It also has an Encryption Control Protocol (ECP) for negotiating data encryption, and a Compression Control Protocol (CCP) for negotiating compression methods. That's a whole squad of negotiators 💅
Then there's EAP, the Extensible Authentication Protocol. It's a PPP extension that adds support for extra authentication methods inside PPP, so it's basically the glow-up option 🌈
Transport Level Security (TLS) is the one that gives you mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. Main character energy 👑 This document explains how EAP-TLS, which supports fragmentation and reassembly, brings all those TLS mechanisms into EAP. Literally the whole point 😭
2. Introduction 💖
So EAP is described in [5], and it gives PPP a standard way to add more authentication methods. With EAP you can plug in smart cards, Kerberos, Public Key, One Time Passwords, and more 🔥 The catch is that EAP methods like [6] have mostly focused on authenticating a client to a server. One-directional, not very fair 🙄
But here's the thing: sometimes you want mutual authentication, where both sides prove who they are. Also, PPP encryption protocols like [9] and [10] assume there's already a session key floating around. So a mechanism for session key establishment is super useful ✨ Designing secure key management protocols is genuinely hard (like, non-trivial hard 💀), so it's smart to avoid inventing new ones from scratch. The EAP protocol in this document lets a PPP peer use TLS for protected ciphersuite negotiation, mutual authentication, and key management, all of which are described in [12]. Borrowing the good stuff, iykyk 🫶
2.1. Requirements language 🎀
Okay, the key words here are the BCP 14 ones. In this document, MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT are to be interpreted as described in [11]. The words "optional" and "recommended" are also used, in lowercase, and they just mean what they say 🦋
3. Protocol overview 🧚♀️
to be continued in part 2! 💜
3.1. Overview of the EAP-TLS conversation ✨
Okay so bestie, as described in [5], the EAP-TLS conversation typically kicks off with the authenticator and the peer negotiating EAP 💅. The authenticator usually sends an EAP-Request/Identity packet to the peer, and the peer replies with an EAP-Response/Identity packet containing the peer's userId 🎀.
From here it gets a little plot twist 😭. Nominally the EAP conversation happens between the PPP authenticator and the peer, but the authenticator MAY act as a passthrough device. It encapsulates the EAP packets it gets from the peer and forwards them to a RADIUS server or backend security server. In this section, we'll call the ultimate endpoint talking to the peer the "EAP server" 👑.
Once the EAP server has the peer's Identity, it MUST respond with an EAP-TLS/Start packet. That's an EAP-Request packet with EAP-Type=EAP-TLS, the Start (S) bit set, and no data 🦋. Then the EAP-TLS conversation begins, and the peer sends an EAP-Response packet with EAP-Type=EAP-TLS. The data field of that packet holds one or more TLS records in TLS record layer format, and those records contain a TLS client_hello handshake message 🌸. Until the change_cipher_spec message comes along, the current cipher spec for the TLS records is TLS_NULL_WITH_NULL_NULL with null compression. Once change_cipher_spec arrives, the subsequent records use the negotiated attributes for the rest of the handshake ✨.
The client_hello message carries the client's TLS version number, a sessionId, a random number, and a set of ciphersuites the client supports. The version the client offers MUST correspond to TLS v1.0 or later 🌈.
The EAP server then replies with an EAP-Request packet with EAP-Type=EAP-TLS. The data field of this packet holds one or more TLS records. These contain a TLS server_hello handshake message, possibly followed by TLS certificate, server_key_exchange, certificate_request, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message 🍓. The server_hello message carries a TLS version number, another random number, a sessionId, and a ciphersuite. The version the server offers MUST correspond to TLS v1.0 or later 💜.
Now for the session stuff 🧚. If the client's sessionId is null or unrecognized by the server, the server MUST choose the sessionId to set up a new session. Otherwise, the sessionId matches the one the client offered, which means the previously established session with that sessionID is being resumed 🔁. The server also picks a ciphersuite from the ones the client offered. If the session matches the client's, then the ciphersuite MUST match the one negotiated during the handshake that originally established the session 🔥.
The whole point of the sessionId in TLS is efficiency. It helps when a client keeps trying to authenticate to an EAP server within a short window. This model was built for HTTP authentication, but it could also be useful for PPP authentication (e.g. multilink) 🙈.
So the peer gets to decide whether to try continuing a previous session, which shortens the TLS conversation. Usually that call is based on how much time has passed since the last authentication attempt to that EAP server ⏰. Then the EAP server looks at the sessionId the peer picked, plus the time since the last authentication, and decides whether to allow the continuation or start a new session.
Heads up: when the EAP server and the authenticator live on the same device, the client can only continue sessions when it connects to that same NAS or tunnel server. If those devices are set up in a rotary or round-robin, the peer might not know ahead of time which authenticator it'll land on, and so which sessionId to try reusing. That means the continuation attempt will probably fail. When the EAP authentication is remoted, though, continuation is much more likely to work, because multiple NAS devices and tunnel servers send their EAP authentications to the same RADIUS server 💀.
If the EAP server is resuming a previously established session, it MUST include only a TLS change_cipher_spec message and a TLS finished handshake message after the server_hello message. That finished message carries the EAP server's authentication response to the peer 🫶. If the EAP server is not resuming a session, it MUST include a TLS server_certificate handshake message, and a server_hello_done handshake message MUST be the last handshake message encapsulated in this EAP-Request packet 📜.
The certificate message holds a public key certificate chain for either a key exchange public key (like an RSA or Diffie-Hellman key exchange public key) or a signature public key (like an RSA or DSS signature public key). In the signature case, a TLS server_key_exchange handshake message MUST also be included so the key exchange can happen 🔑.
The certificate_request message shows up when the server wants the client to authenticate itself with a public key. The EAP server SHOULD require client authentication, but it isn't a hard requirement, since the server might require the peer to authenticate some other way 🤷♀️.
The peer MUST respond to the EAP-Request with an EAP-Response packet of EAP-Type=EAP-TLS. The data field of this packet holds one or more TLS records with a TLS change_cipher_spec message and finished handshake message, and possibly certificate, certificate_verify and/or client_key_exchange handshake messages 💖. If the server_hello the EAP server sent in the previous EAP-Request packet indicated a resumed session, the peer MUST send only the change_cipher_spec and finished handshake messages. That finished message carries the peer's authentication response to the EAP server 🦋.
If that server_hello did NOT indicate a resumed session, then along with the change_cipher_spec and finished messages, the peer MUST send a client_key_exchange message. That message completes the exchange of a shared master secret between the peer and the EAP server 🎀. If the EAP server sent a certificate_request in the previous EAP-Request packet, the peer MUST also send certificate and certificate_verify handshake messages. The certificate carries a certificate for the peer's signature public key, and the certificate_verify carries the peer's signed authentication response to the EAP server ✍️. After receiving this packet, the EAP server verifies the peer's certificate and digital signature, if one was requested 🕵️♀️.
If the peer's authentication fails, the EAP server SHOULD send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS record that holds the appropriate TLS alert message 🚨. The EAP server SHOULD send a TLS alert rather than immediately terminating the conversation. That way, the peer can tell the user what went wrong and maybe restart the conversation 🙏.
To make sure the peer actually gets that TLS alert, the EAP server MUST wait for the peer to reply with an EAP-Response packet 👀. That EAP-Response MAY encapsulate a TLS client_hello handshake message. In that case the EAP server MAY allow the EAP-TLS conversation to restart. Or the EAP-Response MAY contain an EAP-Response packet with EAP-Type=EAP-TLS and no data. In that case, the EAP server MUST send an EAP-Failure packet and terminate the conversation 🛑. It's up to the EAP server whether to allow restarts, and if so, how many times they can happen. An EAP server that supports restarts SHOULD put a cap on how many restarts it allows, so it's protected against denial of service attacks 🛡️.
If the peer's authentication succeeds, the EAP server MUST respond with an EAP-Request packet with EAP-Type=EAP-TLS. For a new TLS session, that packet includes one or more TLS records with TLS change_cipher_spec and finished handshake messages. The finished message carries the EAP server's authentication response to the peer 🎉. The peer then verifies the hash to authenticate the EAP server 🔐.
If the EAP server's authentication fails, the peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message that explains why the authentication failed. The peer MAY also send a TLS alert instead of terminating the conversation right away. This lets the EAP server log the cause of the error for the system administrator to look at later 📋.
To make sure the EAP server gets that TLS alert, the peer MUST wait for the EAP server to reply before it terminates the conversation. The EAP server MUST reply with an EAP-Failure packet, because a server authentication failure is a terminal condition 💀.
If the EAP server authenticates successfully, the peer MUST send an EAP-Response packet of EAP-Type=EAP-TLS with no data. The EAP server then MUST respond with an EAP-Success message 🥳.
3.2. Retry behavior 🔁
Just like the other EAP protocols, the EAP server handles retries. If the EAP server doesn't hear back from the peer, it MUST resend the EAP-Request it hasn't gotten an EAP-Response for yet 📨. The peer, though, MUST NOT resend EAP-Response packets unless the EAP server prompts it first 🙅♀️.
Here's an example. Say the initial EAP-TLS start packet from the EAP server gets lost. The peer never receives it, so it never responds, and the EAP server resends the EAP-TLS start packet 😬. Once the peer finally gets the EAP-TLS start packet, it sends an EAP-Response carrying the client_hello message. If that EAP-Response gets lost, the EAP server resends the initial EAP-TLS start, and the peer resends the EAP-Response 🔄.
Because of all that, a peer might get duplicate EAP-Request messages and send duplicate EAP-Response messages too. So both the peer and the EAP server need to be built to handle this possibility 🧠.
3.3. Fragmentation
okay so a single TLS record can be up to 16384 octets 🧚, but a TLS message can span multiple TLS records, and a TLS certificate message could in principle be as long as 16MB 😭. That means the group of EAP-TLS messages sent in a single round might end up bigger than the PPP MTU, the maximum RADIUS packet size of 4096 octets, or even the Multilink Maximum Received Reconstructed Unit (MRRU) 💅. As described in [2], the multilink MRRU gets negotiated through the Multilink MRRU LCP option, which has an MRRU length field of two octets, so MRRUs can be as large as 64 KB ✨.
ngl, though, to protect against reassembly lockup and denial of service attacks 🙈, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. A typical certificate chain is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, so a reasonable choice of maximum acceptable message length might be 64 KB 🎀.
If this value is chosen, then fragmentation can be handled via the multilink PPP fragmentation mechanisms described in [2]. That's desirable, but there may be cases where multilink or the MRRU LCP option can't be negotiated. So an EAP-TLS implementation MUST provide its own support for fragmentation and reassembly 🫶.
Since EAP is a simple ACK-NAK protocol, fragmentation support can be added in a simple way 🦋. In EAP, fragments that are lost or damaged in transit get retransmitted, and since sequencing information is provided by the Identifier field in EAP, there's no need for a fragment offset field like the one IPv4 has.
EAP-TLS fragmentation support is provided by adding a flags octet within the EAP-Response and EAP-Request packets, along with a TLS Message Length field of four octets. The flags are the Length included (L), More fragments (M), and EAP-TLS Start (S) bits.
- The L flag is set to indicate the presence of the four octet
TLS Message Lengthfield, and MUST be set for the first fragment of a fragmented TLS message or set of messages. - The M flag is set on all but the last fragment.
- The S flag is set only within the EAP-TLS start message sent from the EAP server to the peer.
The TLS Message Length field is four octets, and it gives the total length of the TLS message or set of messages being fragmented, which makes buffer allocation simpler 🧺.
When an EAP-TLS peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and no data. This serves as a fragment ACK 🌸. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. To keep fragment processing error-free, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value.
Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS and no data. This is also a fragment ACK 💜. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. To keep fragment processing error-free, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response.
3.4. Identity verification
As part of the TLS negotiation, the server presents a certificate to the peer, and if mutual authentication is requested, the peer presents a certificate to the server 🔐.
Since the peer has made a claim of identity in the EAP-Response/Identity (MyID) packet, the EAP server SHOULD verify that the claimed identity corresponds to the certificate presented by the peer. Typically this is done either by placing the userId within the peer certificate, or by providing a mapping between the peer certificate and the userId using a directory service 📇.
Similarly, the peer MUST verify the validity of the EAP server certificate, and SHOULD also examine the EAP server name presented in the certificate, to figure out whether the EAP server can be trusted 👀. Please note that when EAP authentication is remoted, the EAP server won't live on the same machine as the authenticator, so the name in the EAP server's certificate can't be expected to match that of the intended destination. In that case, a more appropriate test might be whether the EAP server's certificate is signed by a CA controlling the intended destination, and whether the EAP server exists within a target sub-domain.
3.5. Key derivation
Since the normal TLS keys are used in the handshake, they shouldn't be used in a different context, so new encryption keys must be derived from the TLS master secret for use with PPP encryption 🗝️. For both peer and EAP server, the derivation goes like this: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, "client EAP encryption", random) is computed up to 128 bytes, and the value PRF("", "client EAP encryption", random) is computed up to 64 bytes (where "" is an empty string).
Here's how the keys get sliced out ✂️:
- The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings.
- The EAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string.
- The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string.
- The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string.
- The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above.
- The server initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output.
The use of these encryption and authentication keys is specific to the PPP encryption mechanism used, such as those defined in [9] and [10]. Additional keys or other non-secret values (such as IVs) can be obtained as needed for future PPP encryption methods by extending the outputs of the PRF beyond 128 bytes and 64 bytes, respectively 🌈.
3.6. ECP negotiation
Since TLS supports ciphersuite negotiation, peers that complete the TLS negotiation will also have selected a ciphersuite, which includes key strength, encryption, and hashing methods. So a subsequent Encryption Control Protocol (ECP) conversation, if it happens, has a predetermined result 🍓.
To make sure the EAP-TLS ciphersuite negotiation and the subsequent ECP negotiation (described in [6]) agree, during ECP negotiation the PPP peer MUST offer only the ciphersuite negotiated in EAP-TLS. This ensures that the PPP authenticator MUST accept the EAP-TLS negotiated ciphersuite for the conversation to proceed. If the authenticator doesn't accept the EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP terminate and disconnect 🔌.
Please note that it can't be assumed that the PPP authenticator and EAP server are located on the same machine, or that the authenticator understands the EAP-TLS conversation that has passed through it. So if the peer offers a ciphersuite other than the one negotiated in EAP-TLS, there's no way for the authenticator to know how to respond correctly 🙃.
3.7. CCP negotiation
TLS as described in [12] supports compression as well as ciphersuite negotiation. However, TLS only provides support for a limited number of compression types, which don't overlap with the compression types used in PPP. As a result, during the EAP-TLS conversation the EAP endpoints MUST NOT request or negotiate compression 🚫. Instead, the PPP Compression Control Protocol (CCP), described in [13], should be used to negotiate the desired compression scheme ✨.
3.8. Examples 🎀
okay so bestie, this is where the spec gets to show off its moves 💅 In the case where the EAP-TLS mutual authentication is successful, the conversation goes like this:
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
ECP negotiation
CCP negotiationIn the case where the EAP-TLS mutual authentication is successful, and fragmentation is required, the conversation looks like this. Same vibe, just chopped into fragments so it all fits 🧩
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
(Fragment 1: L, M bits set)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(Fragment 2: M bit set)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(Fragment 3)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS inished)(Fragment 1:
L, M bits set)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
PPP EAP-Response/
EAP-Type=EAP-TLS
(Fragment 2)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
ECP negotiation
CCP negotiationIn the case where the server authenticates to the client successfully, but the client fails to authenticate to the server, the conversation goes like this. Oof, the client gets left on read 😭
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Request
EAP-Type=EAP-TLS
(TLS Alert message)
PPP EAP-Response/
EAP-Type=EAP-TLS ->
<- PPP EAP-Failure
(User Disconnected)In the case where server authentication is unsuccessful, the conversation looks like this:
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
<- PPP EAP-Request/
EAP-Type=EAP-TLS
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS Alert message) ->
<- PPP EAP-Failure
(User Disconnected)In the case where a previously established session is being resumed, and both sides authenticate successfully, the conversation goes like this. A returning friend, instant vibe check ✨
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
ECP negotiation
CCP negotiationIn the case where a previously established session is being resumed, and the server authenticates to the client successfully but the client fails to authenticate to the server, the conversation goes like this:
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello) ->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
PPP EA-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- PPP EAP-Request
EAP-Type=EAP-TLS
(TLS Alert message)
PPP EAP-Response
EAP-Type=EAP-TLS ->
<- PPP EAP-Failure
(User Disconnected)In the case where a previously established session is being resumed, and the server authentication is unsuccessful, the conversation goes like this:
Authenticating Peer Authenticator
------------------- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
<- PPP EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- PPP EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
<- PPP EAP-Request/
EAP-Type=EAP-TLS
PPP EAP-Response/
EAP-Type=EAP-TLS
(TLS Alert message) ->
<- PPP EAP-Failure
(User Disconnected)4. Detailed description of the EAP-TLS protocol 🦋
4.1. PPP EAP TLS Packet Format ✨
okay so bestie, this is the packet layout, and it's giving "every field has a job" 🎀 Here's a quick peek at how the PPP EAP TLS Request/Response packet is laid out. Everything gets sent left to right, no cap 💅
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 | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 🦋
The Code is 1 for a Request and 2 for a Response.
Identifier 🌸
The Identifier is one octet, and its whole job is helping you match a Response to the Request it belongs to. Very matchmaker energy 💕
Length 📏
The Length is two octets and tells you how long the EAP packet is, counting the Code, Identifier, Length, Type, and Data fields. Anything sitting outside the Length field is Data Link Layer padding, so it should be ignored when it arrives. Not your problem, bestie 🙈
Type 🍓
The Type is 13, which means EAP TLS. We are SO here for it 🔥
Data 💜
The format of the Data field depends on the Code field. Tell me the Code and I'll tell you what the Data looks like 🧚
4.2. PPP EAP TLS Request Packet ✨
this one is the Request packet, and it's basically the main character of the whole exchange 👑 Here's the layout, left to right like always:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 💖
The Code is 1, because it's a Request. Obviously 🙄✨
Identifier 🦋
The Identifier is one octet and helps match Responses with Requests. Here's the drama: the Identifier MUST be changed on each Request packet. Every new Request gets a fresh Identifier, no reusing the same one, periodt 💅
Length 📏
The Length is two octets and tells you the length of the EAP packet, counting the Code, Identifier, Length, Type, and TLS Response fields.
Type 🍓
The Type is 13, which is EAP TLS. Iconic 😭
Flags 🌈
Okay this is where it gets spicy 🌶️ The Flags field is one octet, laid out like this:
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|L M S R R R R R|
+-+-+-+-+-+-+-+-+L means Length included, M means More fragments, S means EAP-TLS start, and R is Reserved, so it's just sitting there looking cute 🎀
The L bit (length included) gets set to say that the four octet TLS Message Length field is there. It MUST be set for the first fragment of a fragmented TLS message or set of messages, so don't skip it! The M bit (more fragments) is set on all but the last fragment, like a "to be continued" sign 📖 The S bit (EAP-TLS start) is set in an EAP-TLS Start message. This is what tells the EAP-TLS Start message apart from a fragment acknowledgement, which is honestly such a clean way to avoid confusion 🫶
TLS Message Length 🧚
This field is four octets, and it only shows up if the L bit is set. It gives you the total length of the TLS message or set of messages being fragmented, so you know the whole size of the thing 🌸
TLS data 🫧
The TLS data is the encapsulated TLS packet, in TLS record format. It's like a present wrapped inside a present 🎁
4.3. PPP EAP TLS Response Packet ✨
the Response packet is the other half of the friendship 🫶 Here's the layout, same left-to-right energy:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 💜
The Code is 2, because it's a Response 💅
Identifier 🌸
The Identifier is one octet and MUST match the Identifier field from the corresponding request. No mismatched energy allowed 🙅♀️
Length 📏
The Length is two octets and tells you the length of the EAP packet, counting the Code, Identifier, Length, Type, and TLS data fields.
Type 🍓
The Type is 13, which is EAP TLS. Same as always, and we love consistency 💖
Flags 🌈
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|L M S R R R R R|
+-+-+-+-+-+-+-+-+L means Length included, M means More fragments, S means EAP-TLS start, and R is Reserved 🦋
The L bit (length included) gets set to say the four octet TLS Message Length field is present, and it MUST be set for the first fragment of a fragmented TLS message or set of messages. The M bit (more fragments) is set on all but the last fragment. The S bit (EAP-TLS start) is set in an EAP-TLS Start message, which is how it stands apart from a fragment acknowledgement. Clean separation, no drama 🎀
TLS Message Length 🧚
This is four octets, and it's only there if the L bit is set. It gives the total length of the TLS message or set of messages being fragmented 🌷
TLS data 🫧
The TLS data is the encapsulated TLS packet, in TLS record format. Wrapped gift, round two 🎁
5. References ✨
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[4] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[6] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996.
[7] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977).
[8] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980).
[9] Sklower, K. amd G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998.
[13] Rand, D., "The PPP Compression Control Protocol", RFC 1962, June 1996.
6. Security Considerations ✨
Okay bestie, this section is SERIOUS, so read it carefully 🚨 Security is not the place to skim 😭
6.1. Certificate revocation
Since the EAP server is on the Internet during the EAP conversation, the server is capable of following a certificate chain or verifying whether the peer's certificate has been revoked. In contrast, the peer may or may not have Internet connectivity, so while it can validate the EAP server's certificate based on a pre-configured set of CAs, it may not be able to follow a certificate chain or verify whether the EAP server's certificate has been revoked 💀
In the case where the peer is initiating a voluntary Layer 2 tunnel using PPTP or L2TP, the peer will typically already have a PPP interface and Internet connectivity established at the time of tunnel initiation. As a result, during the EAP conversation it is capable of checking for certificate revocation. Main character behavior 👑
However, in the case where the peer is initiating an initial PPP conversation, it will not have Internet connectivity and is therefore not capable of checking for certificate revocation until after NCP negotiation completes and the peer has access to the Internet. In this case, the peer SHOULD check for certificate revocation after connecting to the Internet. Bestie, don't forget this one, it's a must-check 🙏
6.2. Separation of the EAP server and PPP authenticator
As a result of the EAP-TLS conversation, the EAP endpoints will mutually authenticate, negotiate a ciphersuite, and derive a session key for subsequent use in PPP encryption. Since the peer and EAP client reside on the same machine, it is necessary for the EAP client module to pass the session key to the PPP encryption module. Passing the key along, very teamwork 🤝
The situation may be more complex on the PPP authenticator, which may or may not reside on the same machine as the EAP server. In the case where the EAP server and PPP authenticator reside on different machines, there are several implications for security. Firstly, the mutual authentication defined in EAP-TLS will occur between the peer and the EAP server, not between the peer and the authenticator. This means that as a result of the EAP-TLS conversation, it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to. Okay this is a plot twist 😳
The second issue is that the session key negotiated between the peer and EAP server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the session key from the EAP server to the authenticator or tunnel server that needs to use the key. The specification of this transit mechanism is outside the scope of this document. Someone else's problem, but it's still a problem 🙃
6.3. Relationship of PPP encryption to other security mechanisms
It is envisaged that EAP-TLS will be used primarily with dialup PPP connections. However, there are also circumstances in which PPP encryption may be used along with Layer 2 tunneling protocols such as PPTP and L2TP. 🌐
In compulsory layer 2 tunneling, a PPP peer makes a connection to a NAS or router which tunnels the PPP packets to a tunnel server. Since with compulsory tunneling a PPP peer cannot tell whether its packets are being tunneled, let alone whether the network device is securing the tunnel, if security is required then the client must make its own arrangements. In the case where all endpoints cannot be relied upon to implement IPSEC, TLS, or another suitable security protocol, PPP encryption provides a convenient means to ensure the privacy of packets transiting between the client and the tunnel server. Trust nobody, keep your packets private 🔒💜
7. Acknowledgments ✨
Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft for useful discussions of this problem space. 🌈🫶
8. Authors' Addresses ✨
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Phone: 425-936-6605 EMail: bernarda@microsoft.com
Dan Simon Microsoft Corporation One Microsoft Way Redmond, WA 98052
Phone: 425-936-6711 EMail: dansimon@microsoft.com
9. Full Copyright Statement ✨
Copyright (C) The Internet Society (1999). All Rights Reserved. 💖
Okay, legal stuff but make it cute 🎀. Anyone can copy and share this document, and translations of it too. People can also make derivative works that comment on it, explain it, or help people implement it, and publish, copy and distribute those, in whole or in part, with no restriction of any kind. The one catch is that the copyright notice and this paragraph have to be included on all those copies and derivative works 🫶.
The document itself, though, may not be modified in any way 🙅♀️. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: you can change it as needed for developing Internet standards (but then the copyright procedures in the Internet Standards process must be followed), or you can translate it into languages other than English 🌈.
These permissions are perpetual, which means the Internet Society and its successors or assigns will never take them back ♾️.
This document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 💀
Acknowledgement 🧚
Funding for the RFC Editor function is currently provided by the Internet Society. 🍓 Thank you, Internet Society, you're literally keeping the lights on for all of this 💜.
📦 where this page comes from
- ietf: rfc2716 1999-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms