draft-ietf-emu-eap-tls13-05.txt   draft-ietf-emu-eap-tls13-06.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 May 26, 2019 Intended status: Standards Track August 2, 2019
Expires: November 27, 2019 Expires: February 3, 2020
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-05 draft-ietf-emu-eap-tls13-06
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 November 27, 2019. This Internet-Draft will expire on February 3, 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 25 skipping to change at page 2, line 25
2.1.3. No Peer Authentication . . . . . . . . . . . . . . . 8 2.1.3. No Peer Authentication . . . . . . . . . . . . . . . 8
2.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 9 2.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 9
2.1.5. Ticket Establishment . . . . . . . . . . . . . . . . 10 2.1.5. Ticket Establishment . . . . . . . . . . . . . . . . 10
2.1.6. Resumption . . . . . . . . . . . . . . . . . . . . . 11 2.1.6. Resumption . . . . . . . . . . . . . . . . . . . . . 11
2.1.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.8. Fragmentation . . . . . . . . . . . . . . . . . . . . 13 2.1.8. Fragmentation . . . . . . . . . . . . . . . . . . . . 13
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 14 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 14
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 14 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Parameter Negotiation and Compliance Requirements . . . . 15 2.4. Parameter Negotiation and Compliance Requirements . . . . 15
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 16 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 16
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 16 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 17
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 17 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 18
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 17 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 18
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 17 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 18
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 17 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 19
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 18 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 19
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 18 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 19
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 19 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 20
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 20 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 21
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 21 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 22
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 21 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . 22 6.1. Normative References . . . . . . . . . . . . . . . . . . 23
6.2. Informative references . . . . . . . . . . . . . . . . . 23 6.2. Informative references . . . . . . . . . . . . . . . . . 24
Appendix A. Updated references . . . . . . . . . . . . . . . . . 26 Appendix A. Updated references . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 and key derivation utilizing the TLS handshake
protocol for cryptographic algorithms and protocol version protocol for cryptographic algorithms and protocol version
negotiation, mutual authentication, and establishment of shared negotiation, mutual authentication, and establishment of shared
skipping to change at page 4, line 40 skipping to change at page 4, line 40
negotiated. TLS 1.3 introduced early application data which is not negotiated. TLS 1.3 introduced early application data which is not
used in EAP-TLS. A server which receives an "early_data" extension used in EAP-TLS. A server which receives an "early_data" extension
MUST ignore the extension or respond with a HelloRetryRequest as MUST ignore the extension or respond with a HelloRetryRequest as
described in Section 4.2.10 of [RFC8446]. Resumption is handled as described in Section 4.2.10 of [RFC8446]. Resumption is handled as
described in Section 2.1.6. After the TLS handshake has completed described in Section 2.1.6. After the TLS handshake has completed
and all Post-Handshake messages have been sent, the EAP server sends and all Post-Handshake messages have been sent, the EAP server sends
EAP-Success. EAP-Success.
In the case where EAP-TLS with mutual authentication is successful, In the case where EAP-TLS with mutual authentication is successful,
the conversation will appear as shown in Figure 1. The EAP server the conversation will appear as shown in Figure 1. The EAP server
commits to not send any more handshake messages by sending an empty commits to not send any more handshake messages by sending a TLS
TLS record, see Section 2.5. record with the application data 0x00, see Section 2.5.
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 5, line 25 skipping to change at page 5, line 25
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,
<-------- TLS empty record) <-------- TLS Application Data)
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-Success <-------- EAP-Success
Figure 1: EAP-TLS mutual authentication Figure 1: EAP-TLS mutual authentication
2.1.2. Termination 2.1.2. Termination
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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,
<-------- TLS empty record) <-------- TLS Application Data)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Fatal Alert) (TLS Fatal Alert)
--------> -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 3: EAP-TLS unsuccessful server authentication Figure 3: EAP-TLS unsuccessful server authentication
In the case where the server authenticates to the peer successfully, In the case where the server authenticates to the peer successfully,
but the peer fails to authenticate to the server, the conversation but the peer fails to authenticate to the server, the conversation
skipping to change at page 8, line 26 skipping to change at page 8, line 26
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,
<-------- TLS empty record) <-------- TLS Application Data)
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
<-------- (TLS Fatal Alert) <-------- (TLS Fatal Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
skipping to change at page 9, line 24 skipping to change at page 9, 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 Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS empty record) <-------- TLS Application Data)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
<-------- EAP-Success <-------- EAP-Success
Figure 5: EAP-TLS without peer authentication Figure 5: EAP-TLS without peer authentication
2.1.4. Hello Retry Request 2.1.4. Hello Retry Request
TLS 1.3 [RFC8446] defines that TLS servers can send a TLS 1.3 [RFC8446] defines that TLS servers can send a
skipping to change at page 10, line 29 skipping to change at page 10, line 29
(TLS HelloRetryRequest) (TLS HelloRetryRequest)
<-------- <--------
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 Finished, TLS Finished,
<-------- TLS empty record) <-------- TLS Application Data)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
<-------- EAP-Success <-------- EAP-Success
Figure 6: EAP-TLS with Hello Retry Request Figure 6: EAP-TLS with Hello Retry Request
2.1.5. Ticket Establishment 2.1.5. Ticket Establishment
When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support
skipping to change at page 11, line 33 skipping to change at page 11, line 33
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
(TLS NewSessionTicket, (TLS NewSessionTicket,
<-------- TLS empty record) <-------- TLS Application Data)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 7: EAP-TLS ticket establishment Figure 7: EAP-TLS ticket establishment
2.1.6. Resumption 2.1.6. Resumption
TLS 1.3 replaces the session resumption mechanisms in earlier TLS 1.3 replaces the session resumption mechanisms in earlier
versions of TLS with a new PSK exchange. When EAP-TLS is used with versions of TLS with a new PSK exchange. When EAP-TLS is used with
skipping to change at page 12, line 30 skipping to change at page 12, line 30
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
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 Finished, TLS Finished,
<-------- TLS empty record) <-------- TLS Application Data)
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 offering resumption, which allows the
EAP server to decline resumption and continue the handshake as a full EAP server to decline resumption and continue the handshake as a full
skipping to change at page 16, line 24 skipping to change at page 16, line 24
Handshake messages use the handshake content type and can be sent Handshake messages use the handshake content type and can be sent
after the main handshake. One such Post-Handshake message is after the main handshake. One such Post-Handshake message is
NewSessionTicket. The NewSessionTicket can be used for resumption. NewSessionTicket. The NewSessionTicket can be used for resumption.
After sending TLS Finished, the EAP server may send any number of After sending TLS Finished, the EAP server may send any number of
Post-Handshake messages in separate EAP-Requests. To decrease the Post-Handshake messages in separate EAP-Requests. To decrease the
uncertainty for the EAP peer, the following procedure MUST be uncertainty for the EAP peer, the following procedure MUST be
followed: followed:
When an EAP server has sent its last handshake message (Finished or a When an EAP server has sent its last handshake message (Finished or a
Post-Handshake), it commits to not sending any more handshake Post-Handshake), it commits to not sending any more handshake
messages by appending an empty application data record (i.e. a TLS messages by sending a TLS record with application data 0x00 (i.e. a
record with TLSPlaintext.type = application_data and TLS record with TLSPlaintext.type = application_data,
TLSPlaintext.length = 0) to the last handshake record. After sending TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00). EAP
an empty application data record, the EAP server may only send an server implementations MUST set TLSPlaintext.fragment to 0x00, but
EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert EAP peer implementations MUST accept any application data as a commit
Message. from the EAP server to not send any more handshake messages. The TLS
record with application data may be sent in the same EAP-Request as
the last handshake record or in a separate EAP-Request. Sending the
commit in a separate EAP-Request adds an additional round-trip, but
may be necessary in TLS implementations that only implement a subset
of TLS 1.3. In the case where the server sends the commit in a
separate commit, the conversation will appear as shown in Figure 9.
After sending the application data record, the EAP server may only
send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS
Alert Message.
EAP Peer EAP Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished,
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- TLS Application Data)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 9: Commit in separate EAP-Request
3. Detailed Description of the EAP-TLS Protocol 3. Detailed Description of the EAP-TLS Protocol
No updates to [RFC5216]. No updates to [RFC5216].
4. IANA considerations 4. IANA considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the EAP- Authority (IANA) regarding registration of values related to the EAP-
TLS 1.3 protocol in accordance with [RFC8126]. TLS 1.3 protocol in accordance with [RFC8126].
skipping to change at page 23, line 36 skipping to change at page 24, line 51
6.2. Informative references 6.2. Informative references
[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-05
(work in progress), April 2019. (work in progress), April 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-04 (work in TLSv1.1", draft-ietf-tls-oldversions-deprecate-05 (work in
progress), May 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.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.0.1 specification", 2017. MulteFire, "MulteFire Release 1.1 specification", 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.
skipping to change at page 26, line 7 skipping to change at page 27, line 24
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.4.0, March 2019. System", 3GPP TS 33.501 15.5.0, June 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].
 End of changes. 16 change blocks. 
43 lines changed or deleted 86 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/