draft-ietf-emu-eap-tls13-17.txt | draft-ietf-emu-eap-tls13-15.txt | |||
---|---|---|---|---|
Network Working Group J. Preuss 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 June 26, 2021 | Intended status: Standards Track May 4, 2021 | |||
Expires: December 28, 2021 | Expires: November 5, 2021 | |||
Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) | Using EAP-TLS with TLS 1.3 | |||
draft-ietf-emu-eap-tls13-17 | draft-ietf-emu-eap-tls13-15 | |||
Abstract | Abstract | |||
The Extensible Authentication Protocol (EAP), defined in RFC 3748, | The Extensible Authentication Protocol (EAP), defined in RFC 3748, | |||
provides a standard mechanism for support of multiple authentication | provides a standard mechanism for support of multiple authentication | |||
methods. This document specifies the use of EAP-Transport Layer | methods. This document specifies the use of EAP-Transport Layer | |||
Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible | Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible | |||
with existing implementations of EAP-TLS. TLS 1.3 provides | with existing implementations of EAP-TLS. TLS 1.3 provides | |||
significantly improved security, privacy, and reduced latency when | significantly improved security, privacy, and reduced latency when | |||
compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS | compared to earlier versions of TLS. EAP-TLS with TLS 1.3 further | |||
1.3) further improves security and privacy by always providing | improves security and privacy by always providing forward secrecy, | |||
forward secrecy, never disclosing the peer identity, and by mandating | never disclosing the peer identity, and by mandating use of | |||
use of revocation checking. This document also provides guidance on | revocation checking. This document also provides guidance on | |||
authentication, authorization, and resumption for EAP-TLS in general | authorization and resumption for EAP-TLS in general (regardless of | |||
(regardless of the underlying TLS version used). This document | the underlying TLS version used). 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 December 28, 2021. | This Internet-Draft will expire on November 5, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 21 ¶ | skipping to change at page 2, line 21 ¶ | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 | 1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 | |||
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4 | 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4 | |||
2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 6 | 2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 5 | |||
2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 7 | 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 6 | |||
2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 9 | 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 8 | |||
2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 11 | 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 10 | |||
2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14 | 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 13 | |||
2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15 | 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 14 | |||
2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16 | 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 15 | |||
2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 | 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 17 | 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 16 | |||
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18 | 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 17 | |||
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 | 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18 | |||
2.4. Parameter Negotiation and Compliance Requirements . . . . 20 | 2.4. Parameter Negotiation and Compliance Requirements . . . . 19 | |||
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 21 | 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 19 | |||
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 22 | 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 20 | |||
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 | 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | |||
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 22 | 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 21 | |||
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 23 | 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 21 | |||
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 23 | 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 22 | |||
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 23 | 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 22 | |||
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 24 | 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 23 | |||
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 24 | 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 23 | |||
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 25 | 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 27 | 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 26 | |||
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29 | 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 27 | |||
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29 | 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 28 | |||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
6.1. Normative References . . . . . . . . . . . . . . . . . . 29 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 28 | |||
6.2. Informative references . . . . . . . . . . . . . . . . . 31 | 6.2. Informative references . . . . . . . . . . . . . . . . . 29 | |||
Appendix A. Updated references . . . . . . . . . . . . . . . . . 34 | Appendix A. Updated references . . . . . . . . . . . . . . . . . 33 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
1. Introduction | 1. Introduction | |||
The Extensible Authentication Protocol (EAP), defined in [RFC3748], | The Extensible Authentication Protocol (EAP), defined in [RFC3748], | |||
provides a standard mechanism for support of multiple authentication | provides a standard mechanism for support of multiple authentication | |||
methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies | methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies | |||
an EAP authentication method with certificate-based mutual | an EAP authentication method with certificate-based mutual | |||
authentication utilizing the TLS handshake protocol for cryptographic | authentication utilizing the TLS handshake protocol for cryptographic | |||
algorithms and protocol version negotiation and establishment of | algorithms and protocol version negotiation and establishment of | |||
shared secret keying material. EAP-TLS is widely supported for | shared secret keying material. EAP-TLS is widely supported for | |||
skipping to change at page 3, line 39 ¶ | skipping to change at page 3, line 39 ¶ | |||
in large parts a complete remodeling of the TLS handshake protocol | in large parts a complete remodeling of the TLS handshake protocol | |||
including a different message flow, different handshake messages, | including a different message flow, different handshake messages, | |||
different key schedule, different cipher suites, different | different key schedule, different cipher suites, different | |||
resumption, different privacy protection, and different record | resumption, different privacy protection, and different record | |||
padding. This means that significant parts of the normative text in | padding. This means that significant parts of the normative text in | |||
the previous EAP-TLS specification [RFC5216] are not applicable to | the previous EAP-TLS specification [RFC5216] are not applicable to | |||
EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy | EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy | |||
handling, and key derivation need to be appropriately addressed for | handling, and key derivation need to be appropriately addressed for | |||
EAP-TLS with TLS 1.3. | EAP-TLS with TLS 1.3. | |||
This document updates [RFC5216] to define how to use EAP-TLS with TLS | This document defines how to use EAP-TLS with TLS 1.3 and does not | |||
1.3. When older TLS versions are negotiated, RFC 5216 applies to | change how EAP-TLS is used with older versions of TLS. It does | |||
maintain backwards compatibility. However, this document does | however provide additional guidance on authorization and resumption | |||
provide additional guidance on authentication, authorization, and | for EAP-TLS in general (regardless of the underlying TLS version | |||
resumption for EAP-TLS regardless of the underlying TLS version used. | used). While this document updates EAP-TLS [RFC5216], it remains | |||
backwards compatible with it and existing implementations of EAP-TLS. | ||||
This document only describes differences compared to [RFC5216]. All | This document only describes differences compared to [RFC5216]. All | |||
message flow are example message flows specific to TLS 1.3 and do not | message flow are example message flows specific to TLS 1.3 and do not | |||
apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state | apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state | |||
machine with the EAP state machine it is possible that new versions | machine with the EAP state machine it is possible that new versions | |||
of TLS will cause incompatibilities that introduce failures or | of TLS will cause incompatibilities that introduce failures or | |||
security issues if they are not carefully integrated into the EAP-TLS | security issues if they are not carefully integrated into the EAP-TLS | |||
protocol. Therefore, implementations MUST limit the maximum TLS | protocol. Therefore, implementations MUST limit the maximum TLS | |||
version they use to 1.3, unless later versions are explicitly enabled | version they use to 1.3, unless later versions are explicitly enabled | |||
by the administrator. | by the administrator. | |||
This document specifies EAP-TLS 1.3 and does not specify how other | This document specifies EAP-TLS 1.3 and does not specify how other | |||
TLS-based EAP methods use TLS 1.3. The specification for how other | TLS-based EAP methods use TLS 1.3. The specification for how other | |||
TLS-based EAP methods use TLS 1.3 is left to other documents such as | TLS-based EAP methods use TLS 1.3 is left to other documents such as | |||
[I-D.ietf-emu-tls-eap-types]. | [I-D.ietf-emu-tls-eap-types]. | |||
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, which in EAP-TLS means that no information about the | Privacy, which in EAP-TLS means that the peer username is not | |||
underlying peer identity is disclosed, is mandatory and achieved | disclosed, is mandatory and achieved without any additional round- | |||
without any additional round-trips. Revocation checking is mandatory | trips. Revocation checking is mandatory and simplified with OCSP | |||
and simplified with OCSP stapling, and TLS 1.3 introduces more | stapling, and TLS 1.3 introduces more possibilities to reduce | |||
possibilities to reduce fragmentation when compared to earlier | fragmentation when compared to earlier versions of TLS. | |||
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 [RFC8446]. The term EAP-TLS peer is | in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is | |||
used for the entity acting as EAP peer and TLS client. The term EAP- | used for the entity acting as EAP peer and TLS client. The term EAP- | |||
TLS server is used for the entity acting as EAP server and TLS | TLS server is used for the entity acting as EAP server and TLS | |||
server. | server. | |||
Readers are expected to be familiar with the terms and concepts used | ||||
in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is | ||||
used for the entity acting as EAP peer and TLS client. The term EAP- | ||||
TLS server is used for the entity acting as EAP server and TLS | ||||
server. | ||||
This document follows the terminology from [I-D.ietf-tls-rfc8446bis] | ||||
where the master secret is renamed to the main secret and the | ||||
exporter_master_secret is renamed to the exporter_secret. | ||||
2. Protocol Overview | 2. Protocol Overview | |||
2.1. Overview of the EAP-TLS Conversation | 2.1. Overview of the EAP-TLS Conversation | |||
This section updates Section 2.1 of [RFC5216]. | This section updates Section 2.1 of [RFC5216]. | |||
If the TLS implementation correctly implements TLS version | ||||
negotiation, EAP-TLS will automatically leverage that capability. | ||||
The EAP-TLS implementation needs to know which version of TLS was | ||||
negotiated to correctly support EAP-TLS 1.3 as well as to maintain | ||||
backward compatibility with EAP-TLS 1.2. | ||||
TLS 1.3 changes both the message flow and the handshake messages | TLS 1.3 changes both the message flow and the handshake messages | |||
compared to earlier versions of TLS. Therefore, much of Section 2.1 | compared to earlier versions of TLS. Therefore, much of Section 2.1 | |||
of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and | of [RFC5216] does not apply for TLS 1.3. | |||
5.7 this document applies only when TLS 1.3 is negotiated. When TLS | ||||
1.2 is negotiated, then [RFC5216] applies. | ||||
TLS 1.3 introduces several new handshake messages including | ||||
HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general, | ||||
these messages will be handled by the underlying TLS libraries and | ||||
are not visible to EAP-TLS, however there are a few things to note: | ||||
o The HelloRetryRequest is used by the server to reject the | ||||
parameters offered in the ClientHello and suggest new parameters. | ||||
When this message is encountered it will increase the number of | ||||
round trips used by the protocol. | ||||
o The NewSessionTicket message is used to convey resumption | ||||
information and is covered in Sections 2.1.2 and 2.1.3. | ||||
o The KeyUpdate message is used to update the traffic keys used on a | ||||
TLS connection. EAP-TLS does not encrypt significant amounts of | ||||
data so this functionality is not needed. Implementations SHOULD | ||||
NOT send this message, however some TLS libraries may | ||||
automatically generate and process this message. | ||||
o Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT | ||||
send an early_data extension and clients MUST NOT send an | ||||
EndOfEarlyData message. | ||||
o Servers MUST NOT request post-handshake client authentication. | ||||
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as | After receiving an EAP-Request packet with EAP-Type=EAP-TLS as | |||
described in [RFC5216] the conversation will continue with the TLS | described in [RFC5216] the conversation will continue with the TLS | |||
handshake protocol encapsulated in the data fields of EAP-Response | handshake protocol encapsulated in the data fields of EAP-Response | |||
and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, | and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, | |||
the formatting and processing of the TLS handshake SHALL be done as | the formatting and processing of the TLS handshake SHALL be done as | |||
specified in version 1.3 of TLS. This document only lists additional | specified in version 1.3 of TLS. This document only lists additional | |||
and different requirements, restrictions, and processing compared to | and different requirements, restrictions, and processing compared to | |||
[RFC8446] and [RFC5216]. | [RFC8446] and [RFC5216]. | |||
2.1.1. Authentication | 2.1.1. Authentication | |||
This section updates Section 2.1.1 of [RFC5216]. | This section updates Section 2.1.1 of [RFC5216]. | |||
The EAP-TLS server MUST authenticate with a certificate and SHOULD | The EAP-TLS server MUST authenticate with a certificate and SHOULD | |||
require the EAP-TLS peer to authenticate with a certificate. | require the EAP-TLS 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. The full handshake in EAP-TLS with TLS 1.3 always | for resumption. The full handshake in EAP-TLS with TLS 1.3 always | |||
provides forward secrecy by exchange of ephemeral "key_share" | provide forward secrecy by exchange of ephemeral "key_share" | |||
extensions in the ClientHello and ServerHello (e.g. containing | extensions in the ClientHello and ServerHello (e.g. containing | |||
ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3, | ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3, | |||
see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early | see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early | |||
application data which like all other application data is not used in | application data which like all other application data is not used in | |||
EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information | EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information | |||
of the "early_data" extension. Resumption is handled as described in | of the "early_data" extension. Resumption is handled as described in | |||
Section 2.1.3. As a protected success indication [RFC3748] the EAP- | Section 2.1.3. TLS 1.3 introduced the Post-Handshake KeyUpdate | |||
TLS server always sends TLS application data 0x00, see Section 2.5. | message which is not useful and not expected in EAP-TLS. As a | |||
Note that a TLS implementation MAY not allow the EAP-TLS layer to | protected success indication [RFC3748] the EAP-TLS server always | |||
control in which order things are sent and the application data MAY | sends TLS application data 0x00, see Section 2.5. Note that a TLS | |||
therefore be sent before a NewSessionTicket. TLS application data | implementation MAY not allow the EAP-TLS layer to control in which | |||
0x00 is therefore to be interpreted as success after the EAP-Request | order things are sent and the application data MAY therefore be sent | |||
that contains TLS application data 0x00. After the EAP-TLS server | before a NewSessionTicket. TLS application data 0x00 is therefore to | |||
has sent an EAP-Request containing the TLS application data 0x00 and | be interpreted as success after the EAP-Request that contains TLS | |||
received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the | application data 0x00. After the EAP-TLS server has received an | |||
EAP-TLS server sends EAP-Success. | empty EAP-Response to the EAP-Request containing the TLS application | |||
data 0x00, the EAP-TLS server sends EAP-Success. | ||||
Figure 1 shows an example message flow for a successful EAP-TLS full | Figure 1 shows an example message flow for a successful EAP-TLS full | |||
handshake with mutual authentication (and neither HelloRetryRequest | handshake with mutual authentication (and neither HelloRetryRequest | |||
nor Post-Handshake messages are sent). | nor Post-Handshake messages are sent). | |||
EAP-TLS Peer EAP-TLS Server | EAP-TLS Peer EAP-TLS Server | |||
EAP-Request/ | EAP-Request/ | |||
<-------- Identity | <-------- Identity | |||
EAP-Response/ | EAP-Response/ | |||
Identity (Privacy-Friendly) --------> | 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 Application Data 0x00) | <-------- TLS Application Data 0x00) | |||
EAP-Response/ | EAP-Response/ | |||
EAP-Type=EAP-TLS --------> | EAP-Type=EAP-TLS --------> | |||
<-------- EAP-Success | <-------- EAP-Success | |||
Figure 1: EAP-TLS mutual authentication | Figure 1: EAP-TLS mutual authentication | |||
2.1.2. Ticket Establishment | 2.1.2. Ticket Establishment | |||
This is a new section when compared to [RFC5216]. | This is a new section when compared to [RFC5216]. | |||
To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS | To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS | |||
server MUST send one or more Post-Handshake NewSessionTicket messages | server MUST send one or more Post-Handshake NewSessionTicket messages | |||
(each associated with a PSK, a PSK identity, a ticket lifetime, and | (each associated with a PSK, a PSK identity, a ticket lifetime, and | |||
skipping to change at page 8, line 21 ¶ | skipping to change at page 7, line 21 ¶ | |||
clients can specify the desired number of tickets needed for future | clients can specify the desired number of tickets needed for future | |||
connections is defined in [I-D.ietf-tls-ticketrequests]. | connections is defined in [I-D.ietf-tls-ticketrequests]. | |||
Figure 2 shows an example message flow for a successful EAP-TLS full | Figure 2 shows an example message flow for a successful EAP-TLS full | |||
handshake with mutual authentication and ticket establishment of a | handshake with mutual authentication and ticket establishment of a | |||
single ticket. | single ticket. | |||
EAP-TLS Peer EAP-TLS Server | EAP-TLS Peer EAP-TLS 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) | |||
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 Application Data 0x00) | <-------- TLS Application Data 0x00) | |||
EAP-Response/ | EAP-Response/ | |||
EAP-Type=EAP-TLS --------> | EAP-Type=EAP-TLS --------> | |||
<-------- EAP-Success | <-------- EAP-Success | |||
Figure 2: EAP-TLS ticket establishment | Figure 2: EAP-TLS ticket establishment | |||
2.1.3. Resumption | 2.1.3. Resumption | |||
This section updates Section 2.1.2 of [RFC5216]. | This section updates Section 2.1.2 of [RFC5216]. | |||
EAP-TLS is typically used with client authentication and typically | EAP-TLS is typically used with client authentication and typically | |||
fragments the TLS flights into a large number of EAP requests and EAP | fragments the TLS flights into a large number of EAP requests and EAP | |||
responses. Resumption significantly reduces the number of round- | responses. Resumption significantly reduces the number of round- | |||
trips and enables the EAP-TLS server to omit database lookups needed | trips and enables the EAP-TLS server to omit database lookups needed | |||
during a full handshake with client authentication. TLS 1.3 replaces | during a full handshake with client authentication. TLS 1.3 replaces | |||
the session resumption mechanisms in earlier versions of TLS with a | the session resumption mechanisms in earlier versions of TLS with a | |||
new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS | new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS | |||
SHALL use a resumption mechanism compatible with version 1.3 of TLS. | SHALL use a resumption mechanism compatible with version 1.3 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 EAP-TLS | the client has received a NewSessionTicket message from the EAP-TLS | |||
server, the client can use the PSK identity associated with the | server, the client can use the PSK identity associated with the | |||
ticket to negotiate the use of the associated PSK. If the EAP-TLS | ticket to negotiate the use of the associated PSK. If the EAP-TLS | |||
server accepts it, then the resumed session has been deemed to be | server accepts it, then the security context of the new connection is | |||
authenticated, and securely tied to the associated with the prior | tied to the original connection and the key derived from the initial | |||
authentication or resumption. It is up to the EAP-TLS peer to use | handshake is used to bootstrap the cryptographic state instead of a | |||
resumption, but it is RECOMMENDED that the EAP-TLS peer use | full handshake. It is up to the EAP-TLS peer to use resumption, but | |||
resumption if it has a valid ticket that has not been used before. | it is RECOMMENDED that the EAP-TLS peer use resumption if it has a | |||
It is left to the EAP-TLS server whether to accept resumption, but it | valid ticket that has not been used before. It is left to the EAP- | |||
is RECOMMENDED that the EAP-TLS server accept resumption if the | TLS server whether to accept resumption, but it is RECOMMENDED that | |||
ticket which was issued is still valid. However, the EAP-TLS server | the EAP-TLS server accept resumption if the ticket which was issued | |||
MAY choose to require a full handshake. In the case a full handshake | is still valid. However, the EAP-TLS server MAY choose to require a | |||
is required, the negotiation proceeds as if the session was a new | full handshake. As in a full handshake, sending a NewSessionTicket | |||
authentication, and resumption had never been requested. The | during resumption is optional. As described in Appendix C.4 of | |||
requirements of Sections 2.1.1 and 2.1.2 then apply in their | [RFC8446], reuse of a ticket allows passive observers to correlate | |||
entirety. As described in Appendix C.4 of [RFC8446], reuse of a | different connections. EAP-TLS peers and EAP-TLS servers SHOULD | |||
ticket allows passive observers to correlate different connections. | follow the client tracking preventions in Appendix C.4 of [RFC8446]. | |||
EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking | ||||
preventions in Appendix C.4 of [RFC8446]. | ||||
It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the | It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the | |||
same realm during resumption and the original full handshake. This | same realm during resumption and the original full handshake. This | |||
requirement allows EAP packets to be routed to the same destination | requirement allows EAP packets to be routed to the same destination | |||
as the original full handshake. If this recommendation is not | as the original full handshake. If this recommendation is not | |||
followed, resumption is likely impossible. When NAI reuse can be | followed, resumption is likely impossible. When NAI reuse can be | |||
done without privacy implications, it is RECOMMENDED to use the same | done without privacy implications, it is RECOMMENDED to use the same | |||
NAI in the resumption, as was used in the original full handshake | NAI in the resumption, as was used in the original full handshake | |||
[RFC7542]. For example, the NAI @realm can safely be reused since it | [RFC7542]. For example, the NAI @realm can safely be reused since it | |||
does not provide any specific information to associate a user's | does not provide any specific information to associate a user's | |||
skipping to change at page 10, line 4 ¶ | skipping to change at page 8, line 51 ¶ | |||
followed, resumption is likely impossible. When NAI reuse can be | followed, resumption is likely impossible. When NAI reuse can be | |||
done without privacy implications, it is RECOMMENDED to use the same | done without privacy implications, it is RECOMMENDED to use the same | |||
NAI in the resumption, as was used in the original full handshake | NAI in the resumption, as was used in the original full handshake | |||
[RFC7542]. For example, the NAI @realm can safely be reused since it | [RFC7542]. For example, the NAI @realm can safely be reused since it | |||
does not provide any specific information to associate a user's | does not provide any specific information to associate a user's | |||
resumption attempt with the original full handshake. However, | resumption attempt with the original full handshake. However, | |||
reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path | reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path | |||
attacker to associate a resumption attempt with the original full | attacker to associate a resumption attempt with the original full | |||
handshake. The TLS PSK identity is typically derived by the TLS | handshake. The TLS PSK identity is typically derived by the TLS | |||
implementation and may be an opaque blob without a routable realm. | implementation and may be an opaque blob without a routable realm. | |||
The TLS PSK identity on its own is therefore unsuitable as a NAI in | The TLS PSK identity on its own is therefore unsuitable as a NAI in | |||
the Identity Response. | the Identity Response. | |||
Figure 3 shows an example message flow for a subsequent successful | Figure 3 shows an example message flow for a subsequent successful | |||
EAP-TLS resumption handshake where both sides authenticate via a PSK | EAP-TLS resumption handshake where both sides authenticate via a PSK | |||
provisioned via an earlier NewSessionTicket and where the server | provisioned via an earlier NewSessionTicket and where the server | |||
provisions a single new ticket. | provisions a single new ticket. | |||
EAP-TLS Peer EAP-TLS Server | EAP-TLS Peer EAP-TLS 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) | |||
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 NewSessionTicket) | TLS NewSessionTicket) | |||
EAP-Response/ | EAP-Response/ | |||
EAP-Type=EAP-TLS | EAP-Type=EAP-TLS | |||
(TLS Finished) --------> | (TLS Finished) --------> | |||
EAP-Request/ | EAP-Request/ | |||
EAP-Type=EAP-TLS | EAP-Type=EAP-TLS | |||
<-------- (TLS Application Data 0x00) | <-------- TLS Application Data 0x00) | |||
EAP-Response/ | EAP-Response/ | |||
EAP-Type=EAP-TLS --------> | EAP-Type=EAP-TLS --------> | |||
<-------- EAP-Success | <-------- EAP-Success | |||
Figure 3: EAP-TLS resumption | Figure 3: EAP-TLS resumption | |||
As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD | As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD | |||
supply a "key_share" extension when attempting resumption, which | supply a "key_share" extension when attempting resumption, which | |||
allows the EAP-TLS server to potentially decline resumption and fall | allows the EAP-TLS server to potentially decline resumption and fall | |||
back to a full handshake. If the EAP-TLS peer did not supply a | back to a full handshake. If the EAP-TLS peer did not supply a | |||
"key_share" extension when attempting resumption, the EAP-TLS server | "key_share" extension when attempting resumption, the EAP-TLS server | |||
needs to send HelloRetryRequest to signal that additional information | needs to send HelloRetryRequest to signal that additional information | |||
is needed to complete the handshake, and the EAP-TLS peer needs to | is needed to complete the handshake, and the EAP-TLS peer needs to | |||
skipping to change at page 11, line 4 ¶ | skipping to change at page 9, line 50 ¶ | |||
As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD | As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD | |||
supply a "key_share" extension when attempting resumption, which | supply a "key_share" extension when attempting resumption, which | |||
allows the EAP-TLS server to potentially decline resumption and fall | allows the EAP-TLS server to potentially decline resumption and fall | |||
back to a full handshake. If the EAP-TLS peer did not supply a | back to a full handshake. If the EAP-TLS peer did not supply a | |||
"key_share" extension when attempting resumption, the EAP-TLS server | "key_share" extension when attempting resumption, the EAP-TLS server | |||
needs to send HelloRetryRequest to signal that additional information | needs to send HelloRetryRequest to signal that additional information | |||
is needed to complete the handshake, and the EAP-TLS peer needs to | is needed to complete the handshake, and the EAP-TLS peer needs to | |||
send a second ClientHello containing that information. Providing a | send a second ClientHello containing that information. Providing a | |||
"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode | "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode | |||
is also important in order to limit the impact of a key compromise. | is also important in order to limit the impact of a key compromise. | |||
When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning | When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning | |||
that key leakage does not compromise any earlier connections. The | that key leakage does not compromise any earlier connections. It is | |||
"psk_dh_ke" mechanism MUST be used for resumption unless the | RECOMMMENDED to use "psk_dhe_ke" for resumption. | |||
deployment has a local requirement to allow configuration of other | ||||
mechanisms. | ||||
2.1.4. Termination | 2.1.4. Termination | |||
This section updates Section 2.1.3 of [RFC5216]. | This section updates Section 2.1.3 of [RFC5216]. | |||
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 [RFC5216] does not apply for TLS 1.3. The two | in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3. The two | |||
paragraphs below replaces the corresponding paragraphs in | paragraphs below replaces the corresponding paragraphs in | |||
Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3. The | Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3. The | |||
skipping to change at page 11, line 36 ¶ | skipping to change at page 10, line 30 ¶ | |||
flow ends with the EAP-TLS server sending an EAP-Success message. | flow ends with the EAP-TLS server sending an EAP-Success message. | |||
If the EAP-TLS server authenticates successfully, the EAP-TLS peer | If the EAP-TLS server authenticates successfully, the EAP-TLS peer | |||
MUST send an EAP-Response message with EAP-Type=EAP-TLS containing | MUST send an EAP-Response message with EAP-Type=EAP-TLS containing | |||
TLS records conforming to the version of TLS used. | TLS records conforming to the version of TLS used. | |||
Figures 4, 5, and 6 illustrate message flows in several cases where | Figures 4, 5, and 6 illustrate message flows in several cases where | |||
the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message. | the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message. | |||
In earlier versions of TLS, error alerts could be warnings or fatal. | In earlier versions of TLS, error alerts could be warnings or fatal. | |||
In TLS 1.3, error alerts are always fatal and the only alerts sent at | In TLS 1.3, error alerts are always fatal and the only alerts sent at | |||
warning level are "close_notify" and "user_canceled", both of which | warning level are "close_notify" and "user_cancelled", both of which | |||
indicate that the connection is not going to continue normally, see | indicate that the connection is not going to continue normally, see | |||
[RFC8446]. | [RFC8446]. | |||
In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a | In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a | |||
fatal error condition. Failure to send TLS Error alerts means that | fatal error condition. Failure to send TLS Error alerts means that | |||
the peer or server would have no way of determining what went wrong. | the peer or server would have no way of determining what went wrong. | |||
EAP-TLS 1.3 strengthens this requirement. Whenever an implementation | EAP-TLS 1.3 strengthen this requirement. Whenever an implementation | |||
encounters a fatal error condition, it MUST send an appropriate TLS | encounters a fatal error condition, it MUST send an appropriate TLS | |||
Error alert. | Error alert. | |||
Figure 4 shows an example message flow where the EAP-TLS server | Figure 4 shows an example message flow where the EAP-TLS server | |||
rejects the ClientHello with an error alert. The EAP-TLS server can | rejects the ClientHello with an error alert. The EAP-TLS server can | |||
also partly reject the ClientHello with a HelloRetryRequest, see | also partly reject the ClientHello with a HelloRetryRequest, see | |||
Section 2.1.6. | Section 2.1.6. | |||
EAP-TLS Peer EAP-TLS Server | EAP-TLS Peer EAP-TLS 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) | |||
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 Error Alert) | <-------- (TLS Error 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 4: EAP-TLS server rejection of ClientHello | |||
Figure 5 shows an example message flow where EAP-TLS server | Figure 5 shows an example message flow where EAP-TLS server | |||
authentication is unsuccessful and the EAP-TLS peer sends a TLS Error | authentication is unsuccessful and the EAP-TLS peer sends a TLS Error | |||
alert. | alert. | |||
EAP-TLS Peer EAP-TLS Server | EAP-TLS Peer EAP-TLS 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) | |||
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 Error Alert) | (TLS Error Alert) | |||
--------> | --------> | |||
<-------- EAP-Failure | <-------- EAP-Failure | |||
Figure 5: EAP-TLS unsuccessful EAP-TLS server authentication | Figure 5: EAP-TLS unsuccessful EAP-TLS server authentication | |||
Figure 6 shows an example message flow where the EAP-TLS server | Figure 6 shows an example message flow where the EAP-TLS server | |||
authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer | authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer | |||
fails to authenticate to the EAP-TLS server and the server sends a | fails to authenticate to the EAP-TLS server and sends a TLS Error | |||
TLS Error alert. | alert. | |||
EAP-TLS Peer EAP-TLS Server | EAP-TLS Peer EAP-TLS 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) | |||
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 Error Alert) | <-------- (TLS Error 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 6: EAP-TLS unsuccessful client authentication | |||
2.1.5. No Peer Authentication | 2.1.5. No Peer Authentication | |||
This is a new section when compared to [RFC5216]. | This is a new section when compared to [RFC5216]. | |||
Figure 7 shows an example message flow for a successful EAP-TLS full | Figure 7 shows an example message flow for a successful EAP-TLS full | |||
handshake without peer authentication (e.g., emergency services, as | handshake without peer authentication (e.g., emergency services, as | |||
described in [RFC7406]). | described in [RFC7406]). | |||
EAP-TLS Peer EAP-TLS Server | EAP-TLS Peer EAP-TLS 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) | |||
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) | |||
EAP-Response/ | EAP-Response/ | |||
EAP-Type=EAP-TLS | EAP-Type=EAP-TLS | |||
(TLS Finished) --------> | (TLS Finished) --------> | |||
EAP-Request/ | EAP-Request/ | |||
EAP-Type=EAP-TLS | EAP-Type=EAP-TLS | |||
<-------- (TLS Application Data 0x00) | <-------- TLS Application Data 0x00) | |||
EAP-Response/ | EAP-Response/ | |||
EAP-Type=EAP-TLS --------> | EAP-Type=EAP-TLS --------> | |||
<-------- EAP-Success | <-------- EAP-Success | |||
Figure 7: EAP-TLS without peer authentication | Figure 7: EAP-TLS without peer authentication | |||
2.1.6. Hello Retry Request | 2.1.6. Hello Retry Request | |||
This is a new section when compared to [RFC5216]. | This is a new section when compared to [RFC5216]. | |||
As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a | As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a | |||
HelloRetryRequest message in response to a ClientHello if the EAP-TLS | HelloRetryRequest message in response to a ClientHello if the EAP-TLS | |||
server finds an acceptable set of parameters but the initial | server finds an acceptable set of parameters but the initial | |||
skipping to change at page 16, line 8 ¶ | skipping to change at page 15, line 8 ¶ | |||
"supported_groups" extension. In this case the client should send a | "supported_groups" extension. In this case the client should send a | |||
new ClientHello with a "key_share" that the EAP-TLS server supports. | new ClientHello with a "key_share" that the EAP-TLS server supports. | |||
Figure 8 shows an example message flow for a successful EAP-TLS full | Figure 8 shows an example message flow for a successful EAP-TLS full | |||
handshake with mutual authentication and HelloRetryRequest. Note the | handshake with mutual authentication and HelloRetryRequest. Note the | |||
extra round-trip as a result of the HelloRetryRequest. | extra round-trip as a result of the HelloRetryRequest. | |||
EAP-TLS Peer EAP-TLS Server | EAP-TLS Peer EAP-TLS 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) | |||
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 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 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 Application Data 0x00) | <-------- TLS Application Data 0x00) | |||
EAP-Response/ | EAP-Response/ | |||
EAP-Type=EAP-TLS --------> | EAP-Type=EAP-TLS --------> | |||
<-------- EAP-Success | <-------- EAP-Success | |||
Figure 8: EAP-TLS with Hello Retry Request | Figure 8: EAP-TLS with Hello Retry Request | |||
2.1.7. Identity | 2.1.7. Identity | |||
This is a new section when compared to [RFC5216]. | This is a new section when compared to [RFC5216]. | |||
It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity | It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity | |||
Response as such identities are routable and privacy-friendly. While | Response as such identities are routable and privacy-friendly. While | |||
opaque blobs are allowed by [RFC3748], such identities are NOT | opaque blobs are allowed by [RFC3748], such identities are NOT | |||
skipping to change at page 17, line 17 ¶ | skipping to change at page 16, line 17 ¶ | |||
contain an identity such as an email address, which is already in NAI | contain an identity such as an email address, which is already in NAI | |||
format. When the client certificate contains a NAI as subject name | format. When the client certificate contains a NAI as subject name | |||
or alternative subject name, an anonymous NAI SHOULD be derived from | or alternative subject name, an anonymous NAI SHOULD be derived from | |||
the NAI in the certificate, see Section 2.1.8. More details on | the NAI in the certificate, see Section 2.1.8. More details on | |||
identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. | identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. | |||
2.1.8. Privacy | 2.1.8. Privacy | |||
This section updates Section 2.1.4 of [RFC5216]. | This section updates Section 2.1.4 of [RFC5216]. | |||
EAP-TLS 1.3 significantly improves privacy when compared to earlier | TLS 1.3 significantly improves privacy when compared to earlier | |||
versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without | versions of TLS by forbidding cipher suites without confidentiality | |||
confidentiality which means that TLS 1.3 is always encrypting large | and encrypting large parts of the TLS handshake including the | |||
parts of the TLS handshake including the certificate messages. | certificate messages. | |||
EAP-TLS peer and server implementations supporting TLS 1.3 MUST | EAP-TLS peer and server implementations supporting TLS 1.3 MUST | |||
support anonymous Network Access Identifiers (NAIs) (Section 2.4 in | support anonymous Network Access Identifiers (NAIs) (Section 2.4 in | |||
[RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username | [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username | |||
in cleartext in the Identity Response. Following [RFC7542], it is | in cleartext in the Identity Response. Following [RFC7542], it is | |||
RECOMMENDED to omit the username (i.e., the NAI is @realm), but other | RECOMMENDED to omit the username (i.e., the NAI is @realm), but other | |||
constructions such as a fixed username (e.g. anonymous@realm) or an | constructions such as a fixed username (e.g. anonymous@realm) or an | |||
encrypted username (e.g., | encrypted username (e.g., | |||
xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. | xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. | |||
Note that the NAI MUST be a UTF-8 string as defined by the grammar in | Note that the NAI MUST be a UTF-8 string as defined by the grammar in | |||
skipping to change at page 18, line 24 ¶ | skipping to change at page 17, line 24 ¶ | |||
EAP packet exchanges that can be handled. To avoid fragmentation, it | EAP packet exchanges that can be handled. To avoid fragmentation, it | |||
is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and | is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and | |||
trust anchor certificates small and the length of the certificate | trust anchor certificates small and the length of the certificate | |||
chains short. In addition, it is RECOMMENDED to use mechanisms that | chains short. In addition, it is RECOMMENDED to use mechanisms that | |||
reduce the sizes of Certificate messages. For a detailed discussion | reduce the sizes of Certificate messages. For a detailed discussion | |||
on reducing message sizes to prevent fragmentation, see | on reducing message sizes to prevent fragmentation, see | |||
[I-D.ietf-emu-eaptlscert]. | [I-D.ietf-emu-eaptlscert]. | |||
2.2. Identity Verification | 2.2. Identity Verification | |||
This section updates Section 2.2 of [RFC5216]. The guidance in this | This section updates Section 2.2 of [RFC5216]. | |||
section is relevant for EAP-TLS in general (regardless of the | ||||
underlying TLS version used). | ||||
The EAP peer identity provided in the EAP-Response/Identity is not | The EAP peer identity provided in the EAP-Response/Identity is not | |||
authenticated by EAP-TLS. Unauthenticated information MUST NOT be | authenticated by EAP-TLS. Unauthenticated information SHALL NOT be | |||
used for accounting purposes or to give authorization. The | used for accounting purposes or to give authorization. The | |||
authenticator and the EAP-TLS server MAY examine the identity | authenticator and the EAP-TLS server MAY examine the identity | |||
presented in EAP-Response/Identity for purposes such as routing and | presented in EAP-Response/Identity for purposes such as routing and | |||
EAP method selection. EAP-TLS servers MAY reject conversations if | EAP method selection. EAP-TLS servers MAY reject conversations if | |||
the identity does not match their policy. Note that this also | the identity does not match their policy. Note that this also | |||
applies to resumption, see Sections 2.1.3, 5.6, and 5.7. | applies to resumption, see Sections 2.1.3, 5.6, and 5.7. | |||
The EAP server identity in the TLS server certificate is typically a | The EAP server identity in the TLS server certificate is typically a | |||
fully qualified domain name (FQDN) in the SubjectAltName (SAN) | fully qualified domain name (FQDN). EAP peer implementations SHOULD | |||
extension. Since EAP-TLS deployments may use more than one EAP | allow users to configuring a unique trust root (CA certificate) and a | |||
server, each with a different certificate, EAP peer implementations | server name to authenticate the server certificate and match the | |||
SHOULD allow for the configuration of a unique trusted root (CA | subjectAlternativeName (SAN) extension in the server certificate with | |||
certificate) to authenticate the server certificate and one or more | the configured server name. In the absence of a user-configured root | |||
server names to match against the SubjectAltName (SAN) extension in | CA certificate, implementations MAY rely on system-wide root CA | |||
the server certificate. To simplify name matching, an EAP-TLS | certificate bundles for authenticating the server certificate. If | |||
deployment can assign a name to represent an authorized EAP server | server name matching is not used, then peers may end up trusting | |||
and EAP Server certificates can include this name in the list of SANs | servers for EAP authentication that are not intended to be EAP | |||
for each certificate that represents an EAP-TLS server. If server | servers for the network. If name matching is not used with a public | |||
name matching is not used, then peers may end up trusting servers for | CA bundle, then effectively any server can obtain a certificate which | |||
EAP authentication that are not intended to be EAP servers for the | will be trusted for EAP authentication by the Peer. | |||
network. If name matching is not used with a public root CA, then | ||||
effectively any server can obtain a certificate which will be trusted | ||||
for EAP authentication by the Peer. While this requirement to verify | ||||
domain names is new, and was not mentioned in [RFC5216], it has been | ||||
widely implemented in EAP-TLS peers. As such, it is believed that | ||||
this section contains minimal new interoperability or implementation | ||||
requirements on EAP-TLS peers and can be applied to earlier versions | ||||
of TLS. | ||||
The process of configuring a root CA certificate and a server name is | The process of configuring a root CA certificate and a server name is | |||
non-trivial and therefore automated methods of provisioning are | non-trivial and therefore automated methods of provisioning are | |||
RECOMMENDED. For example, the eduroam federation [RFC7593] provides | RECOMMENDED. For example, the eduroam federation [RFC7593] provides | |||
a Configuration Assistant Tool (CAT) to automate the configuration | a Configuration Assistant Tool (CAT) to automate the configuration | |||
process. In the absence of a trusted root CA certificate (user | process. In the absence of a trusted root CA certificate (user | |||
configured or system-wide), EAP peers MAY implement a trust on first | configured or system-wide), EAP peers MAY implement a trust on first | |||
use (TOFU) mechanism where the peer trusts and stores the server | use (TOFU) mechanism where the peer trusts and stores the server | |||
certificate during the first connection attempt. The EAP peer | certificate during the first connection attempt. The EAP peer | |||
ensures that the server presents the same stored certificate on | ensures that the server presents the same stored certificate on | |||
subsequent interactions. Use of a TOFU mechanism does not allow for | subsequent interactions. Use of TOFU mechanism does not allow for | |||
the server certificate to change without out-of-band validation of | the server certificate to change without out-of-band validation of | |||
the certificate and is therefore not suitable for many deployments | the certificate and is therefore not suitable for many deployments. | |||
including ones where multiple EAP servers are deployed for high | ||||
availability. TOFU mechanisms increase the susceptibility to traffic | ||||
interception attacks and should only be used if there are adequate | ||||
controls in place to mitigate this risk. | ||||
2.3. Key Hierarchy | 2.3. Key Hierarchy | |||
This section updates Section 2.3 of [RFC5216]. | This section updates Section 2.3 of [RFC5216]. | |||
TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier | TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier | |||
versions of TLS with HKDF and completely changes the Key Schedule. | versions of TLS with HKDF and completely changes the Key Schedule. | |||
The key hierarchies shown in Section 2.3 of [RFC5216] are therefore | The key hierarchies shown in Section 2.3 of [RFC5216] are therefore | |||
not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 | not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 | |||
the key schedule is described in Section 7.1 of [RFC8446]. | the key schedule is described in Section 7.1 of [RFC8446]. | |||
When EAP-TLS is used with TLS version 1.3 the Key_Material and | When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and | |||
Method-Id SHALL be derived from the exporter_secret using the TLS | Method-Id SHALL be derived from the exporter_secret using the TLS | |||
exporter interface [RFC5705] (for TLS 1.3 this is defined in | exporter interface [RFC5705] (for TLS 1.3 this is defined in | |||
Section 7.5 of [RFC8446]). Type is the value of the EAP Type field | Section 7.5 of [RFC8446]). | |||
defined in Section 2 of [RFC3748]. For EAP-TLS the Type field has | ||||
value 0x0D. | ||||
Type = 0x0D | ||||
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", | ||||
Type, 128) | ||||
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", | ||||
Type, 64) | ||||
Session-Id = Type || Method-Id | ||||
The MSK and EMSK are derived from the Key_Material in the same manner | ||||
as with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated | ||||
below for simplicity: | ||||
MSK = Key_Material(0, 63) | Type-Code = 0x0D | |||
EMSK = Key_Material(64, 127) | MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64) | |||
EMSK = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64) | ||||
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64) | ||||
Session-Id = Type-Code || Method-Id | ||||
Other TLS based EAP methods can use the TLS exporter in a similar | Other TLS based EAP methods can use the TLS exporter in a similar | |||
fashion, see [I-D.ietf-emu-tls-eap-types]. | fashion, see [I-D.ietf-emu-tls-eap-types]. | |||
[RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are | [RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are | |||
not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower | not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower | |||
layers use the MSK in a lower-layer dependent manner. EAP-TLS with | layers use the MSK in a lower-layer dependent manner. EAP-TLS with | |||
TLS 1.3 exports the MSK and does not specify how it is used by lower | TLS 1.3 exports the MSK and does not specify how it used by lower | |||
layers. | layers. | |||
Note that the key derivation MUST use the length values given above. | Note that the key derivation MUST use the length values given above. | |||
While in TLS 1.2 and earlier it was possible to truncate the output | While in TLS 1.2 and earlier it was possible to truncate the output | |||
by requesting less data from the TLS-Exporter function, this practice | by requesting less data from the TLS-Exporter function, this practice | |||
is not possible with TLS 1.3. If an implementation intends to use | is not possible with TLS 1.3. If an implementation intends to use | |||
only a part of the output of the TLS-Exporter function, then it MUST | only a part of the output of the TLS-Exporter function, then it MUST | |||
ask for the full output and then only use the desired part. Failure | ask for the full output and then only use the desired part. Failure | |||
to do so will result in incorrect values being calculated for the | to do so will result in incorrect values being calculated for the | |||
above keying material. | 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 | |||
which provides a public API for the exporter. Note that EAP-TLS with | without having to extract the Main Secret, ClientHello.random, and | |||
TLS 1.2 [RFC5216] can be used with the TLS exporter since the public | ServerHello.random in a non-standard way. | |||
exporter was defined in [RFC5705]. | ||||
2.4. Parameter Negotiation and Compliance Requirements | 2.4. Parameter Negotiation and Compliance Requirements | |||
This section updates Section 2.4 of [RFC5216]. | This section updates Section 2.4 of [RFC5216]. | |||
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. | EAP-TLS is used with TLS version 1.3. | |||
When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- | When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- | |||
TLS servers MUST comply with the compliance requirements (mandatory- | TLS servers MUST comply with the compliance requirements (mandatory- | |||
to-implement cipher suites, signature algorithms, key exchange | to-implement cipher suites, signature algorithms, key exchange | |||
algorithms, extensions, etc.) for the TLS version used. For TLS 1.3 | algorithms, extensions, etc.) for the TLS version used. For TLS 1.3 | |||
the compliance requirements are defined in Section 9 of [RFC8446]. | the compliance requirements are defined in Section 9 of [RFC8446]. | |||
In EAP-TLS with TLS 1.3, only cipher suites with confidentiality | In EAP-TLS with TLS 1.3, only cipher suites with confidentiality | |||
SHALL be supported. | SHALL be supported. | |||
While EAP-TLS does not protect any application data except for the | While EAP-TLS does not protect any application data except for the | |||
TLS record with application data 0x00, the negotiated cipher suites | Commitment Message, the negotiated cipher suites and algorithms MAY | |||
and algorithms MAY be used to secure data as done in other TLS-based | be used to secure data as done in other TLS-based EAP methods. | |||
EAP methods. | ||||
2.5. EAP State Machines | 2.5. EAP State Machines | |||
This is a new section when compared to [RFC5216] and only applies to | This is a new section when compared to [RFC5216] and only applies to | |||
TLS 1.3. [RFC4137] offers a proposed state machine for EAP. | TLS 1.3. [RFC4137] offers a proposed state machine for EAP. | |||
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. Examples of Post-Handshake messages are | after the main handshake. Examples of Post-Handshake messages are | |||
NewSessionTicket, which is used for resumption and KeyUpdate, which | NewSessionTicket, which is used for resumption and KeyUpdate, which | |||
is not useful and not expected in EAP-TLS. After sending TLS | is not useful and not expected in EAP-TLS. After sending TLS | |||
Finished, the EAP-TLS server may send any number of Post-Handshake | Finished, the EAP-TLS server may send any number of Post-Handshake | |||
messages in separate EAP-Requests. | messages in separate EAP-Requests. | |||
To provide a protected success result indication and to decrease the | To provide a protected success result indication and to decrease the | |||
uncertainty for the EAP-TLS peer, the following procedure MUST be | uncertainty for the EAP-TLS peer, the following procedure MUST be | |||
followed: | followed: | |||
When an EAP-TLS server has successfully processed the TLS client | When an EAP-TLS server has successfully processed the TLS client | |||
Finished and sent its last handshake message (Finished or a Post- | Finished and sent its last handshake message (Finished or a Post- | |||
Handshake), it sends an encrypted TLS record with application data | Handshake), it commits to not sending any more handshake messages by | |||
0x00. The encrypted TLS record with application data 0x00 is a | sending an encrypted TLS record with application data 0x00. The | |||
protected success result indication, as defined in [RFC3748]. After | encrypted TLS record with application data 0x00 is a protected | |||
sending a EAP-Request that contains the protected success result | success result indication, as defined in [RFC3748]. After sending an | |||
indication, the EAP-TLS server must not send any more EAP-Request and | encrypted TLS record with application data 0x00, the EAP-TLS server | |||
may only send an EAP-Success. The EAP-TLS server MUST NOT send an | may only send an EAP-Success. The EAP-TLS server MUST NOT send an | |||
encrypted TLS record with application data 0x00 alert before it has | encrypted TLS record with application data 0x00 alert before it has | |||
successfully processed the client finished and sent its last | successfully processed the client finished and sent its last | |||
handshake message. | handshake message. | |||
TLS Error alerts SHOULD be considered a failure result indication, as | TLS Error alerts SHOULD be considered a failure result indication, as | |||
defined in [RFC3748]. Implementations following [RFC4137] sets the | defined in [RFC3748]. Implementations following [RFC4137] sets the | |||
alternate indication of failure variable altReject after sending or | alternate indication of failure variable altReject after sending or | |||
receiving an error alert. After sending or receiving a TLS Error | receiving an error alert. After sending or receiving a TLS Error | |||
alert, the EAP-TLS server may only send an EAP-Failure. Protected | alert, the EAP-TLS server may only send an EAP-Failure. Protected | |||
skipping to change at page 22, line 19 ¶ | skipping to change at page 20, line 39 ¶ | |||
No updates to Section 3 of [RFC5216]. | No updates to Section 3 of [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]. | |||
This document requires IANA to add the following labels to the TLS | This document requires IANA to add the following labels to the TLS | |||
Exporter Label Registry defined by [RFC5705]. These labels are used | Exporter Label Registry defined by [RFC5705]. These labels are used | |||
in derivation of Key_Material and Method-Id as defined in | in derivation of Key_Material, IV and Method-Id as defined in | |||
Section 2.3: | Section 2.3: | |||
+-------------------------------+---------+-------------+------+ | +----------------------------+---------+-------------+------+ | |||
| Value | DTLS-OK | Recommended | Note | | | Value | DTLS-OK | Recommended | Note | | |||
+-------------------------------+---------+-------------+------+ | +----------------------------+---------+-------------+------+ | |||
| EXPORTER_EAP_TLS_Key_Material | N | Y | | | | EXPORTER_EAP_TLS_MSK | N | Y | | | |||
| | | | | | | | | | | | |||
| EXPORTER_EAP_TLS_Method-Id | N | Y | | | | EXPORTER_EAP_TLS_EMSK | N | Y | | | |||
+-------------------------------+---------+-------------+------+ | | | | | | | |||
| EXPORTER_EAP_TLS_Method-Id | N | Y | | | ||||
+----------------------------+---------+-------------+------+ | ||||
Table 1: TLS Exporter Label Registry | Table 1: TLS Exporter Label Registry | |||
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 5.1 of [RFC5216]. However, it | EAP-TLS as given in Section 5.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 | |||
skipping to change at page 23, line 10 ¶ | skipping to change at page 21, line 42 ¶ | |||
mandates use of cipher suites that ensure confidentiality. TLS 1.3 | mandates use of cipher suites that ensure confidentiality. TLS 1.3 | |||
also encrypts certificates and some of the extensions. When using | also encrypts certificates and some of the extensions. When using | |||
EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not | EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not | |||
cause any additional round-trips. | cause any additional round-trips. | |||
[3] Cryptographic strength: TLS 1.3 only defines strong algorithms | [3] Cryptographic strength: TLS 1.3 only defines strong algorithms | |||
without major weaknesses and EAP-TLS with TLS 1.3 always provides | without major weaknesses and EAP-TLS with TLS 1.3 always provides | |||
forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC | forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC | |||
mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated. | mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated. | |||
[4] Cryptographic Negotiation: The TLS layer handles the negotiation | [4] Cryptographic Negotiation: TLS 1.3 increases the number of | |||
of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP- | cryptographic parameters that are negotiated in the handshake. When | |||
TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF | EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic | |||
hash algorithm, key exchange groups, and signature algorithm, see | negotiation of AEAD algorithm, HKDF hash algorithm, key exchange | |||
Section 4.1.1 of [RFC8446]. | groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. | |||
5.2. Peer and Server Identities | 5.2. Peer and Server Identities | |||
No updates to section 5.2 of [RFC5216]. Note that Section 2.2 has | No updates to section 5.2 of [RFC5216]. | |||
additional discussion on identities. | ||||
5.3. Certificate Validation | 5.3. Certificate Validation | |||
No updates to section 5.3 of [RFC5216]. | No updates to section 5.3 of [RFC5216]. | |||
5.4. Certificate Revocation | 5.4. Certificate Revocation | |||
This section updates Section 5.4 of [RFC5216]. | This section updates Section 5.4 of [RFC5216]. | |||
There are a number of reasons (e.g., key compromise, CA compromise, | While certificates may have long validity periods, there are a number | |||
privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub- | of reasons (e.g., key compromise, CA compromise, privilege withdrawn, | |||
CA certificates have to be revoked before their expiry date. | etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have | |||
Revocation of the EAP-TLS server's certificate is complicated by the | to be revoked before their expiry date. Revocation of the EAP-TLS | |||
fact that the EAP-TLS peer may not have Internet connectivity until | server's certificate is complicated by the fact that the EAP-TLS peer | |||
authentication completes. | may not have Internet connectivity until authentication completes. | |||
When EAP-TLS is used with TLS 1.3, the revocation status of all the | When EAP-TLS is used with TLS 1.3, the revocation status of all the | |||
certificates in the certificate chains MUST be checked (except the | certificates in the certificate chains MUST be checked (except the | |||
trust anchor). An implementation may use Certificate Revocation List | trust anchor). An implementation may use Certificate Revocation List | |||
(CRL), Online Certificate Status Protocol (OSCP), or other | (CRL), Online Certificate Status Protocol (OSCP), or other | |||
standardized/proprietary methods for revocation checking. Examples | standardized/proprietary methods for revocation checking. Examples | |||
of proprietary methods are non-standard formats for distribution of | of proprietary methods are non-standard formats for distribution of | |||
revocation lists as well as certificates with very short lifetime. | revocation lists as well as certificates with very short lifetime. | |||
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status | EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status | |||
skipping to change at page 25, line 4 ¶ | skipping to change at page 23, line 36 ¶ | |||
5.6. Authorization | 5.6. Authorization | |||
This is a new section when compared to [RFC5216]. The guidance in | This is a new section when compared to [RFC5216]. The guidance in | |||
this section is relevant for EAP-TLS in general (regardless of the | this section is relevant for EAP-TLS in general (regardless of the | |||
underlying TLS version used). | underlying TLS version used). | |||
EAP servers will usually require the EAP peer to provide a valid | EAP servers will usually require the EAP peer to provide a valid | |||
certificate and will fail the connection if one is not provided. | certificate and will fail the connection if one is not provided. | |||
Some deployments may permit no peer authentication for some or all | Some deployments may permit no peer authentication for some or all | |||
connections. When peer authentication is not used, EAP-TLS server | connections. When peer authentication is not used, implementations | |||
implementations MUST take care to limit network access appropriately | MUST take care to limit network access appropriately for | |||
for unauthenticated peers and implementations MUST use resumption | unauthenticated peers and implementations MUST use resumption with | |||
with caution to ensure that a resumed session is not granted more | caution to ensure that a resumed session is not granted more | |||
privilege than was intended for the original session. An example of | privilege than was intended for the original session. | |||
limiting network access would be to invoke a vendor's walled garden | ||||
or quarantine network functionality. | ||||
EAP-TLS is typically encapsulated in other protocols, such as PPP | EAP-TLS is typically encapsulated in other protocols, such as PPP | |||
[RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. | [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. | |||
The encapsulating protocols can also provide additional, non-EAP | The encapsulating protocols can also provide additional, non-EAP | |||
information to an EAP-TLS server. This information can include, but | information to an EAP-TLS server. This information can include, but | |||
is not limited to, information about the authenticator, information | is not limited to, information about the authenticator, information | |||
about the EAP-TLS peer, or information about the protocol layers | about the EAP-TLS peer, or information about the protocol layers | |||
above or below EAP (MAC addresses, IP addresses, port numbers, WiFi | above or below EAP (MAC addresses, IP addresses, port numbers, WiFi | |||
SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those | SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those | |||
protocols can make policy decisions and enforce authorization based | protocols can make policy decisions and enforce authorization based | |||
skipping to change at page 25, line 45 ¶ | skipping to change at page 24, line 28 ¶ | |||
address of the authenticator does not match the expected policy. | address of the authenticator does not match the expected policy. | |||
5.7. Resumption | 5.7. Resumption | |||
This is a new section when compared to [RFC5216]. The guidance in | This is a new section when compared to [RFC5216]. The guidance in | |||
this section is relevant for EAP-TLS in general (regardless of the | this section is relevant for EAP-TLS in general (regardless of the | |||
underlying TLS version used). | underlying TLS version used). | |||
There are a number of security issues related to resumption that are | There are a number of security issues related to resumption that are | |||
not described in [RFC5216]. The problems, guidelines, and | not described in [RFC5216]. The problems, guidelines, and | |||
requirements in this section therefore applies to EAP-TLS when it is | requirements in this section therefore applies to all version of TLS. | |||
used with any version of TLS. | ||||
When resumption occurs, it is based on cached information at the TLS | When resumption occurs, it is based on cached information at the TLS | |||
layer. To perform resumption in a secure way, the EAP-TLS peer and | layer. To perform resumption in a secure way, the EAP-TLS peer and | |||
EAP-TLS server need to be able to securely retrieve authorization | EAP-TLS server need to be able to securely retrieve authorization | |||
information such as certificate chains from the initial full | information such as certificate chains from the initial full | |||
handshake. This document use the term "cached data" to describe such | handshake. We use the term "cached data" to describe such | |||
information. Authorization during resumption MUST be based on such | information. Authorization during resumption MUST be based on such | |||
cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh | cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh | |||
revocation checks on the cached certificate data. Any security | revocation checks on the cached certificate data. Any security | |||
policies for authorization MUST be followed also for resumption. The | policies for authorization MUST be followed also for resumption. The | |||
certificates may have been revoked since the initial full handshake | certificates may have been revoked since the initial full handshake | |||
and the authorizations of the other party may have reduced. If the | and the authorizations of the other party may have reduced. If the | |||
cached revocation data is not sufficiently current, the EAP-TLS peer | cached revocation data is not sufficiently current, the EAP-TLS peer | |||
or EAP-TLS server MAY force a full TLS handshake. | or EAP-TLS server MAY force a full TLS handshake. | |||
There are two ways to retrieve the cached data from the original full | There are two ways to retrieve the cached data from the original full | |||
skipping to change at page 26, line 30 ¶ | skipping to change at page 25, line 12 ¶ | |||
[RFC8446], where the EAP-TLS server avoids storing information | [RFC8446], where the EAP-TLS server avoids storing information | |||
locally and instead encapsulates the information into a ticket or PSK | locally and instead encapsulates the information into a ticket or PSK | |||
which is sent to the client for storage. This ticket or PSK is | which is sent to the client for storage. This ticket or PSK is | |||
encrypted using a key that only the EAP-TLS server knows. Note that | encrypted using a key that only the EAP-TLS server knows. Note that | |||
the client still needs to cache the original handshake information | the client still needs to cache the original handshake information | |||
locally and will use the session ID or PSK identity to lookup this | locally and will use the session ID or PSK identity to lookup this | |||
information during resumption. However, the EAP-TLS server is able | information during resumption. However, the EAP-TLS server is able | |||
to decrypt the ticket or PSK to obtain the original handshake | to decrypt the ticket or PSK to obtain the original handshake | |||
information. | information. | |||
The EAP-TLS server or EAP client MUST cache data during the initial | If the EAP-TLS server or EAP client do not apply any authorization | |||
full handshake sufficient to allow authorization decisions to be made | policies, they MAY allow resumption where no cached data is | |||
during resumption. If cached data cannot be retrieved in a secure | available. In all other cases, they MUST cache data during the | |||
way, resumption MUST NOT be done. | initial full handshake 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-TLS server expects some | The above requirements also apply if the EAP-TLS server expects some | |||
system to perform accounting for the session. Since accounting must | system to perform accounting for the session. Since accounting must | |||
be tied to an authenticated identity, and resumption does not supply | be tied to an authenticated identity, and resumption does not supply | |||
such an identity, accounting is impossible without access to cached | such an identity, accounting is impossible without access to cached | |||
data. Therefore systems which expect to perform accounting for the | data. Therefore systems which expect to perform accounting for the | |||
session SHOULD cache an identifier which can be used in subsequent | session SHOULD cache an identifier which can be used in subsequent | |||
accounting. | accounting. | |||
As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption | As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption | |||
PSKs or tickets (and associated cached data) for longer than 604800 | PSKs or tickets (and associated cached data) for longer than 7 days, | |||
seconds (7 days), regardless of the PSK or ticket lifetime. The EAP- | regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY | |||
TLS peer MAY delete them earlier based on local policy. The cached | delete them earlier based on local policy. The cached data MAY also | |||
data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any | be removed on the EAP-TLS server or EAP-TLS peer if any certificate | |||
certificate in the certificate chain has been revoked or has expired. | in the certificate chain has been revoked or has expired. In all | |||
In all such cases, an attempt at resumption results in a full TLS | such cases, an attempt at resumption results in a full TLS handshake | |||
handshake instead. | instead. | |||
Information from the EAP-TLS exchange (e.g., the identity provided in | Information from the EAP-TLS exchange (e.g., the identity provided in | |||
EAP-Response/Identity) as well as non-EAP information (e.g., IP | EAP-Response/Identity) as well as non-EAP information (e.g., IP | |||
addresses) may change between the initial full handshake and | addresses) may change between the initial full handshake and | |||
resumption. This change creates a "time-of-check time-of-use" | resumption. This change creates a "time-of-check time-of-use" | |||
(TOCTOU) security vulnerability. A malicious or compromised user | (TOCTOU) security vulnerability. A malicious or compromised user | |||
could supply one set of data during the initial authentication, and a | could supply one set of data during the initial authentication, and a | |||
different set of data during resumption, potentially allowing them to | different set of data during resumption, potentially allowing them to | |||
obtain access that they should not have. | obtain access that they should not have. | |||
skipping to change at page 31, line 22 ¶ | skipping to change at page 29, line 49 ¶ | |||
[I-D.ietf-emu-tls-eap-types] | [I-D.ietf-emu-tls-eap-types] | |||
DeKok, A., "TLS-based EAP types and TLS 1.3", draft-ietf- | DeKok, A., "TLS-based EAP types and TLS 1.3", draft-ietf- | |||
emu-tls-eap-types-02 (work in progress), February 2021. | emu-tls-eap-types-02 (work in progress), February 2021. | |||
[I-D.ietf-tls-md5-sha1-deprecate] | [I-D.ietf-tls-md5-sha1-deprecate] | |||
Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating | Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating | |||
MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf- | MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf- | |||
tls-md5-sha1-deprecate-06 (work in progress), March 2021. | tls-md5-sha1-deprecate-06 (work in progress), March 2021. | |||
[I-D.ietf-tls-rfc8446bis] | ||||
Rescorla, E., "The Transport Layer Security (TLS) Protocol | ||||
Version 1.3", draft-ietf-tls-rfc8446bis-01 (work in | ||||
progress), February 2021. | ||||
[I-D.ietf-tls-ticketrequests] | [I-D.ietf-tls-ticketrequests] | |||
Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket | Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket | |||
Requests", draft-ietf-tls-ticketrequests-07 (work in | Requests", draft-ietf-tls-ticketrequests-07 (work in | |||
progress), December 2020. | progress), December 2020. | |||
[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 Standard 802.11-2020 , | Layer (PHY) Specifications", IEEE Std 802.11-2016 | |||
February 2021. | (Revision of IEEE Std 802.11-2012) , December 2016. | |||
[IEEE-802.1AE] | [IEEE-802.1AE] | |||
Institute of Electrical and Electronics Engineers, "IEEE | Institute of Electrical and Electronics Engineers, "IEEE | |||
Standard for Local and metropolitan area networks -- Media | Standard for Local and metropolitan area networks -- Media | |||
Access Control (MAC) Security", IEEE Standard | Access Control (MAC) Security", IEEE Standard | |||
802.1AE-2018 , December 2018. | 802.1AE-2018 , December 2018. | |||
[IEEE-802.1X] | [IEEE-802.1X] | |||
Institute of Electrical and Electronics Engineers, "IEEE | Institute of Electrical and Electronics Engineers, "IEEE | |||
Standard for Local and metropolitan area networks -- Port- | Standard for Local and metropolitan area networks -- Port- | |||
Based Network Access Control", IEEE Standard 802.1X-2020 , | Based Network Access Control", IEEE Standard 802.1X-2020 , | |||
February 2020. | January 2020. | |||
[MulteFire] | [MulteFire] | |||
MulteFire, "MulteFire Release 1.1 specification", 2019. | MulteFire, "MulteFire Release 1.1 specification", 2019. | |||
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible | [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible | |||
Authentication Protocol (PEAP)", April 2021. | Authentication Protocol (PEAP)", 2018. | |||
[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 34, line 27 ¶ | skipping to change at page 32, line 49 ¶ | |||
Architecture for Network Roaming", RFC 7593, | Architecture for Network Roaming", RFC 7593, | |||
DOI 10.17487/RFC7593, September 2015, | DOI 10.17487/RFC7593, September 2015, | |||
<https://www.rfc-editor.org/info/rfc7593>. | <https://www.rfc-editor.org/info/rfc7593>. | |||
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS | [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS | |||
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, | and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8447>. | <https://www.rfc-editor.org/info/rfc8447>. | |||
[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 17.1.0, April 2021. | System", 3GPP TS 33.501 17.0.0, December 2020. | |||
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. | below when EAP-TLS is used with TLS 1.3. | |||
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 Bernard Aboba, Jari Arkko, Terry Burton, | The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, | |||
Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, | Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, | |||
Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa | Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa | |||
Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and | Torvinen, and Hannes Tschofenig for comments and suggestions on the | |||
suggestions on the draft. Special thanks to the document shepard | draft. | |||
Joseph Salowey. | ||||
Contributors | Contributors | |||
Alan DeKok, FreeRADIUS | Alan DeKok, FreeRADIUS | |||
Authors' Addresses | Authors' Addresses | |||
John Preuss Mattsson | John Preuss Mattsson | |||
Ericsson | Ericsson | |||
Stockholm 164 40 | Stockholm 164 40 | |||
End of changes. 110 change blocks. | ||||
324 lines changed or deleted | 245 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |