draft-ietf-emu-eap-tls13-16.txt   draft-ietf-emu-eap-tls13-17.txt 
Network Working Group J. Preuss Mattsson Network Working Group J. Preuss Mattsson
Internet-Draft M. Sethi Internet-Draft M. Sethi
Updates: 5216 (if approved) Ericsson Updates: 5216 (if approved) Ericsson
Intended status: Standards Track June 11, 2021 Intended status: Standards Track June 26, 2021
Expires: December 13, 2021 Expires: December 28, 2021
Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)
draft-ietf-emu-eap-tls13-16 draft-ietf-emu-eap-tls13-17
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748, The Extensible Authentication Protocol (EAP), defined in RFC 3748,
provides a standard mechanism for support of multiple authentication provides a standard mechanism for support of multiple authentication
methods. This document specifies the use of EAP-Transport Layer methods. This document specifies the use of EAP-Transport Layer
Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
with existing implementations of EAP-TLS. TLS 1.3 provides with existing implementations of EAP-TLS. TLS 1.3 provides
significantly improved security, privacy, and reduced latency when significantly improved security, privacy, and reduced latency when
compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS
1.3) further improves security and privacy by always providing 1.3) further improves security and privacy by always providing
forward secrecy, never disclosing the peer identity, and by mandating forward secrecy, never disclosing the peer identity, and by mandating
use of revocation checking. This document also provides guidance on use of revocation checking. This document also provides guidance on
authorization and resumption for EAP-TLS in general (regardless of authentication, authorization, and resumption for EAP-TLS in general
the underlying TLS version used). This document updates RFC 5216. (regardless of the underlying TLS version used). This document
updates RFC 5216.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 13, 2021. This Internet-Draft will expire on December 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 1.1. Requirements and Terminology . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4
2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 5 2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 6
2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 6 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 7
2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 11 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 11
2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14
2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15
2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16
2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 17 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 17
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19
2.4. Parameter Negotiation and Compliance Requirements . . . . 20 2.4. Parameter Negotiation and Compliance Requirements . . . . 20
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 20 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 21
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 21 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 22
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 22 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 22
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 23 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 23
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 23 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 23
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 23 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 23
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 24 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 24
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 24 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 24
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 25 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 25
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 27 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 27
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 28 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Normative References . . . . . . . . . . . . . . . . . . 29 6.1. Normative References . . . . . . . . . . . . . . . . . . 29
6.2. Informative references . . . . . . . . . . . . . . . . . 30 6.2. Informative references . . . . . . . . . . . . . . . . . 31
Appendix A. Updated references . . . . . . . . . . . . . . . . . 34 Appendix A. Updated references . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
provides a standard mechanism for support of multiple authentication provides a standard mechanism for support of multiple authentication
methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies
an EAP authentication method with certificate-based mutual an EAP authentication method with certificate-based mutual
authentication utilizing the TLS handshake protocol for cryptographic authentication utilizing the TLS handshake protocol for cryptographic
algorithms and protocol version negotiation and establishment of algorithms and protocol version negotiation and establishment of
skipping to change at page 3, line 39 skipping to change at page 3, line 39
in large parts a complete remodeling of the TLS handshake protocol in large parts a complete remodeling of the TLS handshake protocol
including a different message flow, different handshake messages, including a different message flow, different handshake messages,
different key schedule, different cipher suites, different different key schedule, different cipher suites, different
resumption, different privacy protection, and different record resumption, different privacy protection, and different record
padding. This means that significant parts of the normative text in padding. This means that significant parts of the normative text in
the previous EAP-TLS specification [RFC5216] are not applicable to the previous EAP-TLS specification [RFC5216] are not applicable to
EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy
handling, and key derivation need to be appropriately addressed for handling, and key derivation need to be appropriately addressed for
EAP-TLS with TLS 1.3. EAP-TLS with TLS 1.3.
This document defines how to use EAP-TLS with TLS 1.3 and does not This document updates [RFC5216] to define how to use EAP-TLS with TLS
change how EAP-TLS is used with older versions of TLS. It does 1.3. When older TLS versions are negotiated, RFC 5216 applies to
however provide additional guidance on authorization and resumption maintain backwards compatibility. However, this document does
for EAP-TLS in general (regardless of the underlying TLS version provide additional guidance on authentication, authorization, and
used). While this document updates EAP-TLS [RFC5216], it remains resumption for EAP-TLS regardless of the underlying TLS version used.
backwards compatible with it and existing implementations of EAP-TLS.
This document only describes differences compared to [RFC5216]. All This document only describes differences compared to [RFC5216]. All
message flow are example message flows specific to TLS 1.3 and do not message flow 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 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 machine with the EAP state machine it is possible that new versions
of TLS will cause incompatibilities that introduce failures or of TLS will cause incompatibilities that introduce failures or
security issues if they are not carefully integrated into the EAP-TLS security issues if they are not carefully integrated into the EAP-TLS
protocol. Therefore, implementations MUST limit the maximum TLS protocol. Therefore, implementations MUST limit the maximum TLS
version they use to 1.3, unless later versions are explicitly enabled version they use to 1.3, unless later versions are explicitly enabled
by the administrator. by the administrator.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
This document follows the terminology from [I-D.ietf-tls-rfc8446bis] This document follows the terminology from [I-D.ietf-tls-rfc8446bis]
where the master secret is renamed to the main secret and the where the master secret is renamed to the main secret and the
exporter_master_secret is renamed to the exporter_secret. exporter_master_secret is renamed to the exporter_secret.
2. Protocol Overview 2. Protocol Overview
2.1. Overview of the EAP-TLS Conversation 2.1. Overview of the EAP-TLS Conversation
This section updates Section 2.1 of [RFC5216]. This section updates Section 2.1 of [RFC5216].
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 TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS. Therefore, much of Section 2.1 compared to earlier versions of TLS. Therefore, much of Section 2.1
of [RFC5216] does not apply for TLS 1.3. EAP-TLS 1.3 remains of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and
backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS version 5.7 this document applies only when TLS 1.3 is negotiated. When TLS
negotiation is handled by the TLS layer, and thus outside of the 1.2 is negotiated, then [RFC5216] applies.
scope of EAP-TLS. Therefore so long as the underlying TLS
implementation correctly implements TLS version negotiation, EAP-TLS TLS 1.3 introduces several new handshake messages including
will automatically leverage that capability. 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:
o 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.
o The NewSessionTicket message is used to convey resumption
information and is covered in Sections 2.1.2 and 2.1.3.
o 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.
o 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.
o Servers MUST NOT request post-handshake client authentication.
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as After receiving an EAP-Request packet with EAP-Type=EAP-TLS as
described in [RFC5216] the conversation will continue with the TLS described in [RFC5216] the conversation will continue with the TLS
handshake protocol encapsulated in the data fields of EAP-Response handshake protocol encapsulated in the data fields of EAP-Response
and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, 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 the formatting and processing of the TLS handshake SHALL be done as
specified in version 1.3 of TLS. This document only lists additional specified in version 1.3 of TLS. This document only lists additional
and different requirements, restrictions, and processing compared to and different requirements, restrictions, and processing compared to
[RFC8446] and [RFC5216]. [RFC8446] and [RFC5216].
skipping to change at page 5, line 39 skipping to change at page 6, line 21
Certificates can be of any type supported by TLS including raw public Certificates can be of any type supported by TLS including raw public
keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except
for resumption. The full handshake in EAP-TLS with TLS 1.3 always for resumption. The full handshake in EAP-TLS with TLS 1.3 always
provides forward secrecy by exchange of ephemeral "key_share" provides forward secrecy by exchange of ephemeral "key_share"
extensions in the ClientHello and ServerHello (e.g. containing extensions in the ClientHello and ServerHello (e.g. containing
ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3, ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3,
see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early
application data which like all other application data is not used in application data which like all other application data is not used in
EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information
of the "early_data" extension. Resumption is handled as described in of the "early_data" extension. Resumption is handled as described in
Section 2.1.3. TLS 1.3 introduced the Post-Handshake KeyUpdate Section 2.1.3. As a protected success indication [RFC3748] the EAP-
message which is not useful and not expected in EAP-TLS. As a TLS server always sends TLS application data 0x00, see Section 2.5.
protected success indication [RFC3748] the EAP-TLS server always Note that a TLS implementation MAY not allow the EAP-TLS layer to
sends TLS application data 0x00, see Section 2.5. Note that a TLS control in which order things are sent and the application data MAY
implementation MAY not allow the EAP-TLS layer to control in which therefore be sent before a NewSessionTicket. TLS application data
order things are sent and the application data MAY therefore be sent 0x00 is therefore to be interpreted as success after the EAP-Request
before a NewSessionTicket. TLS application data 0x00 is therefore to that contains TLS application data 0x00. After the EAP-TLS server
be interpreted as success after the EAP-Request that contains TLS has sent an EAP-Request containing the TLS application data 0x00 and
application data 0x00. After the EAP-TLS server has sent an EAP- received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the
Request containing the TLS application data 0x00 and received an EAP- EAP-TLS server sends EAP-Success.
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 Figure 1 shows an example message flow for a successful EAP-TLS full
handshake with mutual authentication (and neither HelloRetryRequest handshake with mutual authentication (and neither HelloRetryRequest
nor Post-Handshake messages are sent). nor Post-Handshake messages are sent).
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
skipping to change at page 18, line 24 skipping to change at page 18, line 24
EAP packet exchanges that can be handled. To avoid fragmentation, it 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 is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and
trust anchor certificates small and the length of the certificate trust anchor certificates small and the length of the certificate
chains short. In addition, it is RECOMMENDED to use mechanisms that chains short. In addition, it is RECOMMENDED to use mechanisms that
reduce the sizes of Certificate messages. For a detailed discussion reduce the sizes of Certificate messages. For a detailed discussion
on reducing message sizes to prevent fragmentation, see on reducing message sizes to prevent fragmentation, see
[I-D.ietf-emu-eaptlscert]. [I-D.ietf-emu-eaptlscert].
2.2. Identity Verification 2.2. Identity Verification
This section updates Section 2.2 of [RFC5216]. This section updates Section 2.2 of [RFC5216]. 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 The EAP peer identity provided in the EAP-Response/Identity is not
authenticated by EAP-TLS. Unauthenticated information MUST NOT be authenticated by EAP-TLS. Unauthenticated information MUST NOT be
used for accounting purposes or to give authorization. The used for accounting purposes or to give authorization. The
authenticator and the EAP-TLS server MAY examine the identity authenticator and the EAP-TLS server MAY examine the identity
presented in EAP-Response/Identity for purposes such as routing and presented in EAP-Response/Identity for purposes such as routing and
EAP method selection. EAP-TLS servers MAY reject conversations if EAP method selection. EAP-TLS servers MAY reject conversations if
the identity does not match their policy. Note that this also the identity does not match their policy. Note that this also
applies to resumption, see Sections 2.1.3, 5.6, and 5.7. applies to resumption, see Sections 2.1.3, 5.6, and 5.7.
skipping to change at page 18, line 50 skipping to change at page 18, line 52
certificate) to authenticate the server certificate and one or more certificate) to authenticate the server certificate and one or more
server names to match against the SubjectAltName (SAN) extension in server names to match against the SubjectAltName (SAN) extension in
the server certificate. To simplify name matching, an EAP-TLS the server certificate. To simplify name matching, an EAP-TLS
deployment can assign a name to represent an authorized EAP server deployment can assign a name to represent an authorized EAP server
and EAP Server certificates can include this name in the list of SANs and EAP Server certificates can include this name in the list of SANs
for each certificate that represents an EAP-TLS server. If server for each certificate that represents an EAP-TLS server. If server
name matching is not used, then peers may end up trusting servers for name matching is not used, then peers may end up trusting servers for
EAP authentication that are not intended to be EAP servers for the EAP authentication that are not intended to be EAP servers for the
network. If name matching is not used with a public root CA, then network. If name matching is not used with a public root CA, then
effectively any server can obtain a certificate which will be trusted effectively any server can obtain a certificate which will be trusted
for EAP authentication by the Peer. for EAP authentication by the Peer. While this requirement to verify
domain names is new, and was not mentioned in [RFC5216], 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 The process of configuring a root CA certificate and a server name is
non-trivial and therefore automated methods of provisioning are non-trivial and therefore automated methods of provisioning are
RECOMMENDED. For example, the eduroam federation [RFC7593] provides RECOMMENDED. For example, the eduroam federation [RFC7593] provides
a Configuration Assistant Tool (CAT) to automate the configuration a Configuration Assistant Tool (CAT) to automate the configuration
process. In the absence of a trusted root CA certificate (user process. In the absence of a trusted root CA certificate (user
configured or system-wide), EAP peers MAY implement a trust on first configured or system-wide), EAP peers MAY implement a trust on first
use (TOFU) mechanism where the peer trusts and stores the server use (TOFU) mechanism where the peer trusts and stores the server
certificate during the first connection attempt. The EAP peer certificate during the first connection attempt. The EAP peer
ensures that the server presents the same stored certificate on ensures that the server presents the same stored certificate on
subsequent interactions. Use of a TOFU mechanism does not allow for subsequent interactions. Use of a TOFU mechanism does not allow for
the server certificate to change without out-of-band validation of the server certificate to change without out-of-band validation of
the certificate and is therefore not suitable for many deployments the certificate and is therefore not suitable for many deployments
including ones where multiple EAP servers are deployed for high including ones where multiple EAP servers are deployed for high
availability. 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.
2.3. Key Hierarchy 2.3. Key Hierarchy
This section updates Section 2.3 of [RFC5216]. This section updates Section 2.3 of [RFC5216].
TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier
versions of TLS with HKDF and completely changes the Key Schedule. versions of TLS with HKDF and completely changes the Key Schedule.
The key hierarchies shown in Section 2.3 of [RFC5216] are therefore The key hierarchies shown in Section 2.3 of [RFC5216] are therefore
not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 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 [RFC8446]. the key schedule is described in Section 7.1 of [RFC8446].
When EAP-TLS is used with TLS version 1.3 the Key_Material and 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 Method-Id SHALL be derived from the exporter_secret using the TLS
exporter interface [RFC5705] (for TLS 1.3 this is defined in exporter interface [RFC5705] (for TLS 1.3 this is defined in
Section 7.5 of [RFC8446]). Section 7.5 of [RFC8446]). Type is the value of the EAP Type field
defined in Section 2 of [RFC3748]. For EAP-TLS the Type field has
value 0x0D.
Type-Code = 0x0D Type = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type-Code, 128) Type, 128)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
Type-Code, 64) Type, 64)
Session-Id = Type-Code || Method-Id Session-Id = Type || Method-Id
The MSK and EMSK are derived from the Key_Material in the same manner The MSK and EMSK are derived from the Key_Material in the same manner
as with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated as with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated
below for simplicity: below for simplicity:
MSK = Key_Material(0, 63) MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127) EMSK = Key_Material(64, 127)
Other TLS based EAP methods can use the TLS exporter in a similar Other TLS based EAP methods can use the TLS exporter in a similar
fashion, see [I-D.ietf-emu-tls-eap-types]. fashion, see [I-D.ietf-emu-tls-eap-types].
skipping to change at page 22, line 51 skipping to change at page 23, line 10
mandates use of cipher suites that ensure confidentiality. TLS 1.3 mandates use of cipher suites that ensure confidentiality. TLS 1.3
also encrypts certificates and some of the extensions. When using 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 EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not
cause any additional round-trips. cause any additional round-trips.
[3] Cryptographic strength: TLS 1.3 only defines strong algorithms [3] Cryptographic strength: TLS 1.3 only defines strong algorithms
without major weaknesses and EAP-TLS with TLS 1.3 always provides without major weaknesses and EAP-TLS with TLS 1.3 always provides
forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC
mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated. mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated.
[4] Cryptographic Negotiation: TLS 1.3 increases the number of [4] Cryptographic Negotiation: The TLS layer handles the negotiation
cryptographic parameters that are negotiated in the handshake. When of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP-
EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF
negotiation of AEAD algorithm, HKDF hash algorithm, key exchange hash algorithm, key exchange groups, and signature algorithm, see
groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. Section 4.1.1 of [RFC8446].
5.2. Peer and Server Identities 5.2. Peer and Server Identities
No updates to section 5.2 of [RFC5216]. No updates to section 5.2 of [RFC5216]. Note that Section 2.2 has
additional discussion on identities.
5.3. Certificate Validation 5.3. Certificate Validation
No updates to section 5.3 of [RFC5216]. No updates to section 5.3 of [RFC5216].
5.4. Certificate Revocation 5.4. Certificate Revocation
This section updates Section 5.4 of [RFC5216]. This section updates Section 5.4 of [RFC5216].
While certificates may have long validity periods, there are a number There are a number of reasons (e.g., key compromise, CA compromise,
of reasons (e.g., key compromise, CA compromise, privilege withdrawn, privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub-
etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have CA certificates have to be revoked before their expiry date.
to be revoked before their expiry date. Revocation of the EAP-TLS Revocation of the EAP-TLS server's certificate is complicated by the
server's certificate is complicated by the fact that the EAP-TLS peer fact that the EAP-TLS peer may not have Internet connectivity until
may not have Internet connectivity until authentication completes. authentication completes.
When EAP-TLS is used with TLS 1.3, the revocation status of all the 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 certificates in the certificate chains MUST be checked (except the
trust anchor). An implementation may use Certificate Revocation List trust anchor). An implementation may use Certificate Revocation List
(CRL), Online Certificate Status Protocol (OSCP), or other (CRL), Online Certificate Status Protocol (OSCP), or other
standardized/proprietary methods for revocation checking. Examples standardized/proprietary methods for revocation checking. Examples
of proprietary methods are non-standard formats for distribution of of proprietary methods are non-standard formats for distribution of
revocation lists as well as certificates with very short lifetime. revocation lists as well as certificates with very short lifetime.
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
skipping to change at page 24, line 46 skipping to change at page 25, line 4
5.6. Authorization 5.6. Authorization
This is a new section when compared to [RFC5216]. The guidance in This is a new section when compared to [RFC5216]. The guidance in
this section is relevant for EAP-TLS in general (regardless of the this section is relevant for EAP-TLS in general (regardless of the
underlying TLS version used). underlying TLS version used).
EAP servers will usually require the EAP peer to provide a valid EAP servers will usually require the EAP peer to provide a valid
certificate and will fail the connection if one is not provided. certificate and will fail the connection if one is not provided.
Some deployments may permit no peer authentication for some or all Some deployments may permit no peer authentication for some or all
connections. When peer authentication is not used, implementations connections. When peer authentication is not used, EAP-TLS server
MUST take care to limit network access appropriately for implementations MUST take care to limit network access appropriately
unauthenticated peers and implementations MUST use resumption with for unauthenticated peers and implementations MUST use resumption
caution to ensure that a resumed session is not granted more with caution to ensure that a resumed session is not granted more
privilege than was intended for the original session. 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 EAP-TLS is typically encapsulated in other protocols, such as PPP
[RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191].
The encapsulating protocols can also provide additional, non-EAP The encapsulating protocols can also provide additional, non-EAP
information to an EAP-TLS server. This information can include, but information to an EAP-TLS server. This information can include, but
is not limited to, information about the authenticator, information is not limited to, information about the authenticator, information
about the EAP-TLS peer, or information about the protocol layers about the EAP-TLS peer, or information about the protocol layers
above or below EAP (MAC addresses, IP addresses, port numbers, WiFi above or below EAP (MAC addresses, IP addresses, port numbers, WiFi
SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those
protocols can make policy decisions and enforce authorization based protocols can make policy decisions and enforce authorization based
skipping to change at page 25, line 45 skipping to change at page 26, line 4
There are a number of security issues related to resumption that are There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies to EAP-TLS when it is requirements in this section therefore applies to EAP-TLS when it is
used with any version of TLS. used with any version of TLS.
When resumption occurs, it is based on cached information at the TLS When resumption occurs, it is based on cached information at the TLS
layer. To perform resumption in a secure way, the EAP-TLS peer and layer. To perform resumption in a secure way, the EAP-TLS peer and
EAP-TLS server need to be able to securely retrieve authorization EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full information such as certificate chains from the initial full
handshake. We use the term "cached data" to describe such handshake. This document use the term "cached data" to describe such
information. Authorization during resumption MUST be based on such information. Authorization during resumption MUST be based on such
cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh
revocation checks on the cached certificate data. Any security revocation checks on the cached certificate data. Any security
policies for authorization MUST be followed also for resumption. The policies for authorization MUST be followed also for resumption. The
certificates may have been revoked since the initial full handshake certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have reduced. If the and the authorizations of the other party may have reduced. If the
cached revocation data is not sufficiently current, the EAP-TLS peer cached revocation data is not sufficiently current, the EAP-TLS peer
or EAP-TLS server MAY force a full TLS handshake. or EAP-TLS server MAY force a full TLS handshake.
There are two ways to retrieve the cached data from the original full There are two ways to retrieve the cached data from the original full
skipping to change at page 26, line 23 skipping to change at page 26, line 30
[RFC8446], where the EAP-TLS server avoids storing information [RFC8446], where the EAP-TLS server avoids storing information
locally and instead encapsulates the information into a ticket or PSK locally and instead encapsulates the information into a ticket or PSK
which is sent to the client for storage. This ticket or PSK is which is sent to the client for storage. This ticket or PSK is
encrypted using a key that only the EAP-TLS server knows. Note that encrypted using a key that only the EAP-TLS server knows. Note that
the client still needs to cache the original handshake information the client still needs to cache the original handshake information
locally and will use the session ID or PSK identity to lookup this locally and will use the session ID or PSK identity to lookup this
information during resumption. However, the EAP-TLS server is able information during resumption. However, the EAP-TLS server is able
to decrypt the ticket or PSK to obtain the original handshake to decrypt the ticket or PSK to obtain the original handshake
information. information.
If the EAP-TLS server or EAP client do not apply any authorization The EAP-TLS server or EAP client MUST cache data during the initial
policies, they MAY allow resumption where no cached data is full handshake sufficient to allow authorization decisions to be made
available. In all other cases, they MUST cache data during the during resumption. If cached data cannot be retrieved in a secure
initial full handshake to enable resumption. The cached data MUST be way, resumption MUST NOT be done.
sufficient to make authorization decisions during resumption. If
cached data cannot be retrieved in a secure way, resumption MUST NOT
be done.
The above requirements also apply if the EAP-TLS server expects some The above requirements also apply if the EAP-TLS server expects some
system to perform accounting for the session. Since accounting must system to perform accounting for the session. Since accounting must
be tied to an authenticated identity, and resumption does not supply be tied to an authenticated identity, and resumption does not supply
such an identity, accounting is impossible without access to cached such an identity, accounting is impossible without access to cached
data. Therefore systems which expect to perform accounting for the data. Therefore systems which expect to perform accounting for the
session SHOULD cache an identifier which can be used in subsequent session SHOULD cache an identifier which can be used in subsequent
accounting. accounting.
As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption
skipping to change at page 34, line 46 skipping to change at page 34, line 46
All references to [RFC3280] are updated with [RFC5280]. All references to [RFC3280] are updated with [RFC5280].
All references to [RFC4282] are updated with [RFC7542]. All references to [RFC4282] are updated with [RFC7542].
Acknowledgments Acknowledgments
The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton,
Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar,
Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa
Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and
suggestions on the draft. suggestions on the draft. Special thanks to the document shepard
Joseph Salowey.
Contributors Contributors
Alan DeKok, FreeRADIUS Alan DeKok, FreeRADIUS
Authors' Addresses Authors' Addresses
John Preuss Mattsson John Preuss Mattsson
Ericsson Ericsson
Stockholm 164 40 Stockholm 164 40
 End of changes. 27 change blocks. 
73 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/