This section updates
Section 2.1 of
RFC 5216 by amending it in accordance with the following discussion.
If the TLS implementation correctly implements TLS version negotiation, EAP-TLS will automatically leverage that capability. The EAP-TLS implementation needs to know which version of TLS was negotiated to correctly support EAP-TLS 1.3 as well as to maintain backward compatibility with EAP-TLS 1.2.
TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of
Section 2.1 of
RFC 5216 does not apply for TLS 1.3. Except for Sections [
2.2] and [
5.7], this update applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then [
RFC 5216] applies.
TLS 1.3 introduces several new handshake messages including HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general, these messages will be handled by the underlying TLS libraries and are not visible to EAP-TLS; however, there are a few things to note:
-
The HelloRetryRequest is used by the server to reject the parameters offered in the ClientHello and suggest new parameters. When this message is encountered, it will increase the number of round trips used by the protocol.
-
The NewSessionTicket message is used to convey resumption information and is covered in Sections [2.1.2] and [2.1.3].
-
The KeyUpdate message is used to update the traffic keys used on a TLS connection. EAP-TLS does not encrypt significant amounts of data so this functionality is not needed. Implementations SHOULD NOT send this message; however, some TLS libraries may automatically generate and process this message.
-
Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT send an early_data extension and clients MUST NOT send an EndOfEarlyData message.
-
Post-handshake authentication MUST NOT be used in EAP-TLS. Clients MUST NOT send a "post_handshake_auth" extension and Servers MUST NOT request post-handshake client authentication.
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in [
RFC 5216], the conversation will continue with the TLS handshake protocol encapsulated in the data fields of EAP-Response and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, the formatting and processing of the TLS handshake
SHALL be done as specified in version 1.3 of TLS. This update only lists additional and different requirements, restrictions, and processing compared to [
RFC 8446] and [
RFC 5216].
This section updates
Section 2.1.1 of
RFC 5216 by amending it in accordance with the following discussion.
The EAP-TLS server
MUST authenticate with a certificate and
SHOULD require the EAP-TLS peer to authenticate with a certificate. Certificates can be of any type supported by TLS including raw public keys. Pre-Shared Key (PSK) authentication
SHALL NOT be used except for resumption. The full handshake in EAP-TLS with TLS 1.3 always provides forward secrecy by exchange of ephemeral "key_share" extensions in the ClientHello and ServerHello (e.g., containing Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) public keys). SessionID is deprecated in TLS 1.3; see Sections
4.1.2 and
4.1.3 of [
RFC 8446]. TLS 1.3 introduced early application data that like all application data (other than the protected success indication described below) is not used in EAP-TLS; see
Section 4.2.10 of
RFC 8446 for additional information on the "early_data" extension. Resumption is handled as described in
Section 2.1.3. As a protected success indication [
RFC 3748], the EAP-TLS server always sends TLS application data 0x00; see
Section 2.5. Note that a TLS implementation
MAY not allow the EAP-TLS layer to control in which order things are sent and the application data
MAY therefore be sent before a NewSessionTicket. TLS application data 0x00 is therefore to be interpreted as success after the EAP-Request that contains TLS application data 0x00. After the EAP-TLS server has sent an EAP-Request containing the TLS application data 0x00 and received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server sends EAP-Success.
Figure 1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest nor post-handshake messages are sent).
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
This is a new section when compared to [
RFC 5216].
To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS server
MUST send one or more post-handshake NewSessionTicket messages (each associated with a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication. Note that TLS 1.3 [
RFC 8446] limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers
MUST respect this upper limit when issuing tickets. The NewSessionTicket is sent after the EAP-TLS server has received the client Finished message in the initial authentication. The NewSessionTicket can be sent in the same flight as the TLS server Finished or later. The PSK associated with the ticket depends on the client Finished and cannot be pre-computed (so as to be sent in the same flight as the TLS server Finished) in handshakes with client authentication. The NewSessionTicket message
MUST NOT include an "early_data" extension. If the "early_data" extension is received, then it
MUST be ignored. Servers should take into account that fewer NewSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario. In most cases, a single NewSessionTicket will be sufficient. A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in [
TICKET-REQUESTS].
Figure 2 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication and ticket establishment of a single ticket.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS NewSessionTicket,
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
This section updates
Section 2.1.2 of
RFC 5216 by amending it in accordance with the following discussion.
EAP-TLS is typically used with client authentication and typically fragments the TLS flights into a large number of EAP-requests and EAP-responses. Resumption significantly reduces the number of round trips and enables the EAP-TLS server to omit database lookups needed during a full handshake with client authentication. TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS
SHALL use a resumption mechanism compatible with version 1.3 of TLS.
For TLS 1.3, resumption is described in
Section 2.2 of
RFC 8446. If the client has received a NewSessionTicket message from the EAP-TLS server, the client can use the PSK identity associated with the ticket to negotiate the use of the associated PSK. If the EAP-TLS server accepts it, then the resumed session has been deemed to be authenticated and securely associated with the prior authentication or resumption. It is up to the EAP-TLS peer to use resumption, but it is
RECOMMENDED that the EAP-TLS peer use resumption if it has a valid ticket that has not been used before. It is left to the EAP-TLS server whether to accept resumption, but it is
RECOMMENDED that the EAP-TLS server accept resumption if the ticket that was issued is still valid. However, the EAP-TLS server
MAY choose to require a full handshake. In the case a full handshake is required, the negotiation proceeds as if the session was a new authentication, and the resumption attempt is ignored. The requirements of Sections [
2.1.1] and [
2.1.2] then apply in their entirety. As described in
Appendix C.4 of
RFC 8446, reuse of a ticket allows passive observers to correlate different connections. EAP-TLS peers and EAP-TLS servers
SHOULD follow the client tracking preventions in
Appendix C.4 of
RFC 8446.
It is
RECOMMENDED to use Network Access Identifiers (NAIs) with the same realm during resumption and the original full handshake. This requirement allows EAP packets to be routed to the same destination as the original full handshake. If this recommendation is not followed, resumption is likely impossible. When NAI reuse can be done without privacy implications, it is
RECOMMENDED to use the same NAI in the resumption as was used in the original full handshake [
RFC 7542]. For example, the NAI @realm can safely be reused since it does not provide any specific information to associate a user's resumption attempt with the original full handshake. However, reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path attacker to associate a resumption attempt with the original full handshake. The TLS PSK identity is typically derived by the TLS implementation and may be an opaque blob without a routable realm. The TLS PSK identity on its own is therefore unsuitable as an NAI in the Identity Response.
Figure 3 shows an example message flow for a subsequent successful EAP-TLS resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server provisions a single new ticket.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello
+ pre_shared_key) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
<-------- TLS Finished,
TLS NewSessionTicket)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
As specified in
Section 2.2 of
RFC 8446, the EAP-TLS peer
SHOULD supply a "key_share" extension when attempting resumption, which allows the EAP-TLS server to potentially decline resumption and fall back to a full handshake. If the EAP-TLS peer did not supply a "key_share" extension when attempting resumption, the EAP-TLS server needs to send a HelloRetryRequest to signal that additional information is needed to complete the handshake, and the EAP-TLS peer needs to send a second ClientHello containing that information. Providing a "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode is also important in order to limit the impact of a key compromise. When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning that compromise of the PSK used for resumption does not compromise any earlier connections. The "psk_dh_ke" key exchange mode
MUST be used for resumption unless the deployment has a local requirement to allow configuration of other mechanisms.
This section updates
Section 2.1.3 of
RFC 5216 by amending it in accordance with the following discussion.
TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, some normative text in
Section 2.1.3 of
RFC 5216 does not apply for TLS 1.3. The two paragraphs below replace the corresponding paragraphs in
Section 2.1.3 of
RFC 5216 when EAP-TLS is used with TLS 1.3. The other paragraphs in
Section 2.1.3 of
RFC 5216 still apply with the exception that SessionID is deprecated.
If the EAP-TLS peer authenticates successfully, the EAP-TLS server
MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with a protected success indication from the EAP-TLS server, followed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, followed by EAP-Success from the server.
If the EAP-TLS server authenticates successfully, the EAP-TLS peer
MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.
Figures [
4], [
5], and [
6] illustrate message flows in several cases where the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message. In earlier versions of TLS, error alerts could be warnings or fatal. In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and "user_canceled", both of which indicate that the connection is not going to continue normally; see [
RFC 8446].
In TLS 1.3 [
RFC 8446], error alerts are not mandatory to send after a fatal error condition. Failure to send TLS Error alerts means that the peer or server would have no way of determining what went wrong. EAP-TLS 1.3 strengthens this requirement. Whenever an implementation encounters a fatal error condition, it
MUST send an appropriate TLS Error alert.
Figure 4 shows an example message flow where the EAP-TLS server rejects the ClientHello with an error alert. The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest; see
Section 2.1.6.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Error Alert)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Failure
Figure 5 shows an example message flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Error Alert)
-------->
<-------- EAP-Failure
Figure 6 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer fails to authenticate to the EAP-TLS server and the server sends a TLS Error alert.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Error Alert)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Failure
This is a new section when compared to [
RFC 5216].
Figure 7 shows an example message flow for a successful EAP-TLS full handshake without peer authentication (e.g., emergency services, as described in [
RFC 7406]).
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
This is a new section when compared to [
RFC 5216].
As defined in TLS 1.3 [
RFC 8446], EAP-TLS servers can send a HelloRetryRequest message in response to a ClientHello if the EAP-TLS server finds an acceptable set of parameters but the initial ClientHello does not contain all the needed information to continue the handshake. One use case is if the EAP-TLS server does not support the groups in the "key_share" extension (or there is no "key_share" extension) but supports one of the groups in the "supported_groups" extension. In this case, the client should send a new ClientHello with a "key_share" that the EAP-TLS server supports.
Figure 8 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication and HelloRetryRequest. Note the extra round trip as a result of the HelloRetryRequest.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS HelloRetryRequest)
<--------
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
This is a new section when compared to [
RFC 5216].
It is
RECOMMENDED to use anonymous NAIs [
RFC 7542] in the Identity Response as such identities are routable and privacy-friendly. While opaque blobs are allowed by [
RFC 3748], such identities are
NOT RECOMMENDED as they are not routable and should only be considered in local deployments where the EAP-TLS peer, EAP authenticator, and EAP-TLS server all belong to the same network. Many client certificates contain an identity such as an email address, which is already in NAI format. When the client certificate contains an NAI as subject name or alternative subject name, an anonymous NAI
SHOULD be derived from the NAI in the certificate; see
Section 2.1.8. More details on identities are described in Sections [
2.1.3], [
2.1.8], [
2.2], and [
5.8].
This section updates
Section 2.1.4 of
RFC 5216 by amending it in accordance with the following discussion.
EAP-TLS 1.3 significantly improves privacy when compared to earlier versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without confidentiality, which means that TLS 1.3 is always encrypting large parts of the TLS handshake including the certificate messages.
EAP-TLS peer and server implementations supporting TLS 1.3
MUST support anonymous Network Access Identifiers (NAIs) (
Section 2.4 of
RFC 7542). A client supporting TLS 1.3
MUST NOT send its username (or any other permanent identifiers) in cleartext in the Identity Response (or any message used instead of the Identity Response). Following [
RFC 7542], it is
RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g., anonymous@realm) or an encrypted username (e.g., xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. Note that the NAI
MUST be a UTF-8 string as defined by the grammar in
Section 2.2 of
RFC 7542.
The HelloRequest message used for privacy in EAP-TLS 1.2 does not exist in TLS 1.3 but as the certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list and perform a second handshake for privacy (as needed by EAP-TLS with earlier versions of TLS). When EAP-TLS is used with TLS version 1.3, the EAP-TLS peer and EAP-TLS server
SHALL follow the processing specified by version 1.3 of TLS. This means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server
MAY treat an empty certificate_list as a terminal condition.
EAP-TLS with TLS 1.3 is always used with privacy. This does not add any extra round trips and the message flow with privacy is just the normal message flow as shown in
Figure 1.
This section updates
Section 2.1.5 of
RFC 5216 by amending it in accordance with the following discussion.
Including ContentType (1 byte), ProtocolVersion (2 bytes), and length (2 bytes) headers, a single TLS record may be up to 16645 octets in length. EAP-TLS fragmentation support is provided through addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a (conditional) TLS Message Length field of four octets. Implementations
MUST NOT set the L bit in unfragmented messages, but they
MUST accept unfragmented messages with and without the L bit set.
Some EAP implementations and access networks may limit the number of EAP packet exchanges that can be handled. To avoid fragmentation, it is
RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and trust anchor certificates small and the length of the certificate chains short. In addition, it is
RECOMMENDED to use mechanisms that reduce the sizes of Certificate messages. For a detailed discussion on reducing message sizes to prevent fragmentation, see [
RFC 9191].
This section replaces
Section 2.2 of
RFC 5216 with the following discussion. The guidance in this section is relevant for EAP-TLS in general (regardless of the underlying TLS version used).
The EAP peer identity provided in the EAP-Response/Identity is not authenticated by EAP-TLS. Unauthenticated information
MUST NOT be used for accounting purposes or to give authorization. The authenticator and the EAP-TLS server
MAY examine the identity presented in EAP-Response/Identity for purposes such as routing and EAP method selection. EAP-TLS servers
MAY reject conversations if the identity does not match their policy. Note that this also applies to resumption; see Sections [
2.1.3], [
5.6], and [
5.7].
The EAP server identity in the TLS server certificate is typically a fully qualified domain name (FQDN) in the SubjectAltName (SAN) extension. Since EAP-TLS deployments may use more than one EAP server, each with a different certificate, EAP peer implementations
SHOULD allow for the configuration of one or more trusted root certificates (CA certificate) to authenticate the server certificate and one or more server names to match against the SubjectAltName (SAN) extension in the server certificate. If any of the configured names match any of the names in the SAN extension, then the name check passes. To simplify name matching, an EAP-TLS deployment can assign a name to represent an authorized EAP server and EAP Server certificates can include this name in the list of SANs for each certificate that represents an EAP-TLS server. If server name matching is not used, then it degrades the confidence that the EAP server with which it is interacting is authoritative for the given network. If name matching is not used with a public root CA, then effectively any server can obtain a certificate that will be trusted for EAP authentication by the peer. While this guidance to verify domain names is new, and was not mentioned in [
RFC 5216], it has been widely implemented in EAP-TLS peers. As such, it is believed that this section contains minimal new interoperability or implementation requirements on EAP-TLS peers and can be applied to earlier versions of TLS.
The process of configuring a root CA certificate and a server name is non-trivial; therefore, automated methods of provisioning are
RECOMMENDED. For example, the eduroam federation [
RFC 7593] provides a Configuration Assistant Tool (CAT) to automate the configuration process. In the absence of a trusted root CA certificate (user configured or system-wide), EAP peers
MAY implement a trust on first use (TOFU) mechanism where the peer trusts and stores the server certificate during the first connection attempt. The EAP peer ensures that the server presents the same stored certificate on subsequent interactions. Use of a TOFU mechanism does not allow for the server certificate to change without out-of-band validation of the certificate and is therefore not suitable for many deployments including ones where multiple EAP servers are deployed for high availability. TOFU mechanisms increase the susceptibility to traffic interception attacks and should only be used if there are adequate controls in place to mitigate this risk.
This section updates
Section 2.3 of
RFC 5216 by replacing it in accordance with the following discussion.
TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier versions of TLS with the HMAC-based Key Derivation Function (HKDF) and completely changes the key schedule. The key hierarchies shown in
Section 2.3 of
RFC 5216 are therefore not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 the key schedule is described in
Section 7.1 of
RFC 8446.
When EAP-TLS is used with TLS version 1.3, the Key_Material and Method-Id
SHALL be derived from the exporter_secret using the TLS exporter interface [
RFC 5705] (for TLS 1.3, this is defined in
Section 7.5 of
RFC 8446). Type is the value of the EAP Type field defined in
Section 2 of
RFC 3748. For EAP-TLS, the Type field has value 0x0D.
Type = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type, 128)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
Type, 64)
Session-Id = Type || Method-Id
The MSK and EMSK are derived from the Key_Material in the same manner as with EAP-TLS
RFC 5216,
Section 2.3. The definitions are repeated below for simplicity:
MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127)
Other TLS-based EAP methods can use the TLS exporter in a similar fashion; see [
TLS-EAP-TYPES].
[
RFC 5247] deprecates the use of an Initialization Vector (IV). Thus, RECV-IV and SEND-IV are not exported in EAP-TLS with TLS 1.3. As noted in [
RFC 5247], lower layers use the MSK in a lower-layer-dependent manner. EAP-TLS with TLS 1.3 exports the MSK and does not specify how it is used by lower layers.
Note that the key derivation
MUST use the length values given above. While in TLS 1.2 and earlier it was possible to truncate the output by requesting less data from the TLS-Exporter function, this practice is not possible with TLS 1.3. If an implementation intends to use only a part of the output of the TLS-Exporter function, then it
MUST ask for the full output and then only use the desired part. Failure to do so will result in incorrect values being calculated for the above keying material.
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation that provides a public API for the exporter. Note that when TLS 1.2 is used with the EAP-TLS exporter [
RFC 5705] it generates the same key material as in EAP-TLS [
RFC 5216].
This section updates
Section 2.4 of
RFC 5216 by amending it in accordance with the following discussion.
TLS 1.3 cipher suites are defined differently than in earlier versions of TLS (see
Appendix B.4 of
RFC 8446), and the cipher suites discussed in
Section 2.4 of
RFC 5216 can therefore not be used when EAP-TLS is used with TLS version 1.3.
When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers
MUST comply with the compliance requirements (mandatory-to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in
Section 9 of
RFC 8446. In EAP-TLS with TLS 1.3, only cipher suites with confidentiality
SHALL be supported.
While EAP-TLS does not protect any application data except for the 0x00 byte that serves as protected success indication, the negotiated cipher suites and algorithms
MAY be used to secure data as done in other TLS-based EAP methods.
This is a new section when compared to [
RFC 5216] and only applies to TLS 1.3. [
RFC 4137] offers a proposed state machine for EAP.
TLS 1.3 [
RFC 8446] introduces post-handshake messages. These post-handshake messages use the handshake content type and can be sent after the main handshake. Examples of post-handshake messages are NewSessionTicket, which is used for resumption and KeyUpdate, which is not useful and not expected in EAP-TLS. After sending TLS Finished, the EAP-TLS server may send any number of post-handshake messages in one or more EAP-Requests.
To provide a protected success result indication and to decrease the uncertainty for the EAP-TLS peer, the following procedure
MUST be followed:
When an EAP-TLS server has successfully processed the TLS client Finished and sent its last handshake message (Finished or a post-handshake message), it sends an encrypted TLS record with application data 0x00. The encrypted TLS record with application data 0x00 is a protected success result indication, as defined in [
RFC 3748]. After sending an EAP-Request that contains the protected success result indication, the EAP-TLS server must not send any more EAP-Requests and may only send an EAP-Success. The EAP-TLS server
MUST NOT send an encrypted TLS record with application data 0x00 before it has successfully processed the client Finished and sent its last handshake message.
TLS Error alerts
SHOULD be considered a failure result indication, as defined in [
RFC 3748]. Implementations following [
RFC 4137] set the alternate indication of failure variable altReject after sending or receiving an error alert. After sending or receiving a TLS Error alert, the EAP-TLS server may only send an EAP-Failure. Protected TLS Error alerts are protected failure result indications, and unprotected TLS Error alerts are not.
The keying material can be derived after the TLS server Finished has been sent or received. Implementations following [
RFC 4137] can then set the eapKeyData and aaaEapKeyData variables.
The keying material can be made available to lower layers and the authenticator after the authenticated success result indication has been sent or received. Implementations following [
RFC 4137] can set the eapKeyAvailable and aaaEapKeyAvailable variables.