EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3EricssonKista164 40Swedenjohn.mattsson@ericsson.comEricssonJorvas02420Finlandmohit@iki.fiEMUExtensible Authentication ProtocolIEEE 8025Gauthenticationidentity protectionprivacyforward secrecy
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Requirements and Terminology
. Protocol Overview
. Overview of the EAP-TLS Conversation
. Authentication
. Ticket Establishment
. Resumption
. Termination
. No Peer Authentication
. Hello Retry Request
. Identity
. Privacy
. Fragmentation
. Identity Verification
. Key Hierarchy
. Parameter Negotiation and Compliance Requirements
. EAP State Machines
. Detailed Description of the EAP-TLS Protocol
. IANA Considerations
. Security Considerations
. Security Claims
. Peer and Server Identities
. Certificate Validation
. Certificate Revocation
. Packet Modification Attacks
. Authorization
. Resumption
. Privacy Considerations
. Pervasive Monitoring
. Discovered Vulnerabilities
. Cross-Protocol Attacks
. References
. Normative References
. Informative references
. Updated References
Acknowledgments
Contributors
Authors' Addresses
IntroductionThe Extensible Authentication Protocol (EAP), defined in , provides a standard mechanism for
support of multiple authentication methods. EAP-TLS specifies an EAP authentication
method with certificate-based mutual authentication utilizing the TLS
handshake protocol for cryptographic algorithms and protocol version
negotiation and establishment of shared secret keying material. EAP-TLS
is widely supported for authentication and key establishment in IEEE
802.11 (Wi-Fi) and IEEE
802.1AE (MACsec) networks
using IEEE 802.1X and it's
the default mechanism for certificate-based authentication in 3GPP 5G
and MulteFire networks.
Many other EAP methods such as Flexible Authentication via Secure Tunneling
(EAP-FAST) , Tunneled Transport Layer
Security (EAP-TTLS) , the Tunnel
Extensible Authentication Protocol (TEAP) , as well as vendor-specific EAP methods such as the
Protected Extensible Authentication Protocol (PEAP) , depend on TLS and EAP-TLS.
EAP-TLS references TLS 1.0
and TLS 1.1 but can also work with TLS 1.2 . TLS 1.0 and 1.1 are formally
deprecated and prohibited from being negotiated or used . Weaknesses found in TLS 1.2 as well as new
requirements for security, privacy, and reduced latency have led to the
specification of TLS 1.3 ,
which obsoletes TLS 1.2 . TLS
1.3 is in large part a complete remodeling of the TLS handshake
protocol including a different message flow, different handshake
messages, different key schedule, different cipher suites, different
resumption mechanism, different privacy protection, and different record
padding. This means that significant parts of the normative text in the
previous EAP-TLS specification
are not applicable to EAP-TLS with TLS 1.3. Therefore, aspects such as
resumption, privacy handling, and key derivation need to be
appropriately addressed for EAP-TLS with TLS 1.3.This document updates to define how to use EAP-TLS with TLS 1.3. When older TLS versions are negotiated, RFC 5216 applies to maintain backwards compatibility. However, this document does provide additional guidance on authentication, authorization, and resumption for EAP-TLS regardless of the underlying TLS version used. This document only describes differences compared to . When EAP-TLS is used with TLS 1.3, some references are updated as specified in . All message flows are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state machine with the EAP state machine, it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol. Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator.This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use TLS 1.3. The specification for how other TLS-based EAP methods use TLS 1.3 is left to other documents such as .In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. Privacy, which in EAP-TLS means that no information about the underlying peer identity is disclosed, is mandatory and achieved without any additional round trips. Revocation checking is mandatory and simplified with Online Certificate Status Protocol (OCSP) stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS.Requirements and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Readers are expected to be familiar with the terms and concepts used in EAP-TLS and TLS . The term EAP-TLS peer is used for the entity acting as EAP peer and TLS client. The term EAP-TLS server is used for the entity acting as EAP server and TLS server.This document follows the terminology from where the master secret is renamed to the main secret and the exporter_master_secret is renamed to the exporter_secret.Protocol OverviewOverview of the EAP-TLS ConversationThis section updates 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
does not apply for TLS 1.3. Except for Sections and , this update applies only when TLS 1.3 is
negotiated. When TLS 1.2 is negotiated, then 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 and .
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 , 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 and .AuthenticationThis section updates 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 and of . 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 for additional information on
the "early_data" extension. Resumption is handled as described in
. As a protected success
indication , the EAP-TLS
server always sends TLS application data 0x00; see . 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. shows an example
message flow for a successful EAP-TLS full handshake with mutual
authentication (and neither HelloRetryRequest nor post-handshake
messages are sent).Ticket EstablishmentThis is a new section when compared to .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 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 . shows an example message flow for a successful EAP-TLS full handshake with mutual authentication and ticket establishment of a single ticket.ResumptionThis section updates 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 . 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
and then apply in their entirety. As
described in , 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 .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 . 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. 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.As specified in , 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.TerminationThis section updates 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 does not apply for TLS 1.3. The two paragraphs
below replace the corresponding paragraphs in when EAP-TLS
is used with TLS 1.3. The other paragraphs in 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 , , and 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 .In TLS 1.3 , 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. 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 . shows an example message flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert. 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.No Peer AuthenticationThis is a new section when compared to . shows an example message flow for a successful EAP-TLS full handshake without peer authentication (e.g., emergency services, as described in ).Hello Retry RequestThis is a new section when compared to .As defined in TLS 1.3 ,
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. 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.IdentityThis is a new section when compared to .It is RECOMMENDED to use anonymous NAIs in the Identity Response as such
identities are routable and privacy-friendly. While opaque blobs are
allowed by , 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 . More details on identities are described in
Sections , , , and .PrivacyThis section updates 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) (). 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 , 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 .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 .FragmentationThis section updates 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 .Identity VerificationThis section replaces 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 , , and
.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 , 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 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.Key HierarchyThis section updates 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 are therefore not correct when EAP-TLS is used with
TLS version 1.3. For TLS 1.3 the key schedule is described in .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 (for TLS 1.3, this is defined in ). Type is the value of the EAP Type field defined
in . 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 . 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 . 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 , 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 it generates the same key material as in EAP-TLS
.Parameter Negotiation and Compliance RequirementsThis section updates by amending it in accordance with the following discussion.TLS 1.3 cipher suites are defined differently than in earlier
versions of TLS (see ), and the cipher suites
discussed in 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 . 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.EAP State MachinesThis is a new section when compared to and only applies to TLS 1.3. offers a proposed state machine for EAP.TLS 1.3 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 . 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 . Implementations following 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 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 can set the eapKeyAvailable and
aaaEapKeyAvailable variables.Detailed Description of the EAP-TLS ProtocolThere are no updates to .IANA ConsiderationsThis section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to EAP-TLS 1.3 in accordance with .Per this document, IANA has added the following labels to the "TLS
Exporter Labels" registry defined by . These labels are used in derivation of Key_Material
and Method-Id as defined in :
TLS Exporter Labels
Value
DTLS-OK
Recommended
Note
EXPORTER_EAP_TLS_Key_Material
N
Y
EXPORTER_EAP_TLS_Method-Id
N
Y
Security ConsiderationsThe security considerations of TLS 1.3 apply to EAP-TLS 1.3.Security ClaimsUsing EAP-TLS with TLS 1.3 does not change the security claims for EAP-TLS as given in . However, it strengthens several of the claims as described in the following updates to the notes given in .
[1] Mutual authentication:
By mandating revocation checking of certificates, the
authentication in EAP-TLS with TLS 1.3 is stronger as authentication
with revoked certificates will always fail.
[2] Confidentiality:
The TLS 1.3 handshake offers much better confidentiality than
earlier versions of TLS. EAP-TLS with TLS 1.3 mandates use of cipher
suites that ensure confidentiality. TLS 1.3 also encrypts
certificates and some of the extensions. When using EAP-TLS with TLS
1.3, the use of privacy is mandatory and does not cause any
additional round trips.
[3] Cryptographic strength:
TLS 1.3 only defines strong algorithms without major weaknesses
and EAP-TLS with TLS 1.3 always provides forward secrecy; see . Weak algorithms such as 3DES, CBC mode, RC4, SHA-1, MD5,
P-192, and RSA-1024 have not been registered for use in TLS 1.3.
[4] Cryptographic negotiation:
The TLS layer handles the negotiation of cryptographic
parameters. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the
cryptographic negotiation of the AEAD algorithm, HKDF hash
algorithm, key exchange groups, and signature algorithm; see .
Peer and Server IdentitiesNo updates to . Note that has additional discussion on identities.Certificate ValidationNo updates to . In addition to , guidance on server certificate validation can be found in .Certificate RevocationThis section updates by amending it in accordance with the following discussion.There are a number of reasons (e.g., key compromise, CA compromise, privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have to be revoked before their expiry date. Revocation of the EAP-TLS server's certificate is complicated by the fact that the EAP-TLS peer may not have Internet connectivity until authentication completes.When EAP-TLS is used with TLS 1.3, the revocation status of all the
certificates in the certificate chains MUST be checked
(except the trust anchor). An implementation may use the Certificate
Revocation List (CRL), Online Certificate Status Protocol (OSCP), or
other standardized/proprietary methods for revocation
checking. Examples of proprietary methods are non-standard formats for
distribution of revocation lists as well as certificates with very
short lifetime.EAP-TLS servers supporting TLS 1.3 MUST implement
Certificate Status Requests (OCSP stapling) as specified in and . It is
RECOMMENDED that EAP-TLS peers and EAP-TLS servers use
OCSP stapling for verifying the status of the EAP-TLS server's
certificate chain. When an EAP-TLS peer uses Certificate Status
Requests to check the revocation status of the EAP-TLS server's
certificate chain, it MUST treat a CertificateEntry
(but not the trust anchor) without a valid CertificateStatus extension
as invalid and abort the handshake with an appropriate alert. The OCSP
status handling in TLS 1.3 is different from earlier versions of TLS;
see . In TLS 1.3, the OCSP information is carried in the
CertificateEntry containing the associated certificate instead of a
separate CertificateStatus message as in . This enables sending OCSP information for all
certificates in the certificate chain (except the trust anchor).To enable revocation checking in situations where EAP-TLS peers do not implement or use OCSP stapling, and where network connectivity is not available prior to authentication completion, EAP-TLS peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available. An EAP peer implementation SHOULD NOT trust the network (and any services) until it has verified the revocation status of the server certificate after receiving network connectivity. An EAP peer MUST use a secure transport to verify the revocation status of the server certificate. An EAP peer SHOULD NOT send any other traffic before revocation checking for the server certificate is complete.Packet Modification AttacksThis section updates by amending it in accordance with the
following discussion.As described in and ,
the only information that is integrity and replay protected in EAP-TLS
are the parts of the TLS Data that TLS protects. All other information
in the EAP-TLS message exchange including EAP-Request and EAP-Response
headers, the identity in the Identity Response, EAP-TLS packet header
fields, Type, Flags, EAP-Success, and EAP-Failure can be modified,
spoofed, or replayed.Protected TLS Error alerts are protected failure result indications
and enable the EAP-TLS peer and EAP-TLS server to determine that the
failure result was not spoofed by an attacker. Protected failure
result indications provide integrity and replay protection but
MAY be unauthenticated. Protected failure results do
not significantly improve availability as TLS 1.3 treats most
malformed data as a fatal error.AuthorizationThis is a new section when compared to . The guidance in this section is relevant for EAP-TLS in general (regardless of the underlying TLS version used).EAP servers will usually require the EAP peer to provide a valid
certificate and will fail the connection if one is not provided. Some
deployments may permit no peer authentication for some or all
connections. When peer authentication is not used, EAP-TLS server
implementations MUST take care to limit network access
appropriately for unauthenticated peers, and implementations
MUST use resumption with caution to ensure that a
resumed session is not granted more privilege than was intended for
the original session. An example of limiting network access would be
to invoke a vendor's walled garden or quarantine network
functionality.EAP-TLS is typically encapsulated in other protocols such as PPP
, RADIUS , Diameter , or the Protocol for Carrying Authentication for
Network Access (PANA) . The
encapsulating protocols can also provide additional, non-EAP
information to an EAP-TLS server. This information can include, but is
not limited to, information about the authenticator, information about
the EAP-TLS peer, or information about the protocol layers above or
below EAP (MAC addresses, IP addresses, port numbers, Wi-Fi Service
Set Identifiers (SSIDs), etc.). EAP-TLS servers implementing EAP-TLS
inside those protocols can make policy decisions and enforce
authorization based on a combination of information from the EAP-TLS
exchange and non-EAP information.As noted in , the
identity presented in EAP-Response/Identity is not authenticated by
EAP-TLS and is therefore trivial for an attacker to forge, modify, or
replay. Authorization and accounting MUST be based on
authenticated information such as information in the certificate or
the PSK identity and cached data provisioned for resumption as
described in . Note that the
requirements for Network Access Identifiers (NAIs) specified in
still apply and MUST be followed. EAP-TLS servers MAY reject conversations based on
non-EAP information provided by the encapsulating protocol, for
example if the MAC address of the authenticator does not match the
expected policy.In addition to allowing 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, EAP peer implementations MAY allow binding
the configured acceptable SAN to a specific CA (or CAs) that should
have issued the server certificate to prevent attacks from rogue or
compromised CAs.ResumptionThis is a new section when compared to . The guidance in this section is relevant for
EAP-TLS in general (regardless of the underlying TLS version
used).There are a number of security issues related to resumption that
are not described in . The
problems, guidelines, and requirements in this section therefore apply
to EAP-TLS when it is used with any version of TLS.When resumption occurs, it is based on cached information at the
TLS layer. To perform resumption securely, the EAP-TLS peer and
EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full
handshake. This document uses the term "cached data" to describe such
information. Authorization during resumption MUST be
based on such cached data. The EAP-TLS peer and EAP-TLS server
MAY perform fresh revocation checks on the cached
certificate data. Any security policies for authorization
MUST be followed also for resumption. The certificates
may have been revoked since the initial full handshake and the
authorizations of the other party may have been reduced. If the cached
revocation data is not sufficiently current, the EAP-TLS peer or
EAP-TLS server MAY force a full TLS handshake.There are two ways to retrieve the cached data from the original
full handshake. The first method is that the EAP-TLS server and client
cache the information locally. The cached information is identified by
an identifier. For TLS versions before 1.3, the identifier can be the
session ID; for TLS 1.3, the identifier is the PSK identity. The
second method for retrieving cached information is via or , where the EAP-TLS server avoids storing
information locally and instead encapsulates the information into a
ticket that is sent to the client for storage. This ticket is
encrypted using a key that only the EAP-TLS server knows. Note that
the client still needs to cache the original handshake information
locally and will obtain it while determining the session ID or PSK
identity to use for resumption. However, the EAP-TLS server is able to
decrypt the ticket or PSK to obtain the original handshake
information.The EAP-TLS server or EAP client MUST cache data
during the initial full handshake sufficient to allow authorization
decisions to be made during resumption. If cached data cannot be
retrieved securely, resumption MUST NOT be done.The above requirements also apply if the EAP-TLS server expects
some system to perform accounting for the session. Since accounting
must be tied to an authenticated identity, and resumption does not
supply such an identity, accounting is impossible without access to
cached data. Therefore, systems that expect to perform accounting for
the session SHOULD cache an identifier that can be used
in subsequent accounting.As suggested in , EAP-TLS
peers MUST NOT store resumption PSKs or tickets (and
associated cached data) for longer than 604800 seconds (7 days)
regardless of the PSK or ticket lifetime. The EAP-TLS peer
MAY delete them earlier based on local policy. The
cached data MAY also be removed on the EAP-TLS server
or EAP-TLS peer if any certificate in the certificate chain has been
revoked or has expired. In all such cases, an attempt at resumption
results in a full TLS handshake instead.Information from the EAP-TLS exchange (e.g., the identity provided
in EAP-Response/Identity) as well as non-EAP information (e.g., IP
addresses) may change between the initial full handshake and
resumption. This change creates a "time-of-check time-of-use" (TOCTOU)
security vulnerability. A malicious or compromised user could supply
one set of data during the initial authentication, and a different set
of data during resumption, potentially allowing them to obtain access
that they should not have.If any authorization, accounting, or policy decisions were made
with information that has changed between the initial full handshake
and resumption, and if change may lead to a different decision, such
decisions MUST be reevaluated. It is
RECOMMENDED that authorization, accounting, and policy
decisions are reevaluated based on the information given in the
resumption. EAP-TLS servers MAY reject resumption where
the information supplied during resumption does not match the
information supplied during the original authentication. If a safe
decision is not possible, EAP-TLS servers SHOULD reject
the resumption and continue with a full handshake.Sections and
of provide security considerations for TLS
1.3 resumption.Privacy ConsiderationsThis is a new section when compared to .TLS 1.3 offers much better privacy than earlier versions of TLS as discussed in . In this section, we only discuss the privacy properties of EAP-TLS with TLS 1.3. For privacy properties of TLS 1.3 itself, see .EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in EAP packets. Additionally, the EAP-TLS peer sends an identity in the first EAP-Response. The other fields in the EAP-TLS Request and the EAP-TLS Response packets do not contain any cleartext privacy-sensitive information.Tracking of users by eavesdropping on Identity Responses or
certificates is a well-known problem in many EAP methods. When EAP-TLS
is used with TLS 1.3, all certificates are encrypted, and the username
part of the Identity Response is not revealed (e.g., using anonymous
NAIs). Note that even though all certificates are encrypted, the
server's identity is only protected against passive attackers while
the client's identity is protected against both passive and active
attackers. As with other EAP methods, even when privacy-friendly
identifiers or EAP tunneling is used, the domain name (i.e., the
realm) in the NAI is still typically visible. How much
privacy-sensitive information the domain name leaks is highly
dependent on how many other users are using the same domain name in
the particular access network. If all EAP-TLS peers have the same
domain, no additional information is leaked. If a domain name is used
by a small subset of the EAP-TLS peers, it may aid an attacker in
tracking or identifying the user.Without padding, information about the size of the client
certificate is leaked from the size of the EAP-TLS packets. The
EAP-TLS packets sizes may therefore leak information that can be used
to track or identify the user. If all client certificates have the
same length, no information is leaked. EAP-TLS peers
SHOULD use record padding; see to reduce
information leakage of certificate sizes.If anonymous NAIs are not used, the privacy-friendly identifiers
need to be generated with care. The identities MUST be
generated in a cryptographically secure way so that it is
computationally infeasible for an attacker to differentiate two
identities belonging to the same user from two identities belonging to
different users in the same realm. This can be achieved, for instance,
by using random or pseudo-random usernames such as random byte strings
or ciphertexts and only using the pseudo-random usernames a single
time. Note that the privacy-friendly usernames also MUST NOT include substrings that can be used to relate the identity
to a specific user. Similarly, privacy-friendly usernames MUST NOT be formed by a fixed mapping that stays the same across
multiple different authentications.An EAP-TLS peer with a policy allowing communication with EAP-TLS
servers supporting only TLS 1.2 without privacy and with a static RSA
key exchange is vulnerable to disclosure of the EAP-TLS peer
username. An active attacker can in this case make the EAP-TLS peer
believe that an EAP-TLS server supporting TLS 1.3 only supports TLS
1.2 without privacy. The attacker can simply impersonate the EAP-TLS
server and negotiate TLS 1.2 with static RSA key exchange and send a
TLS alert message when the EAP-TLS peer tries to use privacy by
sending an empty certificate message. Since the attacker
(impersonating the EAP-TLS server) does not provide a
proof-of-possession of the private key until the Finished message when
a static RSA key exchange is used, an EAP-TLS peer may inadvertently
disclose its identity (username) to an attacker. Therefore, it is
RECOMMENDED for EAP-TLS peers to not use EAP-TLS with
TLS 1.2 and static RSA-based cipher suites without privacy. This
implies that an EAP-TLS peer SHOULD NOT continue the
EAP authentication attempt if a TLS 1.2 EAP-TLS server sends an
EAP-TLS/Request with a TLS alert message in response to an empty
certificate message from the peer.Pervasive MonitoringThis is a new section when compared to .Pervasive monitoring refers to widespread surveillance of users. In
the context of EAP-TLS, pervasive monitoring attacks can target
EAP-TLS peer devices for tracking them (and their users) when they
join a network. By encrypting more information, mandating the use of
privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3
offers much better protection against pervasive monitoring. In
addition to the privacy attacks discussed above, surveillance on a
large scale may enable tracking of a user over a wide geographical
area and across different access networks. Using information from
EAP-TLS together with information gathered from other protocols
increases the risk of identifying individual users.
In TLS 1.3, the post-handshake key update mechanism provides
forward secrecy for the traffic secrets. EAP-TLS 1.3 does not
provide a similar mechanism for MSK and EMSK. Implementation using
the exported MSK and EMSK can achieve forward secrecy by frequently
deriving new keys in a similar way as described in .
Discovered VulnerabilitiesThis is a new section when compared to .Over the years, there have been several serious attacks on earlier
versions of Transport Layer Security (TLS), including attacks on its
most commonly used ciphers and modes of operation. summarizes the attacks that were
known at the time of publishing, and BCP 195 provides recommendations and requirements for
improving the security of deployed services that use TLS. However,
many of the attacks are less serious for EAP-TLS as EAP-TLS only uses
the TLS handshake and does not protect any application data. EAP-TLS
implementations MUST mitigate known attacks. EAP-TLS
implementations need to monitor and follow new EAP- and TLS-related
security guidance and requirements such as and .Cross-Protocol AttacksThis is a new section when compared to .Allowing the same certificate to be used in multiple protocols can
potentially allow an attacker to authenticate via one protocol and
then "resume" that session in another protocol. suggests that certificates
typically have one or more FQDNs in the SAN extension. However, those
fields are for EAP validation only and do not indicate that the
certificates are suitable for use with HTTPS or other protocols on the
named host. suggests that
authorization rules should be reapplied on resumption but does not
mandate this behavior. As a result, this cross-protocol resumption
could allow the attacker to bypass authorization policies and to
obtain undesired access to secured systems. Along with making sure
that appropriate authorization information is available and used
during resumption, using different certificates and resumption caches
for different protocols is RECOMMENDED to help keep
different protocol usages separate.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Extensible Authentication Protocol (EAP)This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]The EAP-TLS Authentication ProtocolThe Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]Keying Material Exporters for Transport Layer Security (TLS)A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK]Transport Layer Security (TLS) Extensions: Extension DefinitionsThis document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSPThis document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.The Network Access IdentifierIn order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Informative referencesIEEE Standard for 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) SpecificationsIEEEIEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) SecurityIEEEIEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access ControlIEEEMulteFire Release 1.1 SpecificationMulteFire Alliance[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)Microsoft CorporationThe Point-to-Point Protocol (PPP)This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]The TLS Protocol Version 1.0This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSPThis document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]Remote Authentication Dial In User Service (RADIUS)This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK]State Machines for Extensible Authentication Protocol (EAP) Peer and AuthenticatorThis document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.The state machine and associated model are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.The Network Access IdentifierIn order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \%customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and \%ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.1This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. This memo provides information for the Internet community.Transport Layer Security (TLS) Session Resumption without Server-Side StateThis document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]Protocol for Carrying Authentication for Network Access (PANA)This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Extensible Authentication Protocol (EAP) Key Management FrameworkThe Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK]Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community.Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]Diameter Base ProtocolThe Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]Tunnel Extensible Authentication Protocol (TEAP) Version 1This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized DevicesThis document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS).Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.The eduroam Architecture for Network RoamingThis document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.IANA Registry Updates for TLS and DTLSThis document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.Deprecating TLS 1.0 and TLS 1.1This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack, and this document deprecates their use in TLS 1.2 and DTLS 1.2 digital signatures. However, this document does not deprecate SHA-1 with Hashed Message Authentication Code (HMAC), as used in record protection. This document updates RFC 5246.Handling Large Certificates and Long Certificate Chains in TLS-Based EAP MethodsTLS Ticket RequestsApple Inc.Google LLCCloudflare TLS session tickets enable stateless connection resumption for
clients without server-side, per-client, state. Servers vend an
arbitrary number of session tickets to clients, at their discretion,
upon connection establishment. Clients store and use tickets when
resuming future connections. This document describes a mechanism by
which clients can specify the desired number of tickets needed for
future connections. This extension aims to provide a means for
servers to determine the number of tickets to generate in order to
reduce ticket waste, while simultaneously priming clients for future
connection attempts.
Work in ProgressThe Transport Layer Security (TLS) Protocol Version 1.3Mozilla This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery.
This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077,
5246, and 6961. This document also specifies new requirements for
TLS 1.2 implementations.
Work in ProgressTLS-based EAP types and TLS 1.3FreeRADIUS EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many
other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as
FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many
vendor specific EAP methods. This document updates those methods in
order to use the new key derivation methods available in TLS 1.3.
Additional changes necessitated by TLS 1.3 are also discussed.
Work in ProgressSecurity architecture and procedures for 5G system3GPPRelease 17
Updated References
The following references in are updated as specified below when EAP-TLS is used with TLS 1.3.
All references to are updated to refer to .
All references to are
updated to refer to . References to are updated
to refer to .
All references to are
updated to refer to . References to are updated to
refer to .
Acknowledgments
The authors want to thank ,
, ,
, ,
, , , , , , ,
, , and for comments
and suggestions on this document. Special thanks to the Document Shepherd
.
Contributors, FreeRADIUS
Authors' AddressesEricssonKista164 40Swedenjohn.mattsson@ericsson.comEricssonJorvas02420Finlandmohit@iki.fi