Draft: draft-ietf-emu-eap-tls13

Commentary: Thanks a lot ! Merged !
Paragraph (version A):
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-Transport Layer
Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
with existing implementations of EAP-TLS.  TLS 1.3 provides
significantly improved security, privacy, and reduced latency when
compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-TLS
forward secrecy, never disclosing the peer identity, and by mandating
use of revocation checking.  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.
Paragraph (version B):
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-Transport Layer
Security (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
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.
Paragraph (version B):
EAP-TLS RFC5216 references TLS 1.0 RFC2246 and TLS 1.1 RFC4346, but
can also work with TLS 1.2 RFC5246.  TLS 1.0 and 1.1 are formally
deprecated and prohibited to negotiate and use RFC8996.  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 RFC8446,
which obsoletes TLS 1.2 RFC5246.  TLS 1.3 is in large parts 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 RFC5216 are not applicable to EAP-TLS with TLS
key derivation need to be appropriately addressed for EAP-TLS with
TLS 1.3.
Paragraph (version A):
Readers are expected to be familiar with the terms and concepts used
in EAP-TLS RFC5216 and TLS RFC8446.  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.
Paragraph (version A):
client Finished and cannot be pre-computed 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
I-D.ietf-tls-ticketrequests.
Paragraph (version B):
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
I-D.ietf-tls-ticketrequests.
Paragraph (version A):
resumption had never been requested.  The requirements of Sections
section_auth and ticket then apply in their entirety.  As described
in Appendix C.4 of RFC8446, reuse of a ticket allows passive
observers to correlate different connections.  EAP-TLS peers and EAP-
TLS servers SHOULD follow the client tracking preventions in
Appendix C.4 of RFC8446.
Paragraph (version B):
the resumption attempt is ignored.  The requirements of Sections
section_auth and ticket then apply in their entirety.  As described
in Appendix C.4 of RFC8446, reuse of a ticket allows passive
observers to correlate different connections.  EAP-TLS peers and EAP-
TLS servers SHOULD follow the client tracking preventions in
Appendix C.4 of RFC8446.
Paragraph (version A):
"psk_dh_ke" mechanism MUST be used for resumption unless the
deployment has a local requirement to allow configuration of other
mechanisms.
Paragraph (version B):
"psk_dh_ke" key-exchange mode MUST be used for resumption unless the
deployment has a local requirement to allow configuration of other
mechanisms.
Paragraph (version A):
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 TLS Message Length field of four octets.  Implementations
MUST NOT set the L bit in unfragmented messages, but MUST accept
unfragmented messages with and without the L bit set.
Paragraph (version B):
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
MUST accept unfragmented messages with and without the L bit set.
Paragraph (version A):
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.
Paragraph (version B):
for EAP authentication by the Peer.  While this guidance 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.
Paragraph (version A):
RFC5247 deprecates the use of IV.  Thus, RECV-IV and SEND-IV are not
exported in EAP-TLS with TLS 1.3.  As noted in RFC5247, 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.
Paragraph (version B):
RFC5247 deprecates the use of IV.  Thus, RECV-IV and SEND-IV are not
exported in EAP-TLS with TLS 1.3.  As noted in RFC5247, 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.
Paragraph (version A):
While EAP-TLS does not protect any application data except for the
TLS record with application data 0x00, the negotiated cipher suites
and algorithms MAY be used to secure data as done in other TLS-based
EAP methods.
Paragraph (version B):
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.
Paragraph (version A):
TLS Error alerts SHOULD be considered a failure result indication, as
defined in RFC3748.  Implementations following RFC4137 sets 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,
unprotected TLS Error alerts are not.
Paragraph (version B):
TLS Error alerts SHOULD be considered a failure result indication, as
defined in RFC3748.  Implementations following RFC4137 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,
unprotected TLS Error alerts are not.
Paragraph (version A):
and the authorizations of the other party may have reduced.  If the
cached revocation data is not sufficiently current, the EAP-TLS peer
or EAP-TLS server MAY force a full TLS handshake.
Paragraph (version B):
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.
Paragraph (version A):
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 RFC5077 or
RFC8446, where the EAP-TLS server avoids storing information locally
and instead encapsulates the information into a ticket or PSK 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 the client
still needs to cache the original handshake information locally and
will use the session ID or PSK identity to lookup this information
during resumption.  However, the EAP-TLS server is able to decrypt
the ticket or PSK to obtain the original handshake information.
Paragraph (version B):
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 RFC5077 or
RFC8446, where the EAP-TLS server avoids storing information locally
and instead encapsulates the information into a ticket which 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.
Paragraph (version A):
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 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.
Paragraph (version B):
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.