draft-ietf-emu-eap-tls13-07.txt   draft-ietf-emu-eap-tls13-08.txt 
Network Working Group J. Mattsson Network Working Group J. Mattsson
Internet-Draft M. Sethi Internet-Draft M. Sethi
Updates: 5216 (if approved) Ericsson Updates: 5216 (if approved) Ericsson
Intended status: Standards Track September 20, 2019 Intended status: Standards Track December 27, 2019
Expires: March 23, 2020 Expires: June 29, 2020
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-07 draft-ietf-emu-eap-tls13-08
Abstract Abstract
This document specifies the use of EAP-TLS with TLS 1.3 while This document specifies the use of EAP-TLS with TLS 1.3 while
remaining backwards compatible with existing implementations of EAP- remaining backwards compatible with existing implementations of EAP-
TLS. TLS 1.3 provides significantly improved security, privacy, and TLS. TLS 1.3 provides significantly improved security, privacy, and
reduced latency when compared to earlier versions of TLS. EAP-TLS reduced latency when compared to earlier versions of TLS. EAP-TLS
with TLS 1.3 further improves security and privacy by mandating use with TLS 1.3 further improves security and privacy by mandating use
of privacy and revocation checking. This document updates RFC 5216. of privacy and revocation checking. This document updates RFC 5216.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 March 23, 2020. This Internet-Draft will expire on June 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 41 skipping to change at page 2, line 41
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 19 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 19
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 19 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 19
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 19
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 20 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 20
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 21 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 21
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 23 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 23
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 23 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . 23 6.1. Normative References . . . . . . . . . . . . . . . . . . 23
6.2. Informative references . . . . . . . . . . . . . . . . . 24 6.2. Informative references . . . . . . . . . . . . . . . . . 24
Appendix A. Updated references . . . . . . . . . . . . . . . . . 27 Appendix A. Updated references . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 and key derivation utilizing the TLS handshake authentication utilizing the TLS handshake protocol for cryptographic
protocol for cryptographic algorithms and protocol version algorithms and protocol version negotiation, mutual authentication,
negotiation, mutual authentication, and establishment of shared and establishment of shared secret keying material. EAP-TLS is
secret keying material. EAP-TLS is widely supported for widely supported for authentication and and key establishment in IEEE
authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using 802.11 [IEEE-802.11] (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec)
IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for networks using IEEE 802.1X [IEEE-802.1X] and it's the default
certificate based authentication in 3GPP 5G [TS.33.501] and MulteFire mechanism for certificate based authentication in 3GPP 5G [TS.33.501]
[MulteFire] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and MulteFire [MulteFire] networks. Many other EAP methods such as
and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2 EAP-FAST [RFC4851], EAP-TTLS [RFC5281], TEAP [RFC7170], and PEAP
[RFC5246]. TLS 1.0 and 1.1 are formally deprecated and prohibited to [PEAP] depend on TLS and EAP-TLS.
negotiate and use [I-D.ietf-tls-oldversions-deprecate].
Weaknesses found in TLS 1.2, as well as new requirements for EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346],
security, privacy, and reduced latency has led to the specification but works perfectly also with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are
of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is formally deprecated and prohibited to negotiate and use
in large parts a complete remodeling of the TLS handshake protocol [I-D.ietf-tls-oldversions-deprecate]. Weaknesses found in TLS 1.2,
including a different message flow, different handshake messages, as well as new requirements for security, privacy, and reduced
different key schedule, different cipher suites, different latency has led to the specification of TLS 1.3 [RFC8446], which
resumption, different privacy protection, and record padding. This obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is in large parts a complete
means that significant parts of the normative text in the previous remodeling of the TLS handshake protocol including a different
EAP-TLS specification [RFC5216] are not applicable to EAP-TLS with message flow, different handshake messages, different key schedule,
TLS 1.3 (or higher). Therefore, aspects such as resumption, privacy different cipher suites, different resumption, different privacy
handling, and key derivation need to be appropriately addressed for protection, and record padding. This means that significant parts of
EAP-TLS with TLS 1.3 (or higher). the normative text in the previous EAP-TLS specification [RFC5216]
are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore,
aspects such as resumption, privacy handling, and key derivation need
to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher).
This document defines how to use EAP-TLS with TLS 1.3 (or higher) and This document defines how to use EAP-TLS with TLS 1.3 (or higher) and
does not change how EAP-TLS is used with older versions of TLS. does not change how EAP-TLS is used with older versions of TLS.
While this document updates EAP-TLS [RFC5216], it remains backwards While this document updates EAP-TLS [RFC5216], it remains backwards
compatible with it and existing implementations of EAP-TLS. This compatible with it and existing implementations of EAP-TLS. This
document only describes differences compared to [RFC5216]. document only describes differences compared to [RFC5216].
In addition to the improved security and privacy offered by TLS 1.3, 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. there are other significant benefits of using EAP-TLS with TLS 1.3.
Privacy is mandatory and achieved without any additional round-trips, Privacy is mandatory and achieved without any additional round-trips,
skipping to change at page 12, line 11 skipping to change at page 12, line 11
negotiate the use of the associated PSK. If the server accepts it, negotiate the use of the associated PSK. If the server accepts it,
then the security context of the new connection is tied to the then the security context of the new connection is tied to the
original connection and the key derived from the initial handshake is original connection and the key derived from the initial handshake is
used to bootstrap the cryptographic state instead of a full used to bootstrap the cryptographic state instead of a full
handshake. It is left up to the EAP peer whether to use resumption, handshake. It is left up to the EAP peer whether to use resumption,
but it is RECOMMENDED that the EAP server accept resumption as long but it is RECOMMENDED that the EAP server accept resumption as long
as the ticket is valid. However, the server MAY choose to require a as the ticket is valid. However, the server MAY choose to require a
full authentication. EAP peers and EAP servers SHOULD follow the full authentication. EAP peers and EAP servers SHOULD follow the
client tracking preventions in Appendix C.4 of [RFC8446]. client tracking preventions in Appendix C.4 of [RFC8446].
It is RECOMMENDED to use anonymous NAIs with the same realm in the
resumption and the original full authentication. This requirement
allows EAP packets to be routable to the same destination as the
original full authentication.
A subsequent authentication using resumption, where both sides A subsequent authentication using resumption, where both sides
authenticate successfully is shown in Figure 8. authenticate successfully (without the issuance of more resumption
tickets) is shown in Figure 8.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
skipping to change at page 12, line 40 skipping to change at page 12, line 46
TLS Finished, TLS Finished,
<-------- Commitment Message) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
<-------- EAP-Success <-------- EAP-Success
Figure 8: EAP-TLS resumption Figure 8: EAP-TLS resumption
As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply
a "key_share" extension when offering resumption, which allows the a "key_share" extension when attempting resumption, which allows the
EAP server to decline resumption and continue the handshake as a full EAP server to potentially decline resumption and fall back to a full
handshake. The message flow in case of mutual authentication handshake. If the EAP peer did not supply a "key_share" extension
(without the issuance of any resumption tickets) is given by when attempting resumption, the EAP server needs to reject the
Figure 1. If the EAP peer did not supply a "key_share" extension
when offering resumption, the EAP server needs to reject the
ClientHello and the EAP peer needs to restart a full handshake. The ClientHello and the EAP peer needs to restart a full handshake. The
message flow in this case is given by Figure 2 followed by Figure 1. message flow in this case is given by Figure 2 followed by Figure 1.
Also during resumption, the server can respond with a Hello Retry Also during resumption, the server can respond with a Hello Retry
Request (see Section 2.1.4) and issue a new ticket (see Request (see Section 2.1.4) or issue a new ticket (see Section 2.1.5)
Section 2.1.5)
2.1.7. Privacy 2.1.7. Privacy
TLS 1.3 significantly improves privacy when compared to earlier TLS 1.3 significantly improves privacy when compared to earlier
versions of TLS by forbidding cipher suites without confidentiality versions of TLS by forbidding cipher suites without confidentiality
and encrypting large parts of the TLS handshake including the and encrypting large parts of the TLS handshake including the
certificate messages. certificate messages.
EAP-TLS peer and server implementations supporting TLS 1.3 or higher EAP-TLS peer and server implementations supporting TLS 1.3 or higher
MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4
in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its
username in cleartext in the Identity Response. It is RECOMMENDED to username in cleartext in the Identity Response. It is RECOMMENDED to
use anonymous NAIs, but other privacy-friendly identities (e.g. use anonymous NAIs, but other privacy-friendly identities (e.g.
encrypted usernames) MAY be used. encrypted usernames) MAY be used. Anonymous NAIs MAY be derived from
the client certificate used in TLS. Client certificates typically
contains an identity with a routable domain such as an email address.
As the certificate messages in TLS 1.3 are encrypted, there is no 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 need to send an empty certificate_list and perform a second handshake
for privacy (as needed by EAP-TLS with earlier versions of TLS). for privacy (as needed by EAP-TLS with earlier versions of TLS).
When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer
and EAP-TLS server SHALL follow the processing specified by the used and EAP-TLS server SHALL follow the processing specified by the used
version of TLS. For TLS 1.3 this means that the EAP-TLS peer only version of TLS. For TLS 1.3 this means that the EAP-TLS peer only
sends an empty certificate_list if it does not have an appropriate 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 to send, and the EAP-TLS server MAY treat an empty
certificate_list as a terminal condition. certificate_list as a terminal condition.
skipping to change at page 14, line 32 skipping to change at page 14, line 39
For a detailed discussion on reducing message sizes to prevent For a detailed discussion on reducing message sizes to prevent
fragmentation, see [I-D.ietf-emu-eaptlscert]. fragmentation, see [I-D.ietf-emu-eaptlscert].
2.2. Identity Verification 2.2. Identity Verification
The identity provided in the EAP-Response/Identity is not The identity provided in the EAP-Response/Identity is not
authenticated by EAP-TLS. Unauthenticated information SHALL NOT be authenticated by EAP-TLS. Unauthenticated information SHALL NOT be
used for accounting purposes or to give authorization. The used for accounting purposes or to give authorization. The
authenticator and the EAP server MAY examine the identity presented authenticator and the EAP server MAY examine the identity presented
in EAP-Response/Identity for purposes such as routing and EAP method in EAP-Response/Identity for purposes such as routing and EAP method
selection. They MAY reject conversations if the identity does not selection. Servers MAY reject conversations if the identity does not
match their policy. Note that this also applies to resumption, see match their policy. Note that this also applies to resumption, see
Sections 2.1.6, 5.6, and 5.7. Sections 2.1.6, 5.6, and 5.7.
2.3. Key Hierarchy 2.3. Key Hierarchy
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 or higher. For not correct when EAP-TLS is used with TLS version 1.3 or higher. For
TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446].
skipping to change at page 17, line 24 skipping to change at page 17, line 24
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished, <-------- TLS Finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- Commitment Message) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
skipping to change at page 25, line 13 skipping to change at page 25, line 13
6.2. Informative references 6.2. Informative references
[I-D.ietf-emu-eaptlscert] [I-D.ietf-emu-eaptlscert]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP Certificates and Long Certificate Chains in TLS-based EAP
Methods", draft-ietf-emu-eaptlscert-00 (work in progress), Methods", draft-ietf-emu-eaptlscert-00 (work in progress),
August 2019. August 2019.
[I-D.ietf-tls-certificate-compression] [I-D.ietf-tls-certificate-compression]
Ghedini, A. and V. Vasiliev, "TLS Certificate Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", draft-ietf-tls-certificate-compression-05 Compression", draft-ietf-tls-certificate-compression-08
(work in progress), April 2019. (work in progress), December 2019.
[I-D.ietf-tls-oldversions-deprecate] [I-D.ietf-tls-oldversions-deprecate]
Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and
TLSv1.1", draft-ietf-tls-oldversions-deprecate-05 (work in TLSv1.1", draft-ietf-tls-oldversions-deprecate-05 (work in
progress), June 2019. progress), June 2019.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology--Telecommunications Standard for Information technology--Telecommunications
and information exchange between systems Local and and information exchange between systems Local and
metropolitan area networks--Specific requirements - Part metropolitan area networks--Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Std 802.11-2016 Layer (PHY) Specifications", IEEE Std 802.11-2016
(Revision of IEEE Std 802.11-2012) , December 2016. (Revision of IEEE Std 802.11-2012) , December 2016.
[IEEE-802.1AE]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Media
Access Control (MAC) Security", IEEE Standard
802.1AE-2018 , December 2018.
[IEEE-802.1X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Port- Standard for Local and metropolitan area networks -- Port-
Based Network Access Control", IEEE Standard 802.1X-2010 , Based Network Access Control", IEEE Standard 802.1X-2010 ,
February 2010. February 2010.
[MulteFire] [MulteFire]
MulteFire, "MulteFire Release 1.1 specification", 2019. MulteFire, "MulteFire Release 1.1 specification", 2019.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", 2019.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/info/rfc1661>. <https://www.rfc-editor.org/info/rfc1661>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999, RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/info/rfc2246>. <https://www.rfc-editor.org/info/rfc2246>.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online Adams, "X.509 Internet Public Key Infrastructure Online
skipping to change at page 26, line 31 skipping to change at page 26, line 41
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, (TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006, DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/info/rfc4346>. <https://www.rfc-editor.org/info/rfc4346>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<https://www.rfc-editor.org/info/rfc4366>. <https://www.rfc-editor.org/info/rfc4366>.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
DOI 10.17487/RFC4851, May 2007,
<https://www.rfc-editor.org/info/rfc4851>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>. May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008, RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>. <https://www.rfc-editor.org/info/rfc5247>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
DOI 10.17487/RFC5281, August 2008,
<https://www.rfc-editor.org/info/rfc5281>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H.,
and D. Kroeselberg, "Extensions to the Emergency Services and D. Kroeselberg, "Extensions to the Emergency Services
Architecture for Dealing With Unauthenticated and Architecture for Dealing With Unauthenticated and
Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406,
December 2014, <https://www.rfc-editor.org/info/rfc7406>. December 2014, <https://www.rfc-editor.org/info/rfc7406>.
skipping to change at page 27, line 39 skipping to change at page 28, line 18
February 2015, <https://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[TS.33.501] [TS.33.501]
3GPP, "Security architecture and procedures for 5G 3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 15.5.0, June 2019. System", 3GPP TS 33.501 16.0.0, September 2019.
Appendix A. Updated references Appendix A. Updated references
All the following references in [RFC5216] are updated as specified All the following references in [RFC5216] are updated as specified
below when EAP-TLS is used with TLS 1.3 or higher. below when EAP-TLS is used with TLS 1.3 or higher.
All references to [RFC2560] are updated with [RFC6960]. All references to [RFC2560] are updated with [RFC6960].
All references to [RFC3280] are updated with [RFC5280]. All references to [RFC3280] are updated with [RFC5280].
skipping to change at page 28, line 19 skipping to change at page 28, line 45
Vesa Torvinen for comments and suggestions on the draft. Vesa Torvinen for comments and suggestions on the draft.
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
Sweden Sweden
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: mohit@piuha.net Email: mohit@piuha.net
 End of changes. 22 change blocks. 
45 lines changed or deleted 77 lines changed or added

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