idnits 2.17.1 draft-ietf-emu-eap-tls13-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5216, updated by this document, for RFC5378 checks: 2006-02-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 11, 2021) is 1021 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 943 -- Looks like a reference, but probably isn't: '2' on line 947 -- Looks like a reference, but probably isn't: '3' on line 954 -- Looks like a reference, but probably isn't: '4' on line 959 == Outdated reference: A later version (-13) exists of draft-ietf-emu-tls-eap-types-02 == Outdated reference: A later version (-09) exists of draft-ietf-tls-md5-sha1-deprecate-06 == Outdated reference: A later version (-10) exists of draft-ietf-tls-rfc8446bis-01 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Preuss Mattsson 3 Internet-Draft M. Sethi 4 Updates: 5216 (if approved) Ericsson 5 Intended status: Standards Track June 11, 2021 6 Expires: December 13, 2021 8 Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) 9 draft-ietf-emu-eap-tls13-16 11 Abstract 13 The Extensible Authentication Protocol (EAP), defined in RFC 3748, 14 provides a standard mechanism for support of multiple authentication 15 methods. This document specifies the use of EAP-Transport Layer 16 Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible 17 with existing implementations of EAP-TLS. TLS 1.3 provides 18 significantly improved security, privacy, and reduced latency when 19 compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 20 1.3) further improves security and privacy by always providing 21 forward secrecy, never disclosing the peer identity, and by mandating 22 use of revocation checking. This document also provides guidance on 23 authorization and resumption for EAP-TLS in general (regardless of 24 the underlying TLS version used). This document updates RFC 5216. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 13, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4 64 2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 5 65 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 6 66 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 8 67 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 11 68 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14 69 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15 70 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16 71 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 72 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 17 73 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18 74 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 75 2.4. Parameter Negotiation and Compliance Requirements . . . . 20 76 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 20 77 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 21 78 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 80 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 22 81 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 23 82 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 23 83 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 23 84 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 24 85 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 24 86 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 25 87 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 27 88 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 28 89 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29 90 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 91 6.1. Normative References . . . . . . . . . . . . . . . . . . 29 92 6.2. Informative references . . . . . . . . . . . . . . . . . 30 93 Appendix A. Updated references . . . . . . . . . . . . . . . . . 34 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 98 1. Introduction 100 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 101 provides a standard mechanism for support of multiple authentication 102 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies 103 an EAP authentication method with certificate-based mutual 104 authentication utilizing the TLS handshake protocol for cryptographic 105 algorithms and protocol version negotiation and establishment of 106 shared secret keying material. EAP-TLS is widely supported for 107 authentication and key establishment in IEEE 802.11 [IEEE-802.11] 108 (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec) networks using IEEE 109 802.1X [IEEE-802.1X] and it's the default mechanism for certificate 110 based authentication in 3GPP 5G [TS.33.501] and MulteFire [MulteFire] 111 networks. Many other EAP methods such as EAP-FAST [RFC4851], EAP- 112 TTLS [RFC5281], TEAP [RFC7170], and PEAP [PEAP] depend on TLS and 113 EAP-TLS. 115 EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346], 116 but can also work with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are 117 formally deprecated and prohibited to negotiate and use [RFC8996]. 118 Weaknesses found in TLS 1.2, as well as new requirements for 119 security, privacy, and reduced latency have led to the specification 120 of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is 121 in large parts a complete remodeling of the TLS handshake protocol 122 including a different message flow, different handshake messages, 123 different key schedule, different cipher suites, different 124 resumption, different privacy protection, and different record 125 padding. This means that significant parts of the normative text in 126 the previous EAP-TLS specification [RFC5216] are not applicable to 127 EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy 128 handling, and key derivation need to be appropriately addressed for 129 EAP-TLS with TLS 1.3. 131 This document defines how to use EAP-TLS with TLS 1.3 and does not 132 change how EAP-TLS is used with older versions of TLS. It does 133 however provide additional guidance on authorization and resumption 134 for EAP-TLS in general (regardless of the underlying TLS version 135 used). While this document updates EAP-TLS [RFC5216], it remains 136 backwards compatible with it and existing implementations of EAP-TLS. 137 This document only describes differences compared to [RFC5216]. All 138 message flow are example message flows specific to TLS 1.3 and do not 139 apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state 140 machine with the EAP state machine it is possible that new versions 141 of TLS will cause incompatibilities that introduce failures or 142 security issues if they are not carefully integrated into the EAP-TLS 143 protocol. Therefore, implementations MUST limit the maximum TLS 144 version they use to 1.3, unless later versions are explicitly enabled 145 by the administrator. 147 This document specifies EAP-TLS 1.3 and does not specify how other 148 TLS-based EAP methods use TLS 1.3. The specification for how other 149 TLS-based EAP methods use TLS 1.3 is left to other documents such as 150 [I-D.ietf-emu-tls-eap-types]. 152 In addition to the improved security and privacy offered by TLS 1.3, 153 there are other significant benefits of using EAP-TLS with TLS 1.3. 154 Privacy, which in EAP-TLS means that no information about the 155 underlying peer identity is disclosed, is mandatory and achieved 156 without any additional round-trips. Revocation checking is mandatory 157 and simplified with OCSP stapling, and TLS 1.3 introduces more 158 possibilities to reduce fragmentation when compared to earlier 159 versions of TLS. 161 1.1. Requirements and Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in BCP 166 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 Readers are expected to be familiar with the terms and concepts used 170 in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is 171 used for the entity acting as EAP peer and TLS client. The term EAP- 172 TLS server is used for the entity acting as EAP server and TLS 173 server. 175 Readers are expected to be familiar with the terms and concepts used 176 in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is 177 used for the entity acting as EAP peer and TLS client. The term EAP- 178 TLS server is used for the entity acting as EAP server and TLS 179 server. 181 This document follows the terminology from [I-D.ietf-tls-rfc8446bis] 182 where the master secret is renamed to the main secret and the 183 exporter_master_secret is renamed to the exporter_secret. 185 2. Protocol Overview 187 2.1. Overview of the EAP-TLS Conversation 189 This section updates Section 2.1 of [RFC5216]. 191 TLS 1.3 changes both the message flow and the handshake messages 192 compared to earlier versions of TLS. Therefore, much of Section 2.1 193 of [RFC5216] does not apply for TLS 1.3. EAP-TLS 1.3 remains 194 backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS version 195 negotiation is handled by the TLS layer, and thus outside of the 196 scope of EAP-TLS. Therefore so long as the underlying TLS 197 implementation correctly implements TLS version negotiation, EAP-TLS 198 will automatically leverage that capability. 200 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 201 described in [RFC5216] the conversation will continue with the TLS 202 handshake protocol encapsulated in the data fields of EAP-Response 203 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, 204 the formatting and processing of the TLS handshake SHALL be done as 205 specified in version 1.3 of TLS. This document only lists additional 206 and different requirements, restrictions, and processing compared to 207 [RFC8446] and [RFC5216]. 209 2.1.1. Authentication 211 This section updates Section 2.1.1 of [RFC5216]. 213 The EAP-TLS server MUST authenticate with a certificate and SHOULD 214 require the EAP-TLS peer to authenticate with a certificate. 215 Certificates can be of any type supported by TLS including raw public 216 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 217 for resumption. The full handshake in EAP-TLS with TLS 1.3 always 218 provides forward secrecy by exchange of ephemeral "key_share" 219 extensions in the ClientHello and ServerHello (e.g. containing 220 ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3, 221 see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early 222 application data which like all other application data is not used in 223 EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information 224 of the "early_data" extension. Resumption is handled as described in 225 Section 2.1.3. TLS 1.3 introduced the Post-Handshake KeyUpdate 226 message which is not useful and not expected in EAP-TLS. As a 227 protected success indication [RFC3748] the EAP-TLS server always 228 sends TLS application data 0x00, see Section 2.5. Note that a TLS 229 implementation MAY not allow the EAP-TLS layer to control in which 230 order things are sent and the application data MAY therefore be sent 231 before a NewSessionTicket. TLS application data 0x00 is therefore to 232 be interpreted as success after the EAP-Request that contains TLS 233 application data 0x00. After the EAP-TLS server has sent an EAP- 234 Request containing the TLS application data 0x00 and received an EAP- 235 Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server 236 sends EAP-Success. 238 Figure 1 shows an example message flow for a successful EAP-TLS full 239 handshake with mutual authentication (and neither HelloRetryRequest 240 nor Post-Handshake messages are sent). 242 EAP-TLS Peer EAP-TLS Server 244 EAP-Request/ 245 <-------- Identity 246 EAP-Response/ 247 Identity (Privacy-Friendly) --------> 248 EAP-Request/ 249 EAP-Type=EAP-TLS 250 <-------- (TLS Start) 251 EAP-Response/ 252 EAP-Type=EAP-TLS 253 (TLS ClientHello) --------> 254 EAP-Request/ 255 EAP-Type=EAP-TLS 256 (TLS ServerHello, 257 TLS EncryptedExtensions, 258 TLS CertificateRequest, 259 TLS Certificate, 260 TLS CertificateVerify, 261 <-------- TLS Finished) 262 EAP-Response/ 263 EAP-Type=EAP-TLS 264 (TLS Certificate, 265 TLS CertificateVerify, 266 TLS Finished) --------> 267 EAP-Request/ 268 EAP-Type=EAP-TLS 269 <-------- (TLS Application Data 0x00) 270 EAP-Response/ 271 EAP-Type=EAP-TLS --------> 272 <-------- EAP-Success 274 Figure 1: EAP-TLS mutual authentication 276 2.1.2. Ticket Establishment 278 This is a new section when compared to [RFC5216]. 280 To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS 281 server MUST send one or more Post-Handshake NewSessionTicket messages 282 (each associated with a PSK, a PSK identity, a ticket lifetime, and 283 other parameters) in the initial authentication. Note that TLS 1.3 284 [RFC8446] limits the ticket lifetime to a maximum of 604800 seconds 285 (7 days) and EAP-TLS servers MUST respect this upper limit when 286 issuing tickets. The NewSessionTicket is sent after the EAP-TLS 287 server has received the client Finished message in the initial 288 authentication. The NewSessionTicket can be sent in the same flight 289 as the TLS server Finished or later. The PSK associated with the 290 ticket depends on the client Finished and cannot be pre-computed in 291 handshakes with client authentication. The NewSessionTicket message 292 MUST NOT include an "early_data" extension. If the "early_data" 293 extension is received then it MUST be ignored. Servers should take 294 into account that fewer NewSessionTickets will likely be needed in 295 EAP-TLS than in the usual HTTPS connection scenario. In most cases a 296 single NewSessionTicket will be sufficient. A mechanism by which 297 clients can specify the desired number of tickets needed for future 298 connections is defined in [I-D.ietf-tls-ticketrequests]. 300 Figure 2 shows an example message flow for a successful EAP-TLS full 301 handshake with mutual authentication and ticket establishment of a 302 single ticket. 304 EAP-TLS Peer EAP-TLS Server 306 EAP-Request/ 307 <-------- Identity 308 EAP-Response/ 309 Identity (Privacy-Friendly) --------> 310 EAP-Request/ 311 EAP-Type=EAP-TLS 312 <-------- (TLS Start) 313 EAP-Response/ 314 EAP-Type=EAP-TLS 315 (TLS ClientHello) --------> 316 EAP-Request/ 317 EAP-Type=EAP-TLS 318 (TLS ServerHello, 319 TLS EncryptedExtensions, 320 TLS CertificateRequest, 321 TLS Certificate, 322 TLS CertificateVerify, 323 <-------- TLS Finished) 324 EAP-Response/ 325 EAP-Type=EAP-TLS 326 (TLS Certificate, 327 TLS CertificateVerify, 328 TLS Finished) --------> 329 EAP-Request/ 330 EAP-Type=EAP-TLS 331 (TLS NewSessionTicket, 332 <-------- (TLS Application Data 0x00) 333 EAP-Response/ 334 EAP-Type=EAP-TLS --------> 335 <-------- EAP-Success 337 Figure 2: EAP-TLS ticket establishment 339 2.1.3. Resumption 341 This section updates Section 2.1.2 of [RFC5216]. 343 EAP-TLS is typically used with client authentication and typically 344 fragments the TLS flights into a large number of EAP requests and EAP 345 responses. Resumption significantly reduces the number of round- 346 trips and enables the EAP-TLS server to omit database lookups needed 347 during a full handshake with client authentication. TLS 1.3 replaces 348 the session resumption mechanisms in earlier versions of TLS with a 349 new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS 350 SHALL use a resumption mechanism compatible with version 1.3 of TLS. 352 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 353 the client has received a NewSessionTicket message from the EAP-TLS 354 server, the client can use the PSK identity associated with the 355 ticket to negotiate the use of the associated PSK. If the EAP-TLS 356 server accepts it, then the resumed session has been deemed to be 357 authenticated, and securely tied to the associated with the prior 358 authentication or resumption. It is up to the EAP-TLS peer to use 359 resumption, but it is RECOMMENDED that the EAP-TLS peer use 360 resumption if it has a valid ticket that has not been used before. 361 It is left to the EAP-TLS server whether to accept resumption, but it 362 is RECOMMENDED that the EAP-TLS server accept resumption if the 363 ticket which was issued is still valid. However, the EAP-TLS server 364 MAY choose to require a full handshake. In the case a full handshake 365 is required, the negotiation proceeds as if the session was a new 366 authentication, and resumption had never been requested. The 367 requirements of Sections 2.1.1 and 2.1.2 then apply in their 368 entirety. As described in Appendix C.4 of [RFC8446], reuse of a 369 ticket allows passive observers to correlate different connections. 370 EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking 371 preventions in Appendix C.4 of [RFC8446]. 373 It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the 374 same realm during resumption and the original full handshake. This 375 requirement allows EAP packets to be routed to the same destination 376 as the original full handshake. If this recommendation is not 377 followed, resumption is likely impossible. When NAI reuse can be 378 done without privacy implications, it is RECOMMENDED to use the same 379 NAI in the resumption, as was used in the original full handshake 380 [RFC7542]. For example, the NAI @realm can safely be reused since it 381 does not provide any specific information to associate a user's 382 resumption attempt with the original full handshake. However, 383 reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path 384 attacker to associate a resumption attempt with the original full 385 handshake. The TLS PSK identity is typically derived by the TLS 386 implementation and may be an opaque blob without a routable realm. 387 The TLS PSK identity on its own is therefore unsuitable as a NAI in 388 the Identity Response. 390 Figure 3 shows an example message flow for a subsequent successful 391 EAP-TLS resumption handshake where both sides authenticate via a PSK 392 provisioned via an earlier NewSessionTicket and where the server 393 provisions a single new ticket. 395 EAP-TLS Peer EAP-TLS Server 397 EAP-Request/ 398 <-------- Identity 399 EAP-Response/ 400 Identity (Privacy-Friendly) --------> 401 EAP-Request/ 402 EAP-Type=EAP-TLS 403 <-------- (TLS Start) 404 EAP-Response/ 405 EAP-Type=EAP-TLS 406 (TLS ClientHello) --------> 407 EAP-Request/ 408 EAP-Type=EAP-TLS 409 (TLS ServerHello, 410 TLS EncryptedExtensions, 411 <-------- TLS Finished, 412 TLS NewSessionTicket) 413 EAP-Response/ 414 EAP-Type=EAP-TLS 415 (TLS Finished) --------> 416 EAP-Request/ 417 EAP-Type=EAP-TLS 418 <-------- (TLS Application Data 0x00) 419 EAP-Response/ 420 EAP-Type=EAP-TLS --------> 421 <-------- EAP-Success 423 Figure 3: EAP-TLS resumption 425 As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD 426 supply a "key_share" extension when attempting resumption, which 427 allows the EAP-TLS server to potentially decline resumption and fall 428 back to a full handshake. If the EAP-TLS peer did not supply a 429 "key_share" extension when attempting resumption, the EAP-TLS server 430 needs to send HelloRetryRequest to signal that additional information 431 is needed to complete the handshake, and the EAP-TLS peer needs to 432 send a second ClientHello containing that information. Providing a 433 "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode 434 is also important in order to limit the impact of a key compromise. 435 When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning 436 that key leakage does not compromise any earlier connections. The 437 "psk_dh_ke" mechanism MUST be used for resumption unless the 438 deployment has a local requirement to allow configuration of other 439 mechanisms. 441 2.1.4. Termination 443 This section updates Section 2.1.3 of [RFC5216]. 445 TLS 1.3 changes both the message flow and the handshake messages 446 compared to earlier versions of TLS. Therefore, some normative text 447 in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3. The two 448 paragraphs below replaces the corresponding paragraphs in 449 Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3. The 450 other paragraphs in Section 2.1.3 of [RFC5216] still apply with the 451 exception that SessionID is deprecated. 453 If the EAP-TLS peer authenticates successfully, the EAP-TLS server 454 MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing 455 TLS records conforming to the version of TLS used. The message 456 flow ends with the EAP-TLS server sending an EAP-Success message. 458 If the EAP-TLS server authenticates successfully, the EAP-TLS peer 459 MUST send an EAP-Response message with EAP-Type=EAP-TLS containing 460 TLS records conforming to the version of TLS used. 462 Figures 4, 5, and 6 illustrate message flows in several cases where 463 the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message. 464 In earlier versions of TLS, error alerts could be warnings or fatal. 465 In TLS 1.3, error alerts are always fatal and the only alerts sent at 466 warning level are "close_notify" and "user_canceled", both of which 467 indicate that the connection is not going to continue normally, see 468 [RFC8446]. 470 In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a 471 fatal error condition. Failure to send TLS Error alerts means that 472 the peer or server would have no way of determining what went wrong. 473 EAP-TLS 1.3 strengthens this requirement. Whenever an implementation 474 encounters a fatal error condition, it MUST send an appropriate TLS 475 Error alert. 477 Figure 4 shows an example message flow where the EAP-TLS server 478 rejects the ClientHello with an error alert. The EAP-TLS server can 479 also partly reject the ClientHello with a HelloRetryRequest, see 480 Section 2.1.6. 482 EAP-TLS Peer EAP-TLS Server 484 EAP-Request/ 485 <-------- Identity 486 EAP-Response/ 487 Identity (Privacy-Friendly) --------> 488 EAP-Request/ 489 EAP-Type=EAP-TLS 490 <-------- (TLS Start) 491 EAP-Response/ 492 EAP-Type=EAP-TLS 493 (TLS ClientHello) --------> 494 EAP-Request/ 495 EAP-Type=EAP-TLS 496 <-------- (TLS Error Alert) 497 EAP-Response/ 498 EAP-Type=EAP-TLS --------> 499 <-------- EAP-Failure 501 Figure 4: EAP-TLS server rejection of ClientHello 503 Figure 5 shows an example message flow where EAP-TLS server 504 authentication is unsuccessful and the EAP-TLS peer sends a TLS Error 505 alert. 507 EAP-TLS Peer EAP-TLS Server 509 EAP-Request/ 510 <-------- Identity 511 EAP-Response/ 512 Identity (Privacy-Friendly) --------> 513 EAP-Request/ 514 EAP-Type=EAP-TLS 515 <-------- (TLS Start) 516 EAP-Response/ 517 EAP-Type=EAP-TLS 518 (TLS ClientHello) --------> 519 EAP-Request/ 520 EAP-Type=EAP-TLS 521 (TLS ServerHello, 522 TLS EncryptedExtensions, 523 TLS CertificateRequest, 524 TLS Certificate, 525 TLS CertificateVerify, 526 <-------- TLS Finished) 527 EAP-Response/ 528 EAP-Type=EAP-TLS 529 (TLS Error Alert) 530 --------> 531 <-------- EAP-Failure 533 Figure 5: EAP-TLS unsuccessful EAP-TLS server authentication 535 Figure 6 shows an example message flow where the EAP-TLS server 536 authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer 537 fails to authenticate to the EAP-TLS server and the server sends a 538 TLS Error alert. 540 EAP-TLS Peer EAP-TLS Server 542 EAP-Request/ 543 <-------- Identity 544 EAP-Response/ 545 Identity (Privacy-Friendly) --------> 547 EAP-Request/ 548 EAP-Type=EAP-TLS 549 <-------- (TLS Start) 550 EAP-Response/ 551 EAP-Type=EAP-TLS 552 (TLS ClientHello) --------> 553 EAP-Request/ 554 EAP-Type=EAP-TLS 555 (TLS ServerHello, 556 TLS EncryptedExtensions, 557 TLS CertificateRequest, 558 TLS Certificate, 559 TLS CertificateVerify, 560 <-------- TLS Finished) 561 EAP-Response/ 562 EAP-Type=EAP-TLS 563 (TLS Certificate, 564 TLS CertificateVerify, 565 TLS Finished) --------> 566 EAP-Request/ 567 EAP-Type=EAP-TLS 568 <-------- (TLS Error Alert) 569 EAP-Response/ 570 EAP-Type=EAP-TLS --------> 571 <-------- EAP-Failure 573 Figure 6: EAP-TLS unsuccessful client authentication 575 2.1.5. No Peer Authentication 577 This is a new section when compared to [RFC5216]. 579 Figure 7 shows an example message flow for a successful EAP-TLS full 580 handshake without peer authentication (e.g., emergency services, as 581 described in [RFC7406]). 583 EAP-TLS Peer EAP-TLS Server 585 EAP-Request/ 586 <-------- Identity 587 EAP-Response/ 588 Identity (Privacy-Friendly) --------> 589 EAP-Request/ 590 EAP-Type=EAP-TLS 591 <-------- (TLS Start) 592 EAP-Response/ 593 EAP-Type=EAP-TLS 594 (TLS ClientHello) --------> 595 EAP-Request/ 596 EAP-Type=EAP-TLS 597 (TLS ServerHello, 598 TLS EncryptedExtensions, 599 TLS Certificate, 600 TLS CertificateVerify, 601 <-------- TLS Finished) 602 EAP-Response/ 603 EAP-Type=EAP-TLS 604 (TLS Finished) --------> 605 EAP-Request/ 606 EAP-Type=EAP-TLS 607 <-------- (TLS Application Data 0x00) 608 EAP-Response/ 609 EAP-Type=EAP-TLS --------> 610 <-------- EAP-Success 612 Figure 7: EAP-TLS without peer authentication 614 2.1.6. Hello Retry Request 616 This is a new section when compared to [RFC5216]. 618 As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a 619 HelloRetryRequest message in response to a ClientHello if the EAP-TLS 620 server finds an acceptable set of parameters but the initial 621 ClientHello does not contain all the needed information to continue 622 the handshake. One use case is if the EAP-TLS server does not 623 support the groups in the "key_share" extension (or there is no 624 "key_share" extension), but supports one of the groups in the 625 "supported_groups" extension. In this case the client should send a 626 new ClientHello with a "key_share" that the EAP-TLS server supports. 628 Figure 8 shows an example message flow for a successful EAP-TLS full 629 handshake with mutual authentication and HelloRetryRequest. Note the 630 extra round-trip as a result of the HelloRetryRequest. 632 EAP-TLS Peer EAP-TLS Server 634 EAP-Request/ 635 <-------- Identity 636 EAP-Response/ 637 Identity (Privacy-Friendly) --------> 638 EAP-Request/ 639 EAP-Type=EAP-TLS 640 <-------- (TLS Start) 641 EAP-Response/ 642 EAP-Type=EAP-TLS 643 (TLS ClientHello) --------> 644 EAP-Request/ 645 EAP-Type=EAP-TLS 646 (TLS HelloRetryRequest) 647 <-------- 648 EAP-Response/ 649 EAP-Type=EAP-TLS 650 (TLS ClientHello) --------> 651 EAP-Request/ 652 EAP-Type=EAP-TLS 653 (TLS ServerHello, 654 TLS EncryptedExtensions, 655 TLS CertificateRequest, 656 TLS Certificate, 657 TLS CertificateVerify, 658 TLS Finished) 659 EAP-Response/ 660 EAP-Type=EAP-TLS 661 (TLS Certificate, 662 TLS CertificateVerify, 663 TLS Finished) --------> 664 EAP-Request/ 665 EAP-Type=EAP-TLS 666 <-------- (TLS Application Data 0x00) 667 EAP-Response/ 668 EAP-Type=EAP-TLS --------> 669 <-------- EAP-Success 671 Figure 8: EAP-TLS with Hello Retry Request 673 2.1.7. Identity 675 This is a new section when compared to [RFC5216]. 677 It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity 678 Response as such identities are routable and privacy-friendly. While 679 opaque blobs are allowed by [RFC3748], such identities are NOT 680 RECOMMENDED as they are not routable and should only be considered in 681 local deployments where the EAP-TLS peer, EAP authenticator, and EAP- 682 TLS server all belong to the same network. Many client certificates 683 contain an identity such as an email address, which is already in NAI 684 format. When the client certificate contains a NAI as subject name 685 or alternative subject name, an anonymous NAI SHOULD be derived from 686 the NAI in the certificate, see Section 2.1.8. More details on 687 identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. 689 2.1.8. Privacy 691 This section updates Section 2.1.4 of [RFC5216]. 693 EAP-TLS 1.3 significantly improves privacy when compared to earlier 694 versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without 695 confidentiality which means that TLS 1.3 is always encrypting large 696 parts of the TLS handshake including the certificate messages. 698 EAP-TLS peer and server implementations supporting TLS 1.3 MUST 699 support anonymous Network Access Identifiers (NAIs) (Section 2.4 in 700 [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username 701 in cleartext in the Identity Response. Following [RFC7542], it is 702 RECOMMENDED to omit the username (i.e., the NAI is @realm), but other 703 constructions such as a fixed username (e.g. anonymous@realm) or an 704 encrypted username (e.g., 705 xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. 706 Note that the NAI MUST be a UTF-8 string as defined by the grammar in 707 Section 2.2 of [RFC7542]. 709 As the certificate messages in TLS 1.3 are encrypted, there is no 710 need to send an empty certificate_list and perform a second handshake 711 for privacy (as needed by EAP-TLS with earlier versions of TLS). 712 When EAP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP- 713 TLS server SHALL follow the processing specified by version 1.3 of 714 TLS. This means that the EAP-TLS peer only sends an empty 715 certificate_list if it does not have an appropriate certificate to 716 send, and the EAP-TLS server MAY treat an empty certificate_list as a 717 terminal condition. 719 EAP-TLS with TLS 1.3 is always used with privacy. This does not add 720 any extra round-trips and the message flow with privacy is just the 721 normal message flow as shown in Figure 1. 723 2.1.9. Fragmentation 725 This section updates Section 2.1.5 of [RFC5216]. 727 Including ContentType (1 byte), ProtocolVersion (2 bytes), and length 728 (2 bytes) headers a single TLS record may be up to 16645 octets in 729 length. EAP-TLS fragmentation support is provided through addition 730 of a flags octet within the EAP-Response and EAP-Request packets, as 731 well as a TLS Message Length field of four octets. Implementations 732 MUST NOT set the L bit in unfragmented messages, but MUST accept 733 unfragmented messages with and without the L bit set. 735 Some EAP implementations and access networks may limit the number of 736 EAP packet exchanges that can be handled. To avoid fragmentation, it 737 is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and 738 trust anchor certificates small and the length of the certificate 739 chains short. In addition, it is RECOMMENDED to use mechanisms that 740 reduce the sizes of Certificate messages. For a detailed discussion 741 on reducing message sizes to prevent fragmentation, see 742 [I-D.ietf-emu-eaptlscert]. 744 2.2. Identity Verification 746 This section updates Section 2.2 of [RFC5216]. 748 The EAP peer identity provided in the EAP-Response/Identity is not 749 authenticated by EAP-TLS. Unauthenticated information MUST NOT be 750 used for accounting purposes or to give authorization. The 751 authenticator and the EAP-TLS server MAY examine the identity 752 presented in EAP-Response/Identity for purposes such as routing and 753 EAP method selection. EAP-TLS servers MAY reject conversations if 754 the identity does not match their policy. Note that this also 755 applies to resumption, see Sections 2.1.3, 5.6, and 5.7. 757 The EAP server identity in the TLS server certificate is typically a 758 fully qualified domain name (FQDN) in the SubjectAltName (SAN) 759 extension. Since EAP-TLS deployments may use more than one EAP 760 server, each with a different certificate, EAP peer implementations 761 SHOULD allow for the configuration of a unique trusted root (CA 762 certificate) to authenticate the server certificate and one or more 763 server names to match against the SubjectAltName (SAN) extension in 764 the server certificate. To simplify name matching, an EAP-TLS 765 deployment can assign a name to represent an authorized EAP server 766 and EAP Server certificates can include this name in the list of SANs 767 for each certificate that represents an EAP-TLS server. If server 768 name matching is not used, then peers may end up trusting servers for 769 EAP authentication that are not intended to be EAP servers for the 770 network. If name matching is not used with a public root CA, then 771 effectively any server can obtain a certificate which will be trusted 772 for EAP authentication by the Peer. 774 The process of configuring a root CA certificate and a server name is 775 non-trivial and therefore automated methods of provisioning are 776 RECOMMENDED. For example, the eduroam federation [RFC7593] provides 777 a Configuration Assistant Tool (CAT) to automate the configuration 778 process. In the absence of a trusted root CA certificate (user 779 configured or system-wide), EAP peers MAY implement a trust on first 780 use (TOFU) mechanism where the peer trusts and stores the server 781 certificate during the first connection attempt. The EAP peer 782 ensures that the server presents the same stored certificate on 783 subsequent interactions. Use of a TOFU mechanism does not allow for 784 the server certificate to change without out-of-band validation of 785 the certificate and is therefore not suitable for many deployments 786 including ones where multiple EAP servers are deployed for high 787 availability. 789 2.3. Key Hierarchy 791 This section updates Section 2.3 of [RFC5216]. 793 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 794 versions of TLS with HKDF and completely changes the Key Schedule. 795 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 796 not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 797 the key schedule is described in Section 7.1 of [RFC8446]. 799 When EAP-TLS is used with TLS version 1.3 the Key_Material and 800 Method-Id SHALL be derived from the exporter_secret using the TLS 801 exporter interface [RFC5705] (for TLS 1.3 this is defined in 802 Section 7.5 of [RFC8446]). 804 Type-Code = 0x0D 805 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 806 Type-Code, 128) 807 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 808 Type-Code, 64) 809 Session-Id = Type-Code || Method-Id 811 The MSK and EMSK are derived from the Key_Material in the same manner 812 as with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated 813 below for simplicity: 815 MSK = Key_Material(0, 63) 816 EMSK = Key_Material(64, 127) 818 Other TLS based EAP methods can use the TLS exporter in a similar 819 fashion, see [I-D.ietf-emu-tls-eap-types]. 821 [RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are 822 not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower 823 layers use the MSK in a lower-layer dependent manner. EAP-TLS with 824 TLS 1.3 exports the MSK and does not specify how it is used by lower 825 layers. 827 Note that the key derivation MUST use the length values given above. 828 While in TLS 1.2 and earlier it was possible to truncate the output 829 by requesting less data from the TLS-Exporter function, this practice 830 is not possible with TLS 1.3. If an implementation intends to use 831 only a part of the output of the TLS-Exporter function, then it MUST 832 ask for the full output and then only use the desired part. Failure 833 to do so will result in incorrect values being calculated for the 834 above keying material. 836 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 837 which provides a public API for the exporter. Note that EAP-TLS with 838 TLS 1.2 [RFC5216] can be used with the TLS exporter since the public 839 exporter was defined in [RFC5705]. 841 2.4. Parameter Negotiation and Compliance Requirements 843 This section updates Section 2.4 of [RFC5216]. 845 TLS 1.3 cipher suites are defined differently than in earlier 846 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 847 discussed in Section 2.4 of [RFC5216] can therefore not be used when 848 EAP-TLS is used with TLS version 1.3. 850 When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- 851 TLS servers MUST comply with the compliance requirements (mandatory- 852 to-implement cipher suites, signature algorithms, key exchange 853 algorithms, extensions, etc.) for the TLS version used. For TLS 1.3 854 the compliance requirements are defined in Section 9 of [RFC8446]. 855 In EAP-TLS with TLS 1.3, only cipher suites with confidentiality 856 SHALL be supported. 858 While EAP-TLS does not protect any application data except for the 859 TLS record with application data 0x00, the negotiated cipher suites 860 and algorithms MAY be used to secure data as done in other TLS-based 861 EAP methods. 863 2.5. EAP State Machines 865 This is a new section when compared to [RFC5216] and only applies to 866 TLS 1.3. [RFC4137] offers a proposed state machine for EAP. 868 TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- 869 Handshake messages use the handshake content type and can be sent 870 after the main handshake. Examples of Post-Handshake messages are 871 NewSessionTicket, which is used for resumption and KeyUpdate, which 872 is not useful and not expected in EAP-TLS. After sending TLS 873 Finished, the EAP-TLS server may send any number of Post-Handshake 874 messages in separate EAP-Requests. 876 To provide a protected success result indication and to decrease the 877 uncertainty for the EAP-TLS peer, the following procedure MUST be 878 followed: 880 When an EAP-TLS server has successfully processed the TLS client 881 Finished and sent its last handshake message (Finished or a Post- 882 Handshake), it sends an encrypted TLS record with application data 883 0x00. The encrypted TLS record with application data 0x00 is a 884 protected success result indication, as defined in [RFC3748]. After 885 sending a EAP-Request that contains the protected success result 886 indication, the EAP-TLS server must not send any more EAP-Request and 887 may only send an EAP-Success. The EAP-TLS server MUST NOT send an 888 encrypted TLS record with application data 0x00 alert before it has 889 successfully processed the client finished and sent its last 890 handshake message. 892 TLS Error alerts SHOULD be considered a failure result indication, as 893 defined in [RFC3748]. Implementations following [RFC4137] sets the 894 alternate indication of failure variable altReject after sending or 895 receiving an error alert. After sending or receiving a TLS Error 896 alert, the EAP-TLS server may only send an EAP-Failure. Protected 897 TLS Error alerts are protected failure result indications, 898 unprotected TLS Error alerts are not. 900 The keying material can be derived after the TLS server Finished has 901 been sent or received. Implementations following [RFC4137] can then 902 set the eapKeyData and aaaEapKeyData variables. 904 The keying material can be made available to lower layers and the 905 authenticator after the authenticated success result indication has 906 been sent or received. Implementations following [RFC4137] can set 907 the eapKeyAvailable and aaaEapKeyAvailable variables. 909 3. Detailed Description of the EAP-TLS Protocol 911 No updates to Section 3 of [RFC5216]. 913 4. IANA considerations 915 This section provides guidance to the Internet Assigned Numbers 916 Authority (IANA) regarding registration of values related to the EAP- 917 TLS 1.3 protocol in accordance with [RFC8126]. 919 This document requires IANA to add the following labels to the TLS 920 Exporter Label Registry defined by [RFC5705]. These labels are used 921 in derivation of Key_Material and Method-Id as defined in 922 Section 2.3: 924 +-------------------------------+---------+-------------+------+ 925 | Value | DTLS-OK | Recommended | Note | 926 +-------------------------------+---------+-------------+------+ 927 | EXPORTER_EAP_TLS_Key_Material | N | Y | | 928 | | | | | 929 | EXPORTER_EAP_TLS_Method-Id | N | Y | | 930 +-------------------------------+---------+-------------+------+ 932 Table 1: TLS Exporter Label Registry 934 5. Security Considerations 936 5.1. Security Claims 938 Using EAP-TLS with TLS 1.3 does not change the security claims for 939 EAP-TLS as given in Section 5.1 of [RFC5216]. However, it 940 strengthens several of the claims as described in the following 941 updates to the notes given in Section 5.1 of [RFC5216]. 943 [1] Mutual authentication: By mandating revocation checking of 944 certificates, the authentication in EAP-TLS with TLS 1.3 is stronger 945 as authentication with revoked certificates will always fail. 947 [2] Confidentiality: The TLS 1.3 handshake offers much better 948 confidentiality than earlier versions of TLS. EAP-TLS with TLS 1.3 949 mandates use of cipher suites that ensure confidentiality. TLS 1.3 950 also encrypts certificates and some of the extensions. When using 951 EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not 952 cause any additional round-trips. 954 [3] Cryptographic strength: TLS 1.3 only defines strong algorithms 955 without major weaknesses and EAP-TLS with TLS 1.3 always provides 956 forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC 957 mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated. 959 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 960 cryptographic parameters that are negotiated in the handshake. When 961 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 962 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 963 groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. 965 5.2. Peer and Server Identities 967 No updates to section 5.2 of [RFC5216]. 969 5.3. Certificate Validation 971 No updates to section 5.3 of [RFC5216]. 973 5.4. Certificate Revocation 975 This section updates Section 5.4 of [RFC5216]. 977 While certificates may have long validity periods, there are a number 978 of reasons (e.g., key compromise, CA compromise, privilege withdrawn, 979 etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have 980 to be revoked before their expiry date. Revocation of the EAP-TLS 981 server's certificate is complicated by the fact that the EAP-TLS peer 982 may not have Internet connectivity until authentication completes. 984 When EAP-TLS is used with TLS 1.3, the revocation status of all the 985 certificates in the certificate chains MUST be checked (except the 986 trust anchor). An implementation may use Certificate Revocation List 987 (CRL), Online Certificate Status Protocol (OSCP), or other 988 standardized/proprietary methods for revocation checking. Examples 989 of proprietary methods are non-standard formats for distribution of 990 revocation lists as well as certificates with very short lifetime. 992 EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 993 Requests (OCSP stapling) as specified in [RFC6066] and 994 Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers 995 and EAP-TLS servers use OCSP stapling for verifying the status of the 996 EAP-TLS server's certificate chain. When an EAP-TLS peer uses 997 Certificate Status Requests to check the revocation status of the 998 EAP-TLS server's certificate chain it MUST treat a CertificateEntry 999 (except the trust anchor) without a valid CertificateStatus extension 1000 as invalid and abort the handshake with an appropriate alert. The 1001 OCSP status handling in TLS 1.3 is different from earlier versions of 1002 TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP 1003 information is carried in the CertificateEntry containing the 1004 associated certificate instead of a separate CertificateStatus 1005 message as in [RFC6066]. This enables sending OCSP information for 1006 all certificates in the certificate chain (except the trust anchor). 1008 To enable revocation checking in situations where EAP-TLS peers do 1009 not implement or use OCSP stapling, and where network connectivity is 1010 not available prior to authentication completion, EAP-TLS peer 1011 implementations MUST also support checking for certificate revocation 1012 after authentication completes and network connectivity is available. 1013 An EAP peer implementation SHOULD NOT trust the network (and any 1014 services) until it has verified the revocation status of the server 1015 certificate after receiving network connectivity. An EAP peer MUST 1016 use a secure transport to verify the revocation status of the server 1017 certificate. An EAP peer SHOULD NOT send any other traffic before 1018 revocation checking for the server certificate is complete. 1020 5.5. Packet Modification Attacks 1022 This section updates Section 5.5 of [RFC5216]. 1024 As described in [RFC3748] and Section 5.5 of [RFC5216], the only 1025 information that is integrity and replay protected in EAP-TLS are the 1026 parts of the TLS Data that TLS protects. All other information in 1027 the EAP-TLS message exchange including EAP-Request and EAP-Response 1028 headers, the identity in the identity response, EAP-TLS packet header 1029 fields, Type, and Flags, EAP-Success, and EAP-Failure can be 1030 modified, spoofed, or replayed. 1032 Protected TLS Error alerts are protected failure result indications 1033 and enables the EAP-TLS peer and EAP-TLS server to determine that the 1034 failure result was not spoofed by an attacker. Protected failure 1035 result indications provide integrity and replay protection but MAY be 1036 unauthenticated. Protected failure results do not significantly 1037 improve availability as TLS 1.3 treats most malformed data as a fatal 1038 error. 1040 5.6. Authorization 1042 This is a new section when compared to [RFC5216]. The guidance in 1043 this section is relevant for EAP-TLS in general (regardless of the 1044 underlying TLS version used). 1046 EAP servers will usually require the EAP peer to provide a valid 1047 certificate and will fail the connection if one is not provided. 1048 Some deployments may permit no peer authentication for some or all 1049 connections. When peer authentication is not used, implementations 1050 MUST take care to limit network access appropriately for 1051 unauthenticated peers and implementations MUST use resumption with 1052 caution to ensure that a resumed session is not granted more 1053 privilege than was intended for the original session. 1055 EAP-TLS is typically encapsulated in other protocols, such as PPP 1056 [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. 1057 The encapsulating protocols can also provide additional, non-EAP 1058 information to an EAP-TLS server. This information can include, but 1059 is not limited to, information about the authenticator, information 1060 about the EAP-TLS peer, or information about the protocol layers 1061 above or below EAP (MAC addresses, IP addresses, port numbers, WiFi 1062 SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those 1063 protocols can make policy decisions and enforce authorization based 1064 on a combination of information from the EAP-TLS exchange and non-EAP 1065 information. 1067 As noted in Section 2.2, the identity presented in EAP-Response/ 1068 Identity is not authenticated by EAP-TLS and is therefore trivial for 1069 an attacker to forge, modify, or replay. Authorization and 1070 accounting MUST be based on authenticated information such as 1071 information in the certificate or the PSK identity and cached data 1072 provisioned for resumption as described in Section 5.7. Note that 1073 the requirements for Network Access Identifiers (NAIs) specified in 1074 Section 4 of [RFC7542] still apply and MUST be followed. 1076 EAP-TLS servers MAY reject conversations based on non-EAP information 1077 provided by the encapsulating protocol, for example, if the MAC 1078 address of the authenticator does not match the expected policy. 1080 5.7. Resumption 1082 This is a new section when compared to [RFC5216]. The guidance in 1083 this section is relevant for EAP-TLS in general (regardless of the 1084 underlying TLS version used). 1086 There are a number of security issues related to resumption that are 1087 not described in [RFC5216]. The problems, guidelines, and 1088 requirements in this section therefore applies to EAP-TLS when it is 1089 used with any version of TLS. 1091 When resumption occurs, it is based on cached information at the TLS 1092 layer. To perform resumption in a secure way, the EAP-TLS peer and 1093 EAP-TLS server need to be able to securely retrieve authorization 1094 information such as certificate chains from the initial full 1095 handshake. We use the term "cached data" to describe such 1096 information. Authorization during resumption MUST be based on such 1097 cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh 1098 revocation checks on the cached certificate data. Any security 1099 policies for authorization MUST be followed also for resumption. The 1100 certificates may have been revoked since the initial full handshake 1101 and the authorizations of the other party may have reduced. If the 1102 cached revocation data is not sufficiently current, the EAP-TLS peer 1103 or EAP-TLS server MAY force a full TLS handshake. 1105 There are two ways to retrieve the cached data from the original full 1106 handshake. The first method is that the EAP-TLS server and client 1107 cache the information locally. The cached information is identified 1108 by an identifier. For TLS versions before 1.3, the identifier can be 1109 the session ID, for TLS 1.3, the identifier is the PSK identity. The 1110 second method for retrieving cached information is via [RFC5077] or 1111 [RFC8446], where the EAP-TLS server avoids storing information 1112 locally and instead encapsulates the information into a ticket or PSK 1113 which is sent to the client for storage. This ticket or PSK is 1114 encrypted using a key that only the EAP-TLS server knows. Note that 1115 the client still needs to cache the original handshake information 1116 locally and will use the session ID or PSK identity to lookup this 1117 information during resumption. However, the EAP-TLS server is able 1118 to decrypt the ticket or PSK to obtain the original handshake 1119 information. 1121 If the EAP-TLS server or EAP client do not apply any authorization 1122 policies, they MAY allow resumption where no cached data is 1123 available. In all other cases, they MUST cache data during the 1124 initial full handshake to enable resumption. The cached data MUST be 1125 sufficient to make authorization decisions during resumption. If 1126 cached data cannot be retrieved in a secure way, resumption MUST NOT 1127 be done. 1129 The above requirements also apply if the EAP-TLS server expects some 1130 system to perform accounting for the session. Since accounting must 1131 be tied to an authenticated identity, and resumption does not supply 1132 such an identity, accounting is impossible without access to cached 1133 data. Therefore systems which expect to perform accounting for the 1134 session SHOULD cache an identifier which can be used in subsequent 1135 accounting. 1137 As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption 1138 PSKs or tickets (and associated cached data) for longer than 604800 1139 seconds (7 days), regardless of the PSK or ticket lifetime. The EAP- 1140 TLS peer MAY delete them earlier based on local policy. The cached 1141 data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any 1142 certificate in the certificate chain has been revoked or has expired. 1143 In all such cases, an attempt at resumption results in a full TLS 1144 handshake instead. 1146 Information from the EAP-TLS exchange (e.g., the identity provided in 1147 EAP-Response/Identity) as well as non-EAP information (e.g., IP 1148 addresses) may change between the initial full handshake and 1149 resumption. This change creates a "time-of-check time-of-use" 1150 (TOCTOU) security vulnerability. A malicious or compromised user 1151 could supply one set of data during the initial authentication, and a 1152 different set of data during resumption, potentially allowing them to 1153 obtain access that they should not have. 1155 If any authorization, accounting, or policy decisions were made with 1156 information that has changed between the initial full handshake and 1157 resumption, and if change may lead to a different decision, such 1158 decisions MUST be reevaluated. It is RECOMMENDED that authorization, 1159 accounting, and policy decisions are reevaluated based on the 1160 information given in the resumption. EAP-TLS servers MAY reject 1161 resumption where the information supplied during resumption does not 1162 match the information supplied during the original authentication. 1163 If a safe decision is not possible, EAP-TLS servers SHOULD reject the 1164 resumption and continue with a full handshake. 1166 Section 2.2 and 4.2.11 of [RFC8446] provides security considerations 1167 for TLS 1.3 resumption. 1169 5.8. Privacy Considerations 1171 This is a new section when compared to [RFC5216]. 1173 TLS 1.3 offers much better privacy than earlier versions of TLS as 1174 discussed in Section 2.1.8. In this section, we only discuss the 1175 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 1176 of TLS 1.3 itself, see [RFC8446]. 1178 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 1179 EAP packets. Additionally, the EAP-TLS peer sends an identity in the 1180 first EAP-Response. The other fields in the EAP-TLS Request and the 1181 EAP-TLS Response packets do not contain any cleartext privacy 1182 sensitive information. 1184 Tracking of users by eavesdropping on identity responses or 1185 certificates is a well-known problem in many EAP methods. When EAP- 1186 TLS is used with TLS 1.3, all certificates are encrypted, and the 1187 username part of the identity response is not revealed (e.g., using 1188 anonymous NAIs). Note that even though all certificates are 1189 encrypted, the server's identity is only protected against passive 1190 attackers while client's identity is protected against both passive 1191 and active attackers. As with other EAP methods, even when privacy- 1192 friendly identifiers or EAP tunneling is used, the domain name (i.e., 1193 the realm) in the NAI is still typically visible. How much privacy 1194 sensitive information the domain name leaks is highly dependent on 1195 how many other users are using the same domain name in the particular 1196 access network. If all EAP-TLS peers have the same domain, no 1197 additional information is leaked. If a domain name is used by a 1198 small subset of the EAP-TLS peers, it may aid an attacker in tracking 1199 or identifying the user. 1201 Without padding, information about the size of the client certificate 1202 is leaked from the size of the EAP-TLS packets. The EAP-TLS packets 1203 sizes may therefore leak information that can be used to track or 1204 identify the user. If all client certificates have the same length, 1205 no information is leaked. EAP-TLS peers SHOULD use record padding, 1206 see Section 5.4 of [RFC8446] to reduce information leakage of 1207 certificate sizes. 1209 If anonymous NAIs are not used, the privacy-friendly identifiers need 1210 to be generated with care. The identities MUST be generated in a 1211 cryptographically secure way so that that it is computationally 1212 infeasible for an attacker to differentiate two identities belonging 1213 to the same user from two identities belonging to different users in 1214 the same realm. This can be achieved, for instance, by using random 1215 or pseudo-random usernames such as random byte strings or ciphertexts 1216 and only using the pseudo-random usernames a single time. Note that 1217 the privacy-friendly usernames also MUST NOT include substrings that 1218 can be used to relate the identity to a specific user. Similarly, 1219 privacy-friendly username MUST NOT be formed by a fixed mapping that 1220 stays the same across multiple different authentications. 1222 An EAP-TLS peer with a policy allowing communication with EAP-TLS 1223 servers supporting only TLS 1.2 without privacy and with a static RSA 1224 key exchange is vulnerable to disclosure of the EAP-TLS peer 1225 username. An active attacker can in this case make the EAP-TLS peer 1226 believe that an EAP-TLS server supporting TLS 1.3 only supports TLS 1227 1.2 without privacy. The attacker can simply impersonate the EAP-TLS 1228 server and negotiate TLS 1.2 with static RSA key exchange and send an 1229 TLS alert message when the EAP-TLS peer tries to use privacy by 1230 sending an empty certificate message. Since the attacker 1231 (impersonating the EAP-TLS server) does not provide a proof-of- 1232 possession of the private key until the Finished message when a 1233 static RSA key exchange is used, an EAP-TLS peer may inadvertently 1234 disclose its identity (username) to an attacker. Therefore, it is 1235 RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and 1236 static RSA based cipher suites without privacy. This implies that an 1237 EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS 1238 server sends an EAP-TLS/Request with a TLS alert message in response 1239 to an empty certificate message from the peer. 1241 5.9. Pervasive Monitoring 1243 This is a new section when compared to [RFC5216]. 1245 Pervasive monitoring refers to widespread surveillance of users. In 1246 the context of EAP-TLS, pervasive monitoring attacks can target EAP- 1247 TLS peer devices for tracking them (and their users) as and when they 1248 join a network. By encrypting more information, mandating the use of 1249 privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3 1250 offers much better protection against pervasive monitoring. In 1251 addition to the privacy attacks discussed above, surveillance on a 1252 large scale may enable tracking of a user over a wide geographical 1253 area and across different access networks. Using information from 1254 EAP-TLS together with information gathered from other protocols 1255 increases the risk of identifying individual users. 1257 5.10. Discovered Vulnerabilities 1259 This is a new section when compared to [RFC5216]. 1261 Over the years, there have been several serious attacks on earlier 1262 versions of Transport Layer Security (TLS), including attacks on its 1263 most commonly used ciphers and modes of operation. [RFC7457] 1264 summarizes the attacks that were known at the time of publishing and 1265 BCP 195 [RFC7525] provides recommendations for improving the security 1266 of deployed services that use TLS. However, many of the attacks are 1267 less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and 1268 does not protect any application data. EAP-TLS implementations MUST 1269 mitigate known attacks. EAP-TLS implementations need to monitor and 1270 follow new EAP and TLS related security guidance and requirements 1271 such as [RFC8447], [RFC8996], [I-D.ietf-tls-md5-sha1-deprecate]. 1273 6. References 1275 6.1. Normative References 1277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1278 Requirement Levels", BCP 14, RFC 2119, 1279 DOI 10.17487/RFC2119, March 1997, 1280 . 1282 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1283 Levkowetz, Ed., "Extensible Authentication Protocol 1284 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1285 . 1287 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1288 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1289 March 2008, . 1291 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1292 Housley, R., and W. Polk, "Internet X.509 Public Key 1293 Infrastructure Certificate and Certificate Revocation List 1294 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1295 . 1297 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1298 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1299 March 2010, . 1301 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1302 Extensions: Extension Definitions", RFC 6066, 1303 DOI 10.17487/RFC6066, January 2011, 1304 . 1306 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1307 Galperin, S., and C. Adams, "X.509 Internet Public Key 1308 Infrastructure Online Certificate Status Protocol - OCSP", 1309 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1310 . 1312 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1313 DOI 10.17487/RFC7542, May 2015, 1314 . 1316 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1317 Writing an IANA Considerations Section in RFCs", BCP 26, 1318 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1319 . 1321 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1322 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1323 May 2017, . 1325 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1326 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1327 . 1329 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1330 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1331 . 1333 6.2. Informative references 1335 [I-D.ietf-emu-eaptlscert] 1336 Sethi, M., Mattsson, J., and S. Turner, "Handling Large 1337 Certificates and Long Certificate Chains in TLS-based EAP 1338 Methods", draft-ietf-emu-eaptlscert-08 (work in progress), 1339 November 2020. 1341 [I-D.ietf-emu-tls-eap-types] 1342 DeKok, A., "TLS-based EAP types and TLS 1.3", draft-ietf- 1343 emu-tls-eap-types-02 (work in progress), February 2021. 1345 [I-D.ietf-tls-md5-sha1-deprecate] 1346 Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating 1347 MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf- 1348 tls-md5-sha1-deprecate-06 (work in progress), March 2021. 1350 [I-D.ietf-tls-rfc8446bis] 1351 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1352 Version 1.3", draft-ietf-tls-rfc8446bis-01 (work in 1353 progress), February 2021. 1355 [I-D.ietf-tls-ticketrequests] 1356 Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket 1357 Requests", draft-ietf-tls-ticketrequests-07 (work in 1358 progress), December 2020. 1360 [IEEE-802.11] 1361 Institute of Electrical and Electronics Engineers, "IEEE 1362 Standard for Information technology--Telecommunications 1363 and information exchange between systems Local and 1364 metropolitan area networks--Specific requirements - Part 1365 11: Wireless LAN Medium Access Control (MAC) and Physical 1366 Layer (PHY) Specifications", IEEE Standard 802.11-2020 , 1367 February 2021. 1369 [IEEE-802.1AE] 1370 Institute of Electrical and Electronics Engineers, "IEEE 1371 Standard for Local and metropolitan area networks -- Media 1372 Access Control (MAC) Security", IEEE Standard 1373 802.1AE-2018 , December 2018. 1375 [IEEE-802.1X] 1376 Institute of Electrical and Electronics Engineers, "IEEE 1377 Standard for Local and metropolitan area networks -- Port- 1378 Based Network Access Control", IEEE Standard 802.1X-2020 , 1379 February 2020. 1381 [MulteFire] 1382 MulteFire, "MulteFire Release 1.1 specification", 2019. 1384 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 1385 Authentication Protocol (PEAP)", April 2021. 1387 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1388 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1389 . 1391 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1392 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1393 . 1395 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1396 Adams, "X.509 Internet Public Key Infrastructure Online 1397 Certificate Status Protocol - OCSP", RFC 2560, 1398 DOI 10.17487/RFC2560, June 1999, 1399 . 1401 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1402 "Remote Authentication Dial In User Service (RADIUS)", 1403 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1404 . 1406 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1407 X.509 Public Key Infrastructure Certificate and 1408 Certificate Revocation List (CRL) Profile", RFC 3280, 1409 DOI 10.17487/RFC3280, April 2002, 1410 . 1412 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 1413 "State Machines for Extensible Authentication Protocol 1414 (EAP) Peer and Authenticator", RFC 4137, 1415 DOI 10.17487/RFC4137, August 2005, 1416 . 1418 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1419 Network Access Identifier", RFC 4282, 1420 DOI 10.17487/RFC4282, December 2005, 1421 . 1423 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1424 (TLS) Protocol Version 1.1", RFC 4346, 1425 DOI 10.17487/RFC4346, April 2006, 1426 . 1428 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 1429 Flexible Authentication via Secure Tunneling Extensible 1430 Authentication Protocol Method (EAP-FAST)", RFC 4851, 1431 DOI 10.17487/RFC4851, May 2007, 1432 . 1434 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1435 "Transport Layer Security (TLS) Session Resumption without 1436 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1437 January 2008, . 1439 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1440 and A. Yegin, "Protocol for Carrying Authentication for 1441 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1442 May 2008, . 1444 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1445 (TLS) Protocol Version 1.2", RFC 5246, 1446 DOI 10.17487/RFC5246, August 2008, 1447 . 1449 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1450 Authentication Protocol (EAP) Key Management Framework", 1451 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1452 . 1454 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1455 Protocol Tunneled Transport Layer Security Authenticated 1456 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 1457 DOI 10.17487/RFC5281, August 2008, 1458 . 1460 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1461 Ed., "Diameter Base Protocol", RFC 6733, 1462 DOI 10.17487/RFC6733, October 2012, 1463 . 1465 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1466 "Tunnel Extensible Authentication Protocol (TEAP) Version 1467 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1468 . 1470 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1471 and D. Kroeselberg, "Extensions to the Emergency Services 1472 Architecture for Dealing With Unauthenticated and 1473 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1474 December 2014, . 1476 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1477 Known Attacks on Transport Layer Security (TLS) and 1478 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1479 February 2015, . 1481 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1482 "Recommendations for Secure Use of Transport Layer 1483 Security (TLS) and Datagram Transport Layer Security 1484 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1485 2015, . 1487 [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 1488 Architecture for Network Roaming", RFC 7593, 1489 DOI 10.17487/RFC7593, September 2015, 1490 . 1492 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1493 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1494 . 1496 [TS.33.501] 1497 3GPP, "Security architecture and procedures for 5G 1498 System", 3GPP TS 33.501 17.1.0, April 2021. 1500 Appendix A. Updated references 1502 All the following references in [RFC5216] are updated as specified 1503 below when EAP-TLS is used with TLS 1.3. 1505 All references to [RFC2560] are updated with [RFC6960]. 1507 All references to [RFC3280] are updated with [RFC5280]. 1509 All references to [RFC4282] are updated with [RFC7542]. 1511 Acknowledgments 1513 The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, 1514 Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, 1515 Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa 1516 Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and 1517 suggestions on the draft. 1519 Contributors 1521 Alan DeKok, FreeRADIUS 1523 Authors' Addresses 1525 John Preuss Mattsson 1526 Ericsson 1527 Stockholm 164 40 1528 Sweden 1530 Email: john.mattsson@ericsson.com 1532 Mohit Sethi 1533 Ericsson 1534 Jorvas 02420 1535 Finland 1537 Email: mohit@piuha.net