draft-ietf-emu-eap-tls13-03.txt   draft-ietf-emu-eap-tls13-04.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 November 14, 2018 Intended status: Standards Track March 11, 2019
Expires: May 18, 2019 Expires: September 12, 2019
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-03 draft-ietf-emu-eap-tls13-04
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 provides significantly improved protection against with TLS 1.3 further improves security and privacy by mandating use
pervasive monitoring by mandating use of privacy. This document of privacy and revocation checking. This document updates RFC 5216.
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 May 18, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements and Terminology . . . . . . . . . . . . . . 3 1.1. Requirements and Terminology . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 3 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4
2.1.1. Base Case . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Base Case . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Resumption . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Resumption . . . . . . . . . . . . . . . . . . . . . 7
2.1.3. Termination . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Termination . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 13 2.1.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 14
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 14 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 15
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 14 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Parameter Negotiation and Compliance Requirements . . . . 14 2.4. Parameter Negotiation and Compliance Requirements . . . . 16
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 15 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 17
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 15 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 17
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 16 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 18
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 16 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 18
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 16 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 18
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 16 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 18
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 17 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 19
5.6. Privacy Considerations . . . . . . . . . . . . . . . . . 17 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 19
5.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 18 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 21
6.1. Normative References . . . . . . . . . . . . . . . . . . 18 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 22
6.2. Informative references . . . . . . . . . . . . . . . . . 19 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 23
Appendix A. Updated references . . . . . . . . . . . . . . . . . 21 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Normative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Informative references . . . . . . . . . . . . . . . . . 24
Appendix A. Updated references . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 27
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 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
secret keying material. EAP-TLS is widely supported for secret keying material. EAP-TLS is widely supported for
authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using
IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for
certificate based authentication in MulteFire [MulteFire] and 3GPP 5G certificate based authentication in 3GPP 5G [TS.33.501] and MulteFire
[TS.33.501] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] [MulteFire] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246]
and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2 and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2
[RFC5246]. [RFC5246].
Weaknesses found in previous versions of TLS, as well as new Weaknesses found in previous versions of TLS, as well as new
requirements for security, privacy, and reduced latency has led to requirements for security, privacy, and reduced latency has led to
the development of TLS 1.3 [RFC8446], which in large parts is a the development of TLS 1.3 [RFC8446], which in large parts is a
complete remodeling of the TLS handshake protocol including a complete remodeling of the TLS handshake protocol including a
different message flow, different handshake messages, different key different message flow, different handshake messages, different key
schedule, different cipher suites, different resumption, and schedule, different cipher suites, different resumption, and
different privacy protection. This means that significant parts of different privacy protection. This means that significant parts of
skipping to change at page 3, line 29 skipping to change at page 3, line 32
to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). 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 achieved without any additional round-trips, and TLS 1.3 Privacy is mandatory and achieved without any additional round-trips,
introduces more possibilities to reduce fragmentation when compared revocation checking is mandatory and easy with OCSP stapling, and TLS
to earlier versions of TLS. 1.3 introduces more possibilities to reduce fragmentation when
compared to earlier versions of TLS.
1.1. Requirements and Terminology 1.1. Requirements and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts used Readers are expected to be familiar with the terms and concepts used
in EAP-TLS [RFC5216] and TLS 1.3 [RFC8446]. in EAP-TLS [RFC5216] and TLS [RFC8446].
2. Protocol Overview 2. Protocol Overview
2.1. Overview of the EAP-TLS Conversation 2.1. Overview of the EAP-TLS Conversation
2.1.1. Base Case 2.1.1. Base Case
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 [RFC5216] does not apply for TLS 1.3 (or higher). of RFC5216 [RFC5216] does not apply for TLS 1.3 (or higher).
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
skipping to change at page 4, line 25 skipping to change at page 4, line 30
be done as specified in that version of TLS. This document only be done as specified in that version of TLS. This document only
lists additional and different requirements, restrictions, and lists additional and different requirements, restrictions, and
processing compared to [RFC8446] and [RFC5216]. processing compared to [RFC8446] and [RFC5216].
The EAP server MUST authenticate with a certificate and SHOULD The EAP server MUST authenticate with a certificate and SHOULD
require the EAP peer to authenticate with a certificate. require the EAP peer to authenticate with a certificate.
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. SessionID is deprecated in TLS 1.3 and the EAP for resumption. SessionID is deprecated in TLS 1.3 and the EAP
server SHALL ignore the legacy_session_id field if TLS 1.3 is server SHALL ignore the legacy_session_id field if TLS 1.3 is
negotiated. Resumption is handled as described in Section 2.1.2. negotiated. TLS 1.3 introduces early application data; early
After the TLS handshake has completed and all Post-Handshake messages application data SHALL NOT be used with EAP-TLS. Resumption is
have been sent, the EAP server sends EAP-Success. handled as described in Section 2.1.2. After the TLS handshake has
completed and all Post-Handshake messages have been sent, the EAP
As stated in [RFC5216], the TLS cipher suite shall not be used to server sends EAP-Success.
protect application data. This applies also for early application
data. When EAP-TLS is used with TLS 1.3, early application data
SHALL NOT be used.
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 an empty
TLS record, see Section 2.5. TLS record, see Section 2.5.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Anonymous NAI) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
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 CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS empty record) <-------- TLS empty record)
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
In the case where EAP-TLS is used without peer authentication (e.g.,
emergency services, as described in [RFC7406]) the conversation will
appear as shown in Figure 2.
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 Certificate,
TLS CertificateVerify,
TLS Finished,
<-------- TLS empty record)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Finished) -------->
<-------- EAP-Success
Figure 2: EAP-TLS without peer authentication
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
of resumption in the initial authentication. To indicate support of of resumption in the initial authentication. To indicate support of
resumption, the EAP server sends a NewSessionTicket message resumption, the EAP server sends a NewSessionTicket message
(containing a PSK and other parameters) after it has received the (containing a PSK and other parameters) after it has received the
Finished message. Finished message.
In the case where EAP-TLS with mutual authentication and ticket In the case where EAP-TLS with mutual authentication and ticket
establishment is successful, the conversation will appear as shown in establishment is successful, the conversation will appear as shown in
Figure 2. Figure 3.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Anonymous NAI) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
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 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
(TLS NewSessionTicket, (TLS NewSessionTicket,
<-------- TLS empty record) <-------- TLS empty record)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 2: EAP-TLS ticket establishment Figure 3: EAP-TLS ticket establishment
2.1.2. Resumption 2.1.2. 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
TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism
compatible with that version of TLS. compatible with that version of TLS.
For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If
the client has received a NewSessionTicket message from the server, the client has received a NewSessionTicket message from the server,
skipping to change at page 7, line 12 skipping to change at page 8, line 12
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 an EAP peer SHOULD use resumption as long as it has a valid but an EAP peer SHOULD use resumption as long as it has a valid
ticket cached. It is RECOMMENDED that the EAP server accept ticket cached. It is RECOMMENDED that the EAP server accept
resumption as long as the ticket is valid. However, the server MAY resumption as long as the ticket is valid. However, the server MAY
choose to require a full authentication. choose to require a full authentication.
A subsequent authentication using resumption, where both sides A subsequent authentication using resumption, where both sides
authenticate successfully is shown in Figure 3. authenticate successfully is shown in Figure 4.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Anonymous NAI) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
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 empty record)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
<-------- EAP-Success <-------- EAP-Success
Figure 3: EAP-TLS resumption Figure 4: 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
handshake. The message flow in this case is given by Figure 1 or handshake. The message flow in this case is given by Figure 1 or
Figure 2. If the EAP peer did not supply a "key_share" extension Figure 3. If the EAP peer did not supply a "key_share" extension
when offering resumption, the EAP server needs to reject the 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 4 followed by Figure 1 message flow in this case is given by Figure 5 followed by Figure 1
or Figure 2. or Figure 3.
2.1.3. Termination 2.1.3. Termination
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, some normative text compared to earlier versions of TLS. Therefore, some normative text
in Section 2.1.3 of RFC 5216 [RFC5216] does not apply for TLS 1.3 or in Section 2.1.3 of RFC 5216 [RFC5216] does not apply for TLS 1.3 or
higher. The two paragraphs below replaces the corresponding higher. The two paragraphs below replaces the corresponding
paragraphs in Section 2.1.3 of RFC 5216 [RFC5216] when EAP-TLS is paragraphs in Section 2.1.3 of RFC 5216 [RFC5216] when EAP-TLS is
used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3
of RFC 5216 [RFC5216] still apply with the exception that SessionID of RFC 5216 [RFC5216] still apply with the exception that SessionID
skipping to change at page 8, line 25 skipping to change at page 9, line 25
If the EAP server authenticates successfully, the EAP peer MUST If the EAP server authenticates successfully, the EAP peer MUST
send an EAP-Response message with EAP-Type=EAP-TLS containing TLS send an EAP-Response message with EAP-Type=EAP-TLS containing TLS
records conforming to the version of TLS used. records conforming to the version of TLS used.
If the EAP peer authenticates successfully, the EAP server MUST If the EAP peer authenticates successfully, the EAP server MUST
send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS
records conforming to the version of TLS used. The message flow records conforming to the version of TLS used. The message flow
ends with the EAP server sending an EAP-Success message. ends with the EAP server sending an EAP-Success message.
Figures 4, 5, 6, and 7 illustrate message flows in several cases Figures 5, 6, 7, and 8 illustrate message flows in several cases
where the EAP peer or EAP server sends a TLS fatal alert message. where the EAP peer or EAP server sends a TLS fatal alert message.
TLS warning alerts generally mean that the connection can continue TLS warning alerts generally mean that the connection can continue
normally and does not change the message flow. Note that the party normally and does not change the message flow. Note that the party
receiving a TLS warning alert may choose to terminate the connection receiving a TLS warning alert may choose to terminate the connection
by sending a TLS fatal alert, which may add an extra round-trip, see by sending a TLS fatal alert, which may add an extra round-trip, see
[RFC8446]. [RFC8446].
In the case where the server rejects the ClientHello, the In the case where the server rejects the ClientHello, the
conversation will appear as shown in Figure 4. conversation will appear as shown in Figure 5.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Anonymous NAI) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
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 Fatal Alert) <-------- (TLS Fatal Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 4: EAP-TLS server rejection of ClientHello Figure 5: EAP-TLS server rejection of ClientHello
In the case where server authentication is unsuccessful, the In the case where server authentication is unsuccessful, the
conversation will appear as shown in Figure 5. conversation will appear as shown in Figure 6.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Anonymous NAI) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
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 CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS empty record) <-------- TLS empty record)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Fatal Alert) (TLS Fatal Alert)
--------> -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 5: EAP-TLS unsuccessful server authentication Figure 6: 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
will appear as shown in Figure 6. will appear as shown in Figure 7.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Anonymous NAI) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
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 CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS empty record) <-------- TLS empty record)
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 -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 6: EAP-TLS unsuccessful client authentication Figure 7: EAP-TLS unsuccessful client authentication
In the case where the client rejects a NewSessionTicket, the In the case where the client rejects a NewSessionTicket, the
conversation will appear as shown in Figure 7. conversation will appear as shown in Figure 8.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Anonymous NAI) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
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 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
(TLS NewSessionTicket, (TLS NewSessionTicket,
<-------- TLS empty record) <-------- TLS empty record)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Fatal Alert) (TLS Fatal Alert)
--------> -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 7: EAP-TLS client rejection of NewSessionTicket Figure 8: EAP-TLS client rejection of NewSessionTicket
2.1.4. Privacy 2.1.4. 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 solutions where the username is use anonymous NAIs, but other privacy-friendly identities (e.g.
encrypted MAY be used. encrypted usernames) MAY be used.
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 or perform a second handshake need to send an empty certificate_list or perform a second handshake
(as needed by EAP-TLS with earlier versions of TLS). When EAP-TLS is (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 and EAP-TLS used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS
server SHALL follow the processing specified by the used version of server SHALL follow the processing specified by the used version of
TLS. For TLS 1.3 this means that the EAP-TLS peer only sends an 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 certificate empty certificate_list if it does not have an appropriate certificate
to send, and the EAP-TLS server MAY treat an empty certificate_list to send, and the EAP-TLS server MAY treat an empty certificate_list
as a terminal condition. as a terminal condition.
EAP-TLS with TLS 1.3 is always used with privacy since this does not EAP-TLS with TLS 1.3 is always used with privacy. This does not add
add any extra round-trips and the message flow with privacy is just any extra round-trips and the message flow with privacy is just the
the normal message flow as shown in Figure 1. normal message flow as shown in Figure 1.
2.1.5. Fragmentation 2.1.5. Fragmentation
Including ContentType and ProtocolVersion a single TLS record may be Including ContentType and ProtocolVersion a single TLS record may be
up to 16387 octets in length. Some EAP implementations and access up to 16387 octets in length. EAP-TLS fragmentation support is
networks may limit the number of EAP packet exchanges that can be provided through addition of a flags octet within the EAP-Response
handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes and EAP-Request packets, as well as a TLS Message Length field of
of client, server, and trust anchor certificates small and the length four octets. Unfragmented messages MAY have the L bit set and
of the certificate chains short. In addition, it is RECOMMENDED to include the length of the message (though this information is
use mechanisms that reduce the sizes of Certificate messages. redundant).
Some EAP implementations and access networks may limit the number of
EAP packet exchanges that can be handled. To avoid fragmentation, it
is RECOMMENDED to keep the sizes of client, server, and trust anchor
certificates small and the length of the certificate chains short.
In addition, it is RECOMMENDED to use mechanisms that reduce the
sizes of Certificate messages.
While Elliptic Curve Cryptography (ECC) was optional for earlier While Elliptic Curve Cryptography (ECC) was optional for earlier
version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of
[RFC8446]). To avoid fragmentation, the use of ECC in certificates, [RFC8446]). To avoid fragmentation, the use of ECC in certificates,
signature algorithms, and groups are RECOMMENDED when using EAP-TLS signature algorithms, and groups are RECOMMENDED when using EAP-TLS
with TLS 1.3 or higher. At a 128-bit security level, this reduces with TLS 1.3 or higher. At a 128-bit security level, this reduces
public key sizes from 384 bytes (RSA and DHE) to 32 bytes (ECDHE) and public key sizes from 384 bytes (RSA and DHE) to 32-64 bytes (ECDHE)
signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). An and signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA).
EAP-TLS deployment MAY further reduce the certificate sizes by An EAP-TLS deployment MAY further reduce the certificate sizes by
limiting the number of Subject Alternative Names. limiting the number of Subject Alternative Names.
Endpoints SHOULD reduce the sizes of Certificate messages by omitting Endpoints SHOULD reduce the sizes of Certificate messages by omitting
certificates that the other endpoint is known to possess. When using certificates that the other endpoint is known to possess. When using
TLS 1.3, all certificates that specifies a trust anchor may be TLS 1.3, all certificates that specifies a trust anchor may be
omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or
earlier, only the self-signed certificate that specifies the root earlier, only the self-signed certificate that specifies the root
certificate authority may be omitted (see Section 7.4.2 of certificate authority may be omitted (see Section 7.4.2 of
[RFC5246]). EAP-TLS peers and servers SHOULD support and use the [RFC5246]). EAP-TLS peers and servers SHOULD support and use the
Cached Information Extension as specified in [RFC7924]. EAP-TLS Cached Information Extension as specified in [RFC7924]. EAP-TLS
peers and servers MAY use other extensions for reducing the sizes of peers and servers MAY use other extensions for reducing the sizes of
Certificate messages, e.g. certificate compression Certificate messages, e.g. certificate compression
[I-D.ietf-tls-certificate-compression]. [I-D.ietf-tls-certificate-compression].
2.2. Identity Verification 2.2. Identity Verification
No updates to [RFC5216]. The identity provided in the EAP-Response/Identity is not
authenticated by EAP-TLS. Unauthenticated information SHALL NOT be
used for accounting purposes or to give authorization. The
authenticator and the EAP server MAY examine the identity presented
in EAP-Response/Identity for purposes such as routing and EAP method
selection. They MAY reject conversations if the identity does not
match their policy. Note that this also applies to resumption, see
Sections 2.1.2, 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].
When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, When EAP-TLS is used with TLS version 1.3 or higher the Key_Material,
IV, and Method-Id SHALL be derived from the exporter_master_secret IV, and Method-Id SHALL be derived from the exporter_master_secret
using the TLS exporter interface [RFC5705] (for TLS 1.3 this is using the TLS exporter interface [RFC5705] (for TLS 1.3 this is
defined in Section 7.5 of [RFC8446]). defined in Section 7.5 of [RFC8446]).
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128) Type-Code = 0x0D
IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64) Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", "", 64) Type-Code, 128)
Session-Id = 0x0D || Method-Id IV = TLS-Exporter("EXPORTER_EAP_TLS_IV",
Type-Code, 64)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
Type-Code, 64)
Session-Id = Type-Code || Method-Id
All other parameters such as MSK and EMSK are derived in the same
manner as with EAP-TLS [RFC5216], Section 2.3. The definitions are
repeated below for simplicity:
MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127)
Enc-RECV-Key = MSK(0, 31)
Enc-SEND-Key = MSK(32, 63)
RECV-IV = IV(0, 31)
SEND-IV = IV(32, 63)
The use of these keys is specific to the lower layer, as described
[RFC5247].
Note that the key derivation MUST use the length values given above.
Where in TLS 1.2 and earlier it was possible to truncate the output
by requesting less data from the TLS-Exporter function, this practice
is not possible with TLS 1.3. If an implementation intends to use
only part of the output of the TLS-Exporter function, then it MUST
ask for the full output, and then only use part of that output.
Failure to do so will result in incorrect values being calculated for
the above keying material.
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
without having to extract the Master Secret, ClientHello.random, and without having to extract the Master Secret, ClientHello.random, and
ServerHello.random in a non-standard way. ServerHello.random in a non-standard way.
All other parameters such as MSK and EMSK are derived as specified in Other TLS-based EAP methods can perform similar key derivations by
EAP-TLS [RFC5216], Section 2.3. The use of these keys is specific to replacing the Type-Code with the value of their EAP type. The Type-
the lower layer, as described [RFC5247]. Code is defined to be 1 octet for values smaller than 256, otherwise
it is a 32-bit number (four octets), in network byte order.
Additional discussion of other EAP methods is outside of the scope of
this document.
2.4. Parameter Negotiation and Compliance Requirements 2.4. Parameter Negotiation and Compliance Requirements
TLS 1.3 cipher suites are defined differently than in earlier TLS 1.3 cipher suites are defined differently than in earlier
versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites
discussed in Section 2.4 of [RFC5216] can therefore not be used when discussed in Section 2.4 of [RFC5216] can therefore not be used when
EAP-TLS is used with TLS version 1.3 or higher. The requirements on EAP-TLS is used with TLS version 1.3 or higher. The requirements on
protocol version and compression given in Section 2.4 of [RFC5216] protocol version and compression given in Section 2.4 of [RFC5216]
still apply. still apply.
When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS
peers and servers MUST comply with the requirements for the TLS peers and servers MUST comply with the compliance requirements
version used. For TLS 1.3 the compliance requirements are defined in (mandatory-to-implement cipher suites, signature algorithms, key
Section 9 of [RFC8446]. exchange algorithms, extensions, etc.) for the TLS version used. For
TLS 1.3 the compliance requirements are defined in Section 9 of
[RFC8446].
While EAP-TLS does not protect any application data, the negotiated
cipher suites and algorithms MAY be used to secure data as done in
other TLS-based EAP methods.
2.5. EAP State Machines 2.5. EAP State Machines
TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post-
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
skipping to change at page 15, line 25 skipping to change at page 17, line 29
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 appending an empty application data record (i.e. a TLS
record with TLSPlaintext.type = application_data and record with TLSPlaintext.type = application_data and
TLSPlaintext.length = 0) to the last handshake record. After sending TLSPlaintext.length = 0) to the last handshake record. After sending
an empty application data record, the EAP server may only send an an empty application data record, the EAP server may only send an
EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
Message. Message.
Note that the use of an empty application data record does not
violate the requirement that the TLS cipher suite shall not be used
to protect application data, as the application data is the empty
string, no application data is protected.
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 16, line 14 skipping to change at page 18, line 14
5. Security Considerations 5. Security Considerations
5.1. Security Claims 5.1. Security Claims
Using EAP-TLS with TLS 1.3 does not change the security claims for Using EAP-TLS with TLS 1.3 does not change the security claims for
EAP-TLS as given in Section 4.1 of [RFC5216]. However, it EAP-TLS as given in Section 4.1 of [RFC5216]. However, it
strengthens several of the claims as described in the following strengthens several of the claims as described in the following
updates to the notes given in Section 4.1 of [RFC5216]. updates to the notes given in Section 4.1 of [RFC5216].
[1] Mutual authentication: By mandating revocation checking of
certificates, the authentication in EAP-TLS with TLS 1.3 is stronger
as authentication with revoked certificates will always fail.
[2] Confidentiality: The TLS 1.3 handshake offers much better [2] Confidentiality: The TLS 1.3 handshake offers much better
confidentiality than earlier versions of TLS by mandating cipher confidentiality than earlier versions of TLS by mandating cipher
suites with confidentiality and encrypting certificates and some of suites with confidentiality and encrypting certificates and some of
the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the
use of privacy is mandatory and does not cause any additional round- use of privacy is mandatory and does not cause any additional round-
trips. trips.
[3] Key strength: TLS 1.3 forbids all algorithms with known [3] Key strength: TLS 1.3 forbids all algorithms with known
weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3
only supports cryptographic algorithms offering at least 112-bit only supports cryptographic algorithms offering at least 112-bit
skipping to change at page 16, line 42 skipping to change at page 18, line 46
5.2. Peer and Server Identities 5.2. Peer and Server Identities
No updates to [RFC5216]. No updates to [RFC5216].
5.3. Certificate Validation 5.3. Certificate Validation
No updates to [RFC5216]. No updates to [RFC5216].
5.4. Certificate Revocation 5.4. Certificate Revocation
While certificates often have a long validity period spanning several
years, there are a number of reasons (e.g. key compromise, CA
compromise, privilege withdrawn, etc.) why client, server, or sub-CA
certificates have to be revoked before their expiry date. Revocation
of the EAP server's certificate is complicated by the fact that the
EAP peer may not have Internet connectivity until authentication
completes.
EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate
Status Requests (OCSP stapling) as specified in [RFC6066] and
Section 4.4.2.1 of [RFC8446]. When EAP-TLS is used with TLS 1.3, the
peer and server MUST use Certificate Status Requests [RFC6066] for
the server's certificate chain and the EAP peer MUST treat a
CertificateEntry (except the trust anchor) without a valid
CertificateStatus extension as invalid and abort the handshake with
an appropriate alert. When EAP-TLS is used with TLS 1.3, the server
MUST check the revocation status of the certificates in the
certificates in the client's certificate chain.
The OCSP status handling in TLS 1.3 is different from earlier The OCSP status handling in TLS 1.3 is different from earlier
versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the
OCSP information is carried in the CertificateEntry containing the OCSP information is carried in the CertificateEntry containing the
associated certificate instead of a separate CertificateStatus associated certificate instead of a separate CertificateStatus
message as in [RFC4366]. This enables sending OCSP information for message as in [RFC4366]. This enables sending OCSP information for
all certificates in the certificate chain. all certificates in the certificate chain.
EAP-TLS peers and servers supporting TLS 1.3 SHOULD support
Certificate Status Requests (OCSP stapling) as specified in [RFC6066]
and Section 4.4.2.1 of [RFC8446]. The use of Certificate Status
Requests to determine the current status of the EAP server's
certificate is RECOMMENDED.
5.5. Packet Modification Attacks 5.5. Packet Modification Attacks
No updates to [RFC5216]. No updates to [RFC5216].
5.6. Privacy Considerations 5.6. Authorization
EAP-TLS may be encapsulated in other protocols, such as PPP
[RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191].
Systems implementing those protocols interact with EAP-TLS and can
make policy decisions and enforce authorization based on information
from the EAP-TLS exchange. The encapsulating protocols can also
provide additional, non-EAP information to the EAP server. This
information can include, but is not limited to, information about the
authenticator, information about the EAP peer, or information about
the protocol layers below EAP (MAC addresses, IP addresses, port
numbers, WiFi SSID, etc.).
As noted in Section 2.2, the identity presented in EAP-Response/
Identity is not authenticated by EAP-TLS and is therefore trivial for
an attacker to forge, modify, or replay. Authorization and
accounting MUST be based on authenticated information such as
information in the certificate or the PSK identity and cached data
provisioned for resumption as described in Section 5.7. Note that
the requirements for Network Access Identifiers (NAIs) specified in
Section 4 of [RFC7542] still apply and MUST be followed.
Policy decisions are often based on a mixture of information from
TLS, EAP, and encapsulating protocols. EAP servers MAY reject
conversations based on examining unauthenticated information such as
an unknown MAC address or an identity provided in in EAP-Response/
Identity that do not match a certain policy.
5.7. Resumption
There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies to all version of TLS.
When resumption occurs, it is based on cached information at the TLS
layer. As described in Section 2.2, the identity provided in the
EAP-Response/Identity is not authenticated by EAP-TLS.
To perform resumption in a secure way, the EAP peer and EAP server
need to be able to securely retrieve information such as certificate
chains, revocation status, and other authorization information from
the initial full handshake. We use the term "cached data" to
describe such information. Authorization during resumption MUST be
based on such cached data. The resumption MAY be rejected based on
examining unauthenticated information.
There are two ways to retrieve the needed information. The first
method is that the TLS server and client caches the information
locally, identified by an identifier and secured by the other party
showing proof-of-position of a key obtained from the initial full
handshake. 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 is via [RFC5077], where the TLS server encapsulates the
information into a ticket and forwards it to the client. The client
can subsequently do resumption using the obtained ticket. Note that
the client still needs to cache the information locally. The
following requirements apply to both methods.
If the EAP server or EAP client do not apply any authorization
policies, they MAY allow resumption where no cached data is
available. In all other cases, they MUST cache data during the
initial full authentication to enable resumption. The cached data
MUST be 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 server expects some
system to perform accounting for the session. Since accounting must
be tied to an authenticated identity, and resumption does not supply
such an identity, accounting is impossible without access to cached
data.
Some information such as IP addresses and the identity provided in
EAP-Response/Identity may change between the initial full handshake
and resumption. This change creates a "Time of check, time of use"
(TOCTOU) security vulnerability. A malicious or compromised user
could supply one set of data during the initial authentication, and a
different set of data during resumption, potentially leading to them
obtaining access that they should not have.
If any authorization, accounting, or policy decisions were made with
information that have changed since the initial full handshake and
resumption, and if change may lead to a different decision, such
decisions MUST be reevaluated. It is RECOMMENDED that authorization,
accounting, and policy decisions are reevaluated based on the
information given in the resumption. EAP servers MAY reject
resumption where the information supplied during resumption does not
match the information supplied during the original authentication.
Where a good decision is unclear, EAP servers SHOULD err on the side
of caution, and therefore reject the resumption.
Any security policies for authorization and revocation MUST be
followed also for resumption. The EAP client and server MAY need to
recheck the authorization and revocation status of the other party.
The certificates may have been revoked since the initial full
handshake and the authorizations of the other party may have been
reduced.
It is difficult to state the above requirements more precisely. If
the EAP server determine that the user is acting maliciously, they
MUST reject the resumption. It's up to each implementation and / or
deploymentment of EAP-TLS to determine which information to examine,
and which policies to apply.
5.8. Privacy Considerations
[RFC6973] suggests that the privacy considerations of IETF protocols [RFC6973] suggests that the privacy considerations of IETF protocols
be documented. be documented.
TLS 1.3 offers much better privacy than earlier versions of TLS as TLS 1.3 offers much better privacy than earlier versions of TLS as
discussed in Section 2.1.4. In this section, we only discuss the discussed in Section 2.1.4. In this section, we only discuss the
privacy properties of EAP-TLS with TLS 1.3. For privacy properties privacy properties of EAP-TLS with TLS 1.3. For privacy properties
of TLS 1.3 itself, see [RFC8446]. of TLS 1.3 itself, see [RFC8446].
EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in
EAP packets. Additionally, the EAP peer sends an identity in the EAP packets. Additionally, the EAP peer sends an identity in the
first EAP-Response. The other fields in the EAP-TLS Request and the first EAP-Response. The other fields in the EAP-TLS Request and the
EAP-TLS Response packets do not contain any cleartext privacy EAP-TLS Response packets do not contain any cleartext privacy
sensitive information. sensitive information.
When EAP-TLS is used with TLS 1.3, the username part of the identity Tracking of users by eavesdropping on identity responses or
response is always confidentiality protected (e.g. using Anonymous certificates is a well-known problem in many EAP methods. When EAP-
NAIs). However, as with other EAP methods, even when privacy- TLS is used with TLS 1.3, all certificates are encrypted, and the
friendly identifiers or EAP tunneling is used, the domain name (i.e. username part of the identity response is always confidentiality
the realm) in the NAI is still typically visible. How much privacy protected (e.g. using Anonymous NAIs). However, as with other EAP
sensitive information the domain name leaks is highly dependent on methods, even when privacy-friendly identifiers or EAP tunneling is
how many other users are using the same domain name in the particular used, the domain name (i.e. the realm) in the NAI is still typically
access network. If all EAP peers have the same domain, no additional visible. How much privacy sensitive information the domain name
information is leaked. If a domain name is used by a small subset of leaks is highly dependent on how many other users are using the same
the EAP peers, it may aid an attacker in tracking or identifying the domain name in the particular access network. If all EAP peers have
user. the same domain, no additional information is leaked. If a domain
name is used by a small subset of the EAP peers, it may aid an
attacker in tracking or identifying the user.
An EAP peer with a policy allowing communication with EAP servers If Anonymous NAIs are not used, the privacy-friendly identifiers need
supporting only TLS 1.2 (or lower) without privacy and with RSA key to be generated with care. The identities MUST be generated in a
exchange is vulnerable to disclosure of the peer username. An active cryptographically secure way so that that it is computationally
attacker can in this case make the EAP peer believe that an EAP infeasible for an attacker to differentiate two identities belonging
server supporting TLS 1.3 only supports TLS 1.2 (or lower) without to the same user from two identities belonging to different users in
privacy. The attacker can simply impersonate the EAP server and the same realm. This can be achieved, for instance, by using random
negotiate TLS 1.2 (or lower) with RSA key exchange and send an TLS or pseudo-random usernames such as random byte strings or
alert message when the EAP peer tries to use privacy by sending an ciphertexts. Note that the privacy-friendly usernames also MUST NOT
empty certificate message. Since the attacker (impersonating the EAP include substrings that can be used to relate the identity to a
server) does not provide a proof-of-possession of the private key specific user. Similarly, privacy-friendly username SHOULD NOT be
until the Finished message when RSA key exchange is used, an EAP peer formed by a fixed mapping that stays the same across multiple
may inadvertently disclose its identity (username) to an attacker. different authentications.
Therefore, it is RECOMMENDED for EAP peers to not use EAP-TLS with An EAP peer with a policy allowing communication with EAP servers
TLS 1.2 (or lower) and RSA based cipher suites without privacy. supporting only TLS 1.2 (or lower) without privacy and with a static
RSA key exchange is vulnerable to disclosure of the peer username.
An active attacker can in this case make the EAP peer believe that an
EAP server supporting TLS 1.3 only supports TLS 1.2 (or lower)
without privacy. The attacker can simply impersonate the EAP server
and negotiate TLS 1.2 (or lower) with static RSA key exchange and
send an TLS alert message when the EAP peer tries to use privacy by
sending an empty certificate message. Since the attacker
(impersonating the EAP server) does not provide a proof-of-possession
of the private key until the Finished message when a static RSA key
exchange is used, an EAP peer may inadvertently disclose its identity
(username) to an attacker. Therefore, it is RECOMMENDED for EAP
peers to not use EAP-TLS with TLS 1.2 (or lower) and RSA based cipher
suites without privacy.
5.7. Pervasive Monitoring 5.9. Pervasive Monitoring
As required by [RFC7258], work on IETF protocols needs to consider As required by [RFC7258], work on IETF protocols needs to consider
the effects of pervasive monitoring and mitigate them when possible. the effects of pervasive monitoring and mitigate them when possible.
Pervasive Monitoring is widespread surveillance of users. By Pervasive Monitoring is widespread surveillance of users. By
encrypting more information and by mandating the use of privacy, TLS encrypting more information and by mandating the use of privacy, TLS
1.3 offers much better protection against pervasive monitoring. In 1.3 offers much better protection against pervasive monitoring. In
addition to the privacy attacks discussed above, surveillance on a addition to the privacy attacks discussed above, surveillance on a
large scale may enable tracking of a user over a wider geographical large scale may enable tracking of a user over a wider geographical
area and across different access networks. Using information from area and across different access networks. Using information from
EAP-TLS together with information gathered from other protocols EAP-TLS together with information gathered from other protocols
increases the risk of identifying individual users. increases the risk of identifying individual users.
5.10. Discovered Vulnerabilities
Over the years, there have been several serious attacks on earlier
versions of Transport Layer Security (TLS), including attacks on its
most commonly used ciphers and modes of operation. [RFC7457]
summarizes the attacks that were known at the time of publishing and
[RFC7525] provides recommendations for improving the security of
deployed services that use TLS. However, many of the attacks are
less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and
does not protect any application data. EAP-TLS implementations
SHOULD mitigate known attacks and follow the recommendations in
[RFC7525]. The use of TLS 1.3 mitigates most of the known attacks.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
skipping to change at page 20, line 14 skipping to change at page 25, line 23
[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.0.1 specification", 2017.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<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
Certificate Status Protocol - OCSP", RFC 2560, Certificate Status Protocol - OCSP", RFC 2560,
DOI 10.17487/RFC2560, June 1999, DOI 10.17487/RFC2560, June 1999,
<https://www.rfc-editor.org/info/rfc2560>. <https://www.rfc-editor.org/info/rfc2560>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
DOI 10.17487/RFC3280, April 2002, DOI 10.17487/RFC3280, April 2002,
<https://www.rfc-editor.org/info/rfc3280>. <https://www.rfc-editor.org/info/rfc3280>.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, Network Access Identifier", RFC 4282,
DOI 10.17487/RFC4282, December 2005, DOI 10.17487/RFC4282, December 2005,
<https://www.rfc-editor.org/info/rfc4282>. <https://www.rfc-editor.org/info/rfc4282>.
skipping to change at page 20, line 45 skipping to change at page 26, line 15
[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>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/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>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<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>.
[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>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H.,
and D. Kroeselberg, "Extensions to the Emergency Services
Architecture for Dealing With Unauthenticated and
Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406,
December 2014, <https://www.rfc-editor.org/info/rfc7406>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
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.2.0, September 2018. System", 3GPP TS 33.501 15.3.1, December 2018.
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].
All references to [RFC4282] are updated with [RFC7542]. All references to [RFC4282] are updated with [RFC7542].
Acknowledgments Acknowledgments
The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba, The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba,
Eric Rescorla, Jari Arkko, Jim Schaad, Jouni Malinen, and Vesa Eric Rescorla, Jari Arkko, Jim Schaad, Jouni Malinen, and Vesa
Torvinen for comments and suggestions on the draft. Torvinen for comments and suggestions on the draft.
Contributors
Alan DeKok, FreeRADIUS
Authors' Addresses Authors' Addresses
John Mattsson John 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. 103 change blocks. 
184 lines changed or deleted 464 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/