idnits 2.17.1 draft-simon-emu-rfc2716bis-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1476. 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 Copyright Line does not match the current year -- 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 (9 January 2008) is 5949 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: '4' on line 1050 -- Looks like a reference, but probably isn't: '1' on line 1033 -- Looks like a reference, but probably isn't: '2' on line 1041 -- Looks like a reference, but probably isn't: '3' on line 1043 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3268 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-10) exists of draft-ietf-tls-rfc4346-bis-07 == Outdated reference: A later version (-08) exists of draft-schulzrinne-ecrit-unauthenticated-access-01 Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU Working Group Dan Simon 3 Internet-Draft Bernard Aboba 4 Obsoletes: 2716 Ryan Hurst 5 Category: Proposed Standard Microsoft Corporation 6 Expires: August 25, 2008 9 January 2008 8 The EAP TLS Authentication Protocol 9 draft-simon-emu-rfc2716bis-13.txt 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 25, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). All rights reserved. 38 Abstract 40 The Extensible Authentication Protocol (EAP), defined in RFC 3748, 41 provides support for multiple authentication methods. Transport 42 Level Security (TLS) provides for mutual authentication, integrity- 43 protected ciphersuite negotiation and key exchange between two 44 endpoints. This document defines EAP-TLS, which includes support for 45 certificate-based mutual authentication and key derivation. 47 This document obsoletes RFC 2716. A summary of the changes between 48 this document and RFC 2716 is available in Appendix A. 50 Table of Contents 52 1. Introduction.............................................. 3 53 1.1 Requirements Language ........................... 3 54 1.2 Terminology ..................................... 3 55 2. Protocol Overview ........................................ 4 56 2.1 Overview of the EAP-TLS Conversation ............ 4 57 2.2 Identity Verification ........................... 15 58 2.3 Key Hierarchy ................................... 16 59 2.4 Ciphersuite and Compression Negotiation ......... 18 60 3. Detailed Description of the EAP-TLS Protocol ............. 19 61 3.1 EAP TLS Request Packet ......................... 19 62 3.2 EAP TLS Response Packet ........................ 21 63 4. IANA Considerations ...................................... 22 64 5. Security Considerations .................................. 22 65 5.1 Security Claims ................................ 22 66 5.2 Peer and Server Identities ..................... 23 67 5.3 Certificate Validation ......................... 24 68 5.4 Certificate Revocation ......................... 25 69 5.5 Packet Modification Attacks .................... 26 70 6. References ............................................... 27 71 6.1 Normative references ....... .................... 27 72 6.2 Informative references .......................... 28 73 Acknowledgments .............................................. 29 74 Authors' Addresses ........................................... 30 75 Appendix A - Changes from RFC 2716 ........................... 31 76 Full Copyright Statement ..................................... 32 77 Intellectual Property ........................................ 32 78 1. Introduction 80 The Extensible Authentication Protocol (EAP), described in [RFC3748], 81 provides a standard mechanism for support of multiple authentication 82 methods. Through the use of EAP, support for a number of 83 authentication schemes may be added, including smart cards, Kerberos, 84 Public Key, One Time Passwords, and others. EAP has been defined for 85 use with a variety of lower layers, including Point-to-Point Protocol 86 (PPP) [RFC1661], Layer 2 tunneling protocols such as PPTP [RFC2637] 87 or L2TP [RFC2661], IEEE 802 wired networks [IEEE-802.1X] and wireless 88 technologies such as IEEE 802.11 [IEEE-802.11] and IEEE 802.16 89 [IEEE-802.16e]. 91 While the EAP methods defined in [RFC3748] did not support mutual 92 authentication, the use of EAP with wireless technologies such as 93 [IEEE-802.11] has resulted in development of a new set of 94 requirements. As described in "EAP Method Requirements for Wireless 95 LANs" [RFC4017], it is desirable for EAP methods used for wireless 96 LAN authentication to support mutual authentication and key 97 derivation. Other link layers can also make use of EAP to enable 98 mutual authentication and key derivation. 100 This document defines EAP-Transport Layer Security (EAP-TLS), which 101 includes support for certificate-based mutual authentication and key 102 derivation, utilizing the protected ciphersuite negotiation, mutual 103 authentication and key management capabilities of the TLS protocol, 104 described in "The Transport Layer Security (TLS) Protocol Version 105 1.1" [RFC4346]. While this document obsoletes RFC 2716 [RFC2716], it 106 remains backward compatible with it. A summary of the changes 107 between this document and RFC 2716 is available in Appendix A. 109 1.1. Requirements 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 1.2. Terminology 117 This document frequently uses the following terms: 119 authenticator 120 The entity initiating EAP authentication. 122 peer The entity that responds to the authenticator. In [IEEE-802.1X], 123 this entity is known as the Supplicant. 125 backend authentication server 126 A backend authentication server is an entity that provides an 127 authentication service to an authenticator. When used, this server 128 typically executes EAP methods for the authenticator. This 129 terminology is also used in [IEEE-802.1X]. 131 EAP server 132 The entity that terminates the EAP authentication method with the 133 peer. In the case where no backend authentication server is used, 134 the EAP server is part of the authenticator. In the case where the 135 authenticator operates in pass-through mode, the EAP server is 136 located on the backend authentication server. 138 Master Session Key (MSK) 139 Keying material that is derived between the EAP peer and server and 140 exported by the EAP method. 142 Extended Master Session Key (EMSK) 143 Additional keying material derived between the EAP peer and server 144 that is exported by the EAP method. 146 2. Protocol Overview 148 2.1. Overview of the EAP-TLS Conversation 150 As described in [RFC3748], the EAP-TLS conversation will typically 151 begin with the authenticator and the peer negotiating EAP. The 152 authenticator will then typically send an EAP-Request/Identity packet 153 to the peer, and the peer will respond with an EAP-Response/Identity 154 packet to the authenticator, containing the peer's user-Id. 156 From this point forward, while nominally the EAP conversation occurs 157 between the EAP authenticator and the peer, the authenticator MAY act 158 as a pass-through device, with the EAP packets received from the peer 159 being encapsulated for transmission to a backend authentication 160 server. In the discussion that follows, we will use the term "EAP 161 server" to denote the ultimate endpoint conversing with the peer. 163 2.1.1. Base Case 165 Once having received the peer's Identity, the EAP server MUST respond 166 with an EAP-TLS/Start packet, which is an EAP-Request packet with 167 EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS 168 conversation will then begin, with the peer sending an EAP-Response 169 packet with EAP-Type=EAP-TLS. The data field of that packet will 170 encapsulate one or more TLS records in TLS record layer format, 171 containing a TLS client_hello handshake message. The current cipher 172 spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null 173 compression. This current cipher spec remains the same until the 174 change_cipher_spec message signals that subsequent records will have 175 the negotiated attributes for the remainder of the handshake. 177 The client_hello message contains the peer's TLS version number, a 178 sessionId, a random number, and a set of ciphersuites supported by 179 the peer. The version offered by the peer MUST correspond to TLS 180 v1.0 or later. 182 The EAP server will then respond with an EAP-Request packet with EAP- 183 Type=EAP-TLS. The data field of this packet will encapsulate one or 184 more TLS records. These will contain a TLS server_hello handshake 185 message, possibly followed by TLS certificate, server_key_exchange, 186 certificate_request, server_hello_done and/or finished handshake 187 messages, and/or a TLS change_cipher_spec message. The server_hello 188 handshake message contains a TLS version number, another random 189 number, a sessionId, and a ciphersuite. The version offered by the 190 server MUST correspond to TLS v1.0 or later. 192 If the peer's sessionId is null or unrecognized by the server, the 193 server MUST choose the sessionId to establish a new session. 194 Otherwise, the sessionId will match that offered by the peer, 195 indicating a resumption of the previously established session with 196 that sessionId. The server will also choose a ciphersuite from those 197 offered by the peer. If the session matches the peer's, then the 198 ciphersuite MUST match the one negotiated during the handshake 199 protocol execution that established the session. 201 If the EAP server is not resuming a previously established session, 202 then it MUST include a TLS server_certificate handshake message, and 203 a server_hello_done handshake message MUST be the last handshake 204 message encapsulated in this EAP-Request packet. 206 The certificate message contains a public key certificate chain for 207 either a key exchange public key (such as an RSA or Diffie-Hellman 208 key exchange public key) or a signature public key (such as an RSA or 209 DSS signature public key). In the latter case, a TLS 210 server_key_exchange handshake message MUST also be included to allow 211 the key exchange to take place. 213 The certificate_request message is included when the server desires 214 the peer to authenticate itself via public key. While the EAP server 215 SHOULD require peer authentication, this is not mandatory, since 216 there are circumstances in which peer authentication will not be 217 needed (e.g., emergency services, as described in [UNAUTH]), or where 218 the peer will authenticate via some other means. 220 If the peer supports EAP-TLS and is configured to use it, it MUST 221 respond to the EAP-Request with an EAP-Response packet of EAP- 222 Type=EAP-TLS. If the preceding server_hello message sent by the EAP 223 server in the preceding EAP-Request packet did not indicate the 224 resumption of a previous session, the data field of this packet MUST 225 encapsulate one or more TLS records containing a TLS 226 client_key_exchange, change_cipher_spec and finished messages. If 227 the EAP server sent a certificate_request message in the preceding 228 EAP-Request packet, then unless the peer is configured for privacy 229 (see Section 2.1.4) the peer MUST send, in addition, certificate and 230 certificate_verify messages. The former contains a certificate for 231 the peer's signature public key, while the latter contains the peer's 232 signed authentication response to the EAP server. After receiving 233 this packet, the EAP server will verify the peer's certificate and 234 digital signature, if requested. 236 If the preceding server_hello message sent by the EAP server in the 237 preceding EAP-Request packet indicated the resumption of a previous 238 session, then the peer MUST send only the change_cipher_spec and 239 finished handshake messages. The finished message contains the 240 peer's authentication response to the EAP server. 242 In the case where the EAP-TLS mutual authentication is successful, 243 the conversation will appear as follows: 245 Authenticating Peer Authenticator 246 ------------------- ------------- 247 <- EAP-Request/ 248 Identity 249 EAP-Response/ 250 Identity (MyID) -> 251 <- EAP-Request/ 252 EAP-Type=EAP-TLS 253 (TLS Start) 254 EAP-Response/ 255 EAP-Type=EAP-TLS 256 (TLS client_hello)-> 257 <- EAP-Request/ 258 EAP-Type=EAP-TLS 259 (TLS server_hello, 260 TLS certificate, 261 [TLS server_key_exchange,] 262 TLS certificate_request, 263 TLS server_hello_done) 264 EAP-Response/ 265 EAP-Type=EAP-TLS 266 (TLS certificate, 267 TLS client_key_exchange, 268 TLS certificate_verify, 269 TLS change_cipher_spec, 270 TLS finished) -> 271 <- EAP-Request/ 272 EAP-Type=EAP-TLS 273 (TLS change_cipher_spec, 274 TLS finished) 275 EAP-Response/ 276 EAP-Type=EAP-TLS -> 277 <- EAP-Success 279 2.1.2. Session Resumption 281 The purpose of the sessionId within the TLS protocol is to allow for 282 improved efficiency in the case where a peer repeatedly attempts to 283 authenticate to an EAP server within a short period of time. While 284 this model was developed for use with HTTP authentication, it also 285 can be used to provide "fast reconnect" functionality as defined in 286 [RFC3748] Section 7.2.1. 288 It is left up to the peer whether to attempt to continue a previous 289 session, thus shortening the TLS conversation. Typically the peer's 290 decision will be made based on the time elapsed since the previous 291 authentication attempt to that EAP server. Based on the sessionId 292 chosen by the peer, and the time elapsed since the previous 293 authentication, the EAP server will decide whether to allow the 294 continuation, or whether to choose a new session. 296 In the case where the EAP server and authenticator reside on the same 297 device, the peer will only be able to continue sessions when 298 connecting to the same authenticator. Should the authenticators be 299 set up in a rotary or round-robin then it may not be possible for the 300 peer to know in advance the authenticator it will be connecting to, 301 and therefore which sessionId to attempt to reuse. As a result, it 302 is likely that the continuation attempt will fail. In the case where 303 the EAP authentication is remoted then continuation is much more 304 likely to be successful, since multiple authenticators will utilize 305 the same backend authentication server. 307 If the EAP server is resuming a previously established session, then 308 it MUST include only a TLS change_cipher_spec message and a TLS 309 finished handshake message after the server_hello message. The 310 finished message contains the EAP server's authentication response to 311 the peer. 313 In the case where a previously established session is being resumed, 314 and both sides authenticate successfully, the conversation will 315 appear as follows: 317 Authenticating Peer Authenticator 318 ------------------- ------------- 319 <- EAP-Request/ 320 Identity 321 EAP-Response/ 322 Identity (MyID) -> 323 <- EAP-Request/ 324 EAP-Request/ 325 EAP-Type=EAP-TLS 326 (TLS Start) 327 EAP-Response/ 328 EAP-Type=EAP-TLS 329 (TLS client_hello)-> 330 <- EAP-Request/ 331 EAP-Type=EAP-TLS 332 (TLS server_hello, 333 TLS change_cipher_spec 334 TLS finished) 335 EAP-Response/ 336 EAP-Type=EAP-TLS 337 (TLS change_cipher_spec, 338 TLS finished) -> 339 <- EAP-Success 341 2.1.3. Termination 343 If the peer's authentication is unsuccessful, the EAP server SHOULD 344 send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS 345 record containing the appropriate TLS alert message. The EAP server 346 SHOULD send a TLS alert message immediately terminating the 347 conversation so as to allow the peer to inform the user or log the 348 cause of the failure and possibly allow for a restart of the 349 conversation. 351 To ensure that the peer receives the TLS alert message, the EAP 352 server MUST wait for the peer to reply with an EAP-Response packet. 353 The EAP-Response packet sent by the peer MAY encapsulate a TLS 354 client_hello handshake message, in which case the EAP server MAY 355 allow the EAP-TLS conversation to be restarted, or it MAY contain an 356 EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case 357 the EAP-Server MUST send an EAP-Failure packet, and terminate the 358 conversation. It is up to the EAP server whether to allow restarts, 359 and if so, how many times the conversation can be restarted. An EAP 360 Server implementing restart capability SHOULD impose a per-peer limit 361 on the number of restarts, so as to protect against denial of service 362 attacks. 364 If the peer authenticates successfully, the EAP server MUST respond 365 with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in 366 the case of a new TLS session, one or more TLS records containing TLS 367 change_cipher_spec and finished handshake messages. The latter 368 contains the EAP server's authentication response to the peer. The 369 peer will then verify the finished message in order to authenticate 370 the EAP server. 372 If EAP server authentication is unsuccessful, the peer SHOULD delete 373 the session from its cache, preventing reuse of the sessionId. The 374 peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a 375 TLS Alert message identifying the reason for the failed 376 authentication. The peer MAY send a TLS alert message rather than 377 immediately terminating the conversation so as to allow the EAP 378 server to log the cause of the error for examination by the system 379 administrator. 381 To ensure that the EAP Server receives the TLS alert message, the 382 peer MUST wait for the EAP-Server to reply before terminating the 383 conversation. The EAP Server MUST reply with an EAP-Failure packet 384 since server authentication failure is a terminal condition. 386 If the EAP server authenticates successfully, the peer MUST send an 387 EAP-Response packet of EAP-Type=EAP-TLS, and no data. The EAP-Server 388 then MUST respond with an EAP-Success message. 390 In the case where the server authenticates to the peer successfully, 391 but the peer fails to authenticate to the server, the conversation 392 will appear as follows: 394 Authenticating Peer Authenticator 395 ------------------- ------------- 396 <- EAP-Request/ 397 Identity 398 EAP-Response/ 399 Identity (MyID) -> 400 <- EAP-Request/ 401 EAP-Type=EAP-TLS 402 (TLS Start) 403 EAP-Response/ 404 EAP-Type=EAP-TLS 405 (TLS client_hello)-> 406 <- EAP-Request/ 407 EAP-Type=EAP-TLS 408 (TLS server_hello, 409 TLS certificate, 410 [TLS server_key_exchange,] 411 TLS certificate_request, 412 TLS server_hello_done) 414 EAP-Response/ 415 EAP-Type=EAP-TLS 416 (TLS certificate, 417 TLS client_key_exchange, 418 TLS certificate_verify, 419 TLS change_cipher_spec, 420 TLS finished) -> 421 <- EAP-Request/ 422 EAP-Type=EAP-TLS 423 (TLS change_cipher_spec, 424 TLS finished) 425 EAP-Response/ 426 EAP-Type=EAP-TLS -> 427 <- EAP-Request 428 EAP-Type=EAP-TLS 429 (TLS Alert message) 430 EAP-Response/ 431 EAP-Type=EAP-TLS -> 432 <- EAP-Failure 433 (User Disconnected) 435 In the case where server authentication is unsuccessful, the 436 conversation will appear as follows: 438 Authenticating Peer Authenticator 439 ------------------- ------------- 440 <- EAP-Request/ 441 Identity 442 EAP-Response/ 443 Identity (MyID) -> 444 <- EAP-Request/ 445 EAP-Type=EAP-TLS 446 (TLS Start) 447 EAP-Response/ 448 EAP-Type=EAP-TLS 449 (TLS client_hello)-> 450 <- EAP-Request/ 451 EAP-Type=EAP-TLS 452 (TLS server_hello, 453 TLS certificate, 454 [TLS server_key_exchange,] 455 TLS certificate_request, 456 TLS server_hello_done) 457 EAP-Response/ 458 EAP-Type=EAP-TLS 459 (TLS Alert message) -> 460 <- EAP-Failure 461 (User Disconnected) 463 2.1.4. Privacy 465 EAP-TLS peer and server implementations MAY support privacy. 466 Disclosure of the username is avoided by utilizing a privacy Network 467 Access Identifier (NAI) [RFC4282] in the EAP-Response/Identity, and 468 transmitting the peer certificate within a TLS session providing 469 confidentiality. 471 In order to avoid disclosing the peer username, an EAP-TLS peer 472 configured for privacy MUST negotiate a TLS ciphersuite supporting 473 confidentiality and MUST provide a client certificate list containing 474 no entries in response to the initial certificate_request from the 475 EAP-TLS server. 477 An EAP-TLS server supporting privacy MUST NOT treat a certificate 478 list containing no entries as a terminal condition; instead it MUST 479 bring up the TLS session and then send a hello_request. The 480 handshake then proceeds normally; the peer sends a client_hello and 481 the server replies with a server_hello, certificate, 482 server_key_exchange, certificate_request, server_hello_done, etc. 483 For the calculation of exported keying material (see Section 2.3), 484 the master_secret derived within the second handshake is used. 486 An EAP-TLS peer supporting privacy MUST provide a certificate list 487 containing at least one entry in response to the subsequent 488 certificate_request sent by the server. If the EAP-TLS server 489 supporting privacy does not receive a client certificate in response 490 to the subsequent certificate_request, then it MUST abort the 491 session. 493 EAP-TLS privacy support is designed to allow EAP-TLS peers that do 494 not support privacy to interoperate with EAP-TLS servers supporting 495 privacy. EAP-TLS servers supporting privacy MUST request a client 496 certificate, and MUST be able to accept a client certificate offered 497 by the EAP-TLS peer, in order to preserve interoperability with EAP- 498 TLS peers that do not support privacy. 500 However, an EAP-TLS peer configured for privacy typically will not be 501 able to successfully authenticate with an EAP-TLS server that does 502 not support privacy, since such a server will typically treat the 503 refusal to provide a client certificate as a terminal error. As a 504 result, unless authentication failure is considered preferable to 505 disclosure of the username, EAP-TLS peers SHOULD only be configured 506 for privacy on networks known to support it. 508 This is most easily achieved with EAP lower layers that support 509 network advertisement, so that the network and appropriate privacy 510 configuration can be determined. In order to determine the privacy 511 configuration on link layers (such as IEEE 802 wired networks) which 512 do not support network advertisement, it may be desirable to utilize 513 information provided in the server certificate (such as the subject 514 and subjectAltName fields) or within identity selection hints 515 [RFC4284] to determine the appropriate configuration. 517 In the case where the peer and server support privacy and mutual 518 authentication, the conversation will appear as follows: 520 Authenticating Peer Authenticator 521 ------------------- ------------- 522 <- EAP-Request/ 523 Identity 524 EAP-Response/ 525 Identity (Anonymous NAI) -> 526 <- EAP-Request/ 527 EAP-Type=EAP-TLS 528 (TLS Start) 529 EAP-Response/ 530 EAP-Type=EAP-TLS 531 (TLS client_hello)-> 532 <- EAP-Request/ 533 EAP-Type=EAP-TLS 534 (TLS server_hello, 535 TLS certificate, 536 [TLS server_key_exchange,] 537 TLS certificate_request, 538 TLS server_hello_done) 539 EAP-Response/ 540 EAP-Type=EAP-TLS 541 (TLS certificate (no cert), 542 TLS client_key_exchange, 543 TLS change_cipher_spec, 544 TLS finished) -> 545 <- EAP-Request/ 546 EAP-Type=EAP-TLS 547 (TLS change_cipher_spec, 548 finished, 549 hello_request) 550 EAP-Response/ 551 EAP-Type=EAP-TLS 552 (TLS client_hello)-> 553 <- EAP-Request/ 554 EAP-Type=EAP-TLS 555 (TLS server_hello, 556 TLS certificate, 557 TLS server_key_exchange, 558 TLS certificate_request, 559 TLS server_hello_done) 560 EAP-Response/ 561 EAP-Type=EAP-TLS 562 (TLS certificate, 563 TLS client_key_exchange, 564 TLS certificate_verify, 565 TLS change_cipher_spec, 566 TLS finished) -> 567 <- EAP-Request/ 568 EAP-Type=EAP-TLS 569 (TLS change_cipher_spec, 570 TLS finished) 571 EAP-Response/ 572 EAP-Type=EAP-TLS -> 573 <- EAP-Success 575 2.1.5. Fragmentation 577 A single TLS record may be up to 16384 octets in length, but a TLS 578 message may span multiple TLS records, and a TLS certificate message 579 may in principle be as long as 16MB. The group of EAP-TLS messages 580 sent in a single round may thus be larger than the MTU size or the 581 maximum RADIUS packet size of 4096 octets. As a result, an EAP-TLS 582 implementation MUST provide its own support for fragmentation and 583 reassembly. However, in order to ensure interoperability with 584 existing implementations, TLS handshake messages SHOULD NOT be 585 fragmented into multiple TLS records if they fit within a single TLS 586 record. 588 In order to protect against reassembly lockup and denial of service 589 attacks, it may be desirable for an implementation to set a maximum 590 size for one such group of TLS messages. Since a single certificate 591 is rarely longer than a few thousand octets, and no other field is 592 likely to be anywhere near as long, a reasonable choice of maximum 593 acceptable message length might be 64 KB. 595 Since EAP is a simple ACK-NAK protocol, fragmentation support can be 596 added in a simple manner. In EAP, fragments that are lost or damaged 597 in transit will be retransmitted, and since sequencing information is 598 provided by the Identifier field in EAP, there is no need for a 599 fragment offset field as is provided in IPv4. 601 EAP-TLS fragmentation support is provided through addition of a flags 602 octet within the EAP-Response and EAP-Request packets, as well as a 603 TLS Message Length field of four octets. Flags include the Length 604 included (L), More fragments (M), and EAP-TLS Start (S) bits. The L 605 flag is set to indicate the presence of the four octet TLS Message 606 Length field, and MUST be set for the first fragment of a fragmented 607 TLS message or set of messages. The M flag is set on all but the last 608 fragment. The S flag is set only within the EAP-TLS start message 609 sent from the EAP server to the peer. The TLS Message Length field is 610 four octets, and provides the total length of the TLS message or set 611 of messages that is being fragmented; this simplifies buffer 612 allocation. 614 When an EAP-TLS peer receives an EAP-Request packet with the M bit 615 set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and 616 no data. This serves as a fragment ACK. The EAP server MUST wait 617 until it receives the EAP-Response before sending another fragment. 618 In order to prevent errors in processing of fragments, the EAP server 619 MUST increment the Identifier field for each fragment contained 620 within an EAP-Request, and the peer MUST include this Identifier 621 value in the fragment ACK contained within the EAP-Response. 622 Retransmitted fragments will contain the same Identifier value. 624 Similarly, when the EAP server receives an EAP-Response with the M 625 bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS 626 and no data. This serves as a fragment ACK. The EAP peer MUST wait 627 until it receives the EAP-Request before sending another fragment. 628 In order to prevent errors in the processing of fragments, the EAP 629 server MUST increment the Identifier value for each fragment ACK 630 contained within an EAP-Request, and the peer MUST include this 631 Identifier value in the subsequent fragment contained within an EAP- 632 Response. 634 In the case where the EAP-TLS mutual authentication is successful, 635 and fragmentation is required, the conversation will appear as 636 follows: 638 Authenticating Peer Authenticator 639 ------------------- ------------- 640 <- EAP-Request/ 641 Identity 642 EAP-Response/ 643 Identity (MyID) -> 644 <- EAP-Request/ 645 EAP-Type=EAP-TLS 646 (TLS Start, S bit set) 647 EAP-Response/ 648 EAP-Type=EAP-TLS 649 (TLS client_hello)-> 650 <- EAP-Request/ 651 EAP-Type=EAP-TLS 652 (TLS server_hello, 653 TLS certificate, 654 [TLS server_key_exchange,] 655 TLS certificate_request, 656 TLS server_hello_done) 657 (Fragment 1: L, M bits set) 658 EAP-Response/ 659 EAP-Type=EAP-TLS -> 660 <- EAP-Request/ 661 EAP-Type=EAP-TLS 662 (Fragment 2: M bit set) 663 EAP-Response/ 664 EAP-Type=EAP-TLS -> 665 <- EAP-Request/ 666 EAP-Type=EAP-TLS 667 (Fragment 3) 668 EAP-Response/ 669 EAP-Type=EAP-TLS 670 (TLS certificate, 671 TLS client_key_exchange, 672 TLS certificate_verify, 673 TLS change_cipher_spec, 674 TLS finished)(Fragment 1: 675 L, M bits set)-> 676 <- EAP-Request/ 677 EAP-Type=EAP-TLS 678 EAP-Response/ 679 EAP-Type=EAP-TLS 680 (Fragment 2)-> 681 <- EAP-Request/ 682 EAP-Type=EAP-TLS 683 (TLS change_cipher_spec, 684 TLS finished) 685 EAP-Response/ 686 EAP-Type=EAP-TLS -> 687 <- EAP-Success 689 2.2. Identity Verification 691 As noted in [RFC3748] Section 5.1: 693 It is RECOMMENDED that the Identity Response be used primarily for 694 routing purposes and selecting which EAP method to use. EAP 695 Methods SHOULD include a method-specific mechanism for obtaining 696 the identity, so that they do not have to rely on the Identity 697 Response. 699 As part of the TLS negotiation, the server presents a certificate to 700 the peer, and if mutual authentication is requested, the peer 701 presents a certificate to the server. EAP-TLS therefore provides a 702 mechanism for determining both the peer identity (Peer-Id in 704 [KEYFRAME]) and server identity (Server-Id in [KEYFRAME]). For 705 details, see Section 5.2. 707 Since the identity presented in the EAP-Response/Identity need not be 708 related to the identity presented in the peer certificate, EAP-TLS 709 implementations SHOULD NOT require that they be identical. However, 710 if they are not identical, the identity presented in the EAP- 711 Response/Identity is unauthenticated information, and SHOULD NOT be 712 used for access control or accounting purposes. 714 2.3. Key Hierarchy 716 Figure 1 illustrates the Transient EAP Key (TEK) hierarchy for EAP- 717 TLS which is based on the TLS key hierarchy described in [RFC4346]. 718 The TLS-negotiated ciphersuite is used to set up a protected channel 719 for use in protecting the EAP conversation, keyed by the derived 720 TEKs. The TEK derivation proceeds as follows: 722 master_secret = TLS-PRF-48(pre_master_secret, "master secret", 723 client.random || server.random) 724 TEK = TLS-PRF-X(master_secret, "key expansion", 725 server.random || client.random) 727 Where: 729 TLS-PRF-X = TLS pseudo-random function defined in [RFC4346], 730 computed to X octets. 732 In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master 733 secret via a one-way function. This ensures that the TLS master 734 secret cannot be derived from the MSK, EMSK or IV unless the one-way 735 function (TLS PRF) is broken. Since the MSK and EMSK are derived 736 from the TLS master secret, if the TLS master secret is compromised 737 then the MSK and EMSK are also compromised. 739 The MSK is divided into two halves, corresponding to the "Peer to 740 Authenticator Encryption Key" (Enc-RECV-Key, 32 octets) and 741 "Authenticator to Peer Encryption Key" (Enc-SEND-Key, 32 octets). 743 The IV is a 64 octet quantity that is a known value; octets 0-31 are 744 known as the "Peer to Authenticator IV" or RECV-IV, and Octets 32-63 745 are known as the "Authenticator to Peer IV", or SEND-IV. 747 | | pre_master_secret | 748 server| | | client 749 Random| V | Random 750 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 751 | | | | 752 +---->| master_secret |<----+ 753 | | (TMS) | | 754 | | | | 755 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 756 | | | 757 V V V 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | | 760 | Key Block (TEKs) | 761 | label == "key expansion" | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | | | | | | 764 | client | server | client | server | client | server 765 | MAC | MAC | write | write | IV | IV 766 | | | | | | 767 V V V V V V 769 Figure 1 - TLS [RFC4346] Key Hierarchy 771 EAP-TLS derives exported keying material and parameters as follows: 773 Key_Material = TLS-PRF-128(TMS, "client EAP encryption", 774 client.random || server.random) 775 MSK = Key_Material(0,63) 776 EMSK = Key_Material(64,127) 777 IV = TLS-PRF-64("", "client EAP encryption", 778 client.random || server.random) 780 Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key 781 (MS-MPPE-Recv-Key in [RFC2548]). Also known as the 782 PMK in [IEEE-802.11]. 783 Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key 784 (MS-MPPE-Send-Key in [RFC2548]) 785 RECV-IV = IV(0,31) = Peer to Authenticator Initialization Vector 786 SEND-IV = IV(32,63) = Authenticator to Peer Initialization 787 Vector 788 Session-Id = 0x0D || client.random || server.random 790 Where: 792 Key_Material(W,Z) = Octets W through Z inclusive of the key material. 793 IV(W,Z) = Octets W through Z inclusive of the IV. 794 MSK(W,Z) = Octets W through Z inclusive of the MSK. 796 EMSK(W,Z) = Octets W through Z inclusive of the EMSK. 797 TMS = TLS master_secret 798 TLS-PRF-X = TLS PRF function computed to X octets 799 client.random = Nonce generated by the TLS client. 800 server.random = Nonce generated by the TLS server. 802 | | pre_master_secret | 803 server| | | client 804 Random| V | Random 805 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 806 | | | | 807 +---->| master_secret |<----+ 808 | | (TMS) | | 809 | | | | 810 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 811 | | | 812 V V V 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | | 815 | MSK, EMSK | 816 | label == "client EAP encryption" | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | | | 819 | MSK(0,31) | MSK(32,63) | EMSK(0,63) 820 | | | 821 | | | 822 V V V 824 Figure 2 - EAP-TLS Key Hierarchy 826 The use of these keys is specific to the lower layer, as described in 827 [KEYFRAME] Section 2.1. 829 2.4. Ciphersuite and Compression Negotiation 831 EAP-TLS implementations MUST support TLS v1.0. 833 EAP-TLS implementations need not necessarily support all TLS 834 ciphersuites listed in [RFC4346]. Not all TLS ciphersuites are 835 supported by available TLS tool kits and licenses may be required in 836 some cases. 838 To ensure interoperability, EAP-TLS peers and servers MUST support 839 the TLS [RFC4346] mandatory-to-implement ciphersuite: 841 TLS_RSA_WITH_3DES_EDE_CBC_SHA. 843 In addition, EAP-TLS servers SHOULD support and be able to negotiate 844 all of the following TLS ciphersuites: 846 TLS_RSA_WITH_RC4_128_MD5 847 TLS_RSA_WITH_RC4_128_SHA 848 TLS_RSA_WITH_AES_128_CBC_SHA 850 In addition, EAP-TLS peers SHOULD support the following TLS 851 ciphersuites defined in [RFC3268]: 853 TLS_RSA_WITH_AES_128_CBC_SHA 854 TLS_RSA_WITH_RC4_128_SHA 856 Since TLS supports ciphersuite negotiation, peers completing the TLS 857 negotiation will also have selected a ciphersuite, which includes 858 encryption and hashing methods. Since the ciphersuite negotiated 859 within EAP-TLS applies only to the EAP conversation, TLS ciphersuite 860 negotiation MUST NOT be used to negotiate the ciphersuites used to 861 secure data. 863 TLS also supports compression as well as ciphersuite negotiation. 864 However, during the EAP-TLS conversation the EAP peer and server MUST 865 NOT request or negotiate compression. 867 3. Detailed description of the EAP-TLS protocol 869 3.1. EAP TLS Request Packet 871 A summary of the EAP TLS Request packet format is shown below. The 872 fields are transmitted from left to right. 874 0 1 2 3 875 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Code | Identifier | Length | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Type | Flags | TLS Message Length 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | TLS Message Length | TLS Data... 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Code 886 1 888 Identifier 890 The Identifier field is one octet and aids in matching responses 891 with requests. The Identifier field MUST be changed on each 892 Request packet. 894 Length 896 The Length field is two octets and indicates the length of the EAP 897 packet including the Code, Identifier, Length, Type, and Data 898 fields. Octets outside the range of the Length field should be 899 treated as Data Link Layer padding and MUST be ignored on 900 reception. 902 Type 904 13 - EAP TLS 906 Flags 908 0 1 2 3 4 5 6 7 8 909 +-+-+-+-+-+-+-+-+ 910 |L M S R R R R R| 911 +-+-+-+-+-+-+-+-+ 913 L = Length included 914 M = More fragments 915 S = EAP-TLS start 916 R = Reserved 918 The L bit (length included) is set to indicate the presence of the 919 four octet TLS Message Length field, and MUST be set for the first 920 fragment of a fragmented TLS message or set of messages. The M 921 bit (more fragments) is set on all but the last fragment. The S 922 bit (EAP-TLS start) is set in an EAP-TLS Start message. This 923 differentiates the EAP-TLS Start message from a fragment 924 acknowledgment. Implementations of this specification MUST set 925 the reserved bits to zero, and MUST ignore them on reception. 927 TLS Message Length 929 The TLS Message Length field is four octets, and is present only 930 if the L bit is set. This field provides the total length of the 931 TLS message or set of messages that is being fragmented. 933 TLS data 935 The TLS data consists of the encapsulated TLS packet in TLS record 936 format. 938 3.2. EAP TLS Response Packet 940 A summary of the EAP TLS Response packet format is shown below. The 941 fields are transmitted from left to right. 943 0 1 2 3 944 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Code | Identifier | Length | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Type | Flags | TLS Message Length 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | TLS Message Length | TLS Data... 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Code 955 2 957 Identifier 959 The Identifier field is one octet and MUST match the Identifier 960 field from the corresponding request. 962 Length 964 The Length field is two octets and indicates the length of the EAP 965 packet including the Code, Identifier, Length, Type, and Data 966 fields. Octets outside the range of the Length field should be 967 treated as Data Link Layer padding and MUST be ignored on 968 reception. 970 Type 972 13 - EAP TLS 974 Flags 976 0 1 2 3 4 5 6 7 8 977 +-+-+-+-+-+-+-+-+ 978 |L M R R R R R R| 979 +-+-+-+-+-+-+-+-+ 981 L = Length included 982 M = More fragments 983 R = Reserved 985 The L bit (length included) is set to indicate the presence of the 986 four octet TLS Message Length field, and MUST be set for the first 987 fragment of a fragmented TLS message or set of messages. The M 988 bit (more fragments) is set on all but the last fragment. 989 Implementations of this specification MUST set the reserved bits 990 to zero, and MUST ignore them on reception. 992 TLS Message Length 994 The TLS Message Length field is four octets, and is present only 995 if the L bit is set. This field provides the total length of the 996 TLS message or set of messages that is being fragmented. 998 TLS data 1000 The TLS data consists of the encapsulated TLS packet in TLS record 1001 format. 1003 4. IANA Considerations 1005 IANA has allocated EAP Type 13 for EAP-TLS. The allocation should be 1006 updated to reference this document. There are no other IANA actions. 1008 5. Security Considerations 1010 5.1. Security Claims 1012 EAP security claims are defined in [RFC3748] Section 7.2.1. The 1013 security claims for EAP-TLS are as follows: 1015 Auth. mechanism: Certificates 1016 Ciphersuite negotiation: Yes [4] 1017 Mutual authentication: Yes [1] 1018 Integrity protection: Yes [1] 1019 Replay protection: Yes [1] 1020 Confidentiality: Yes [2] 1021 Key derivation: Yes 1022 Key strength: [3] 1023 Dictionary attack prot.: Yes 1024 Fast reconnect: Yes 1025 Crypt. binding: N/A 1026 Session independence: Yes [1] 1027 Fragmentation: Yes 1028 Channel binding: No 1030 Notes 1031 ----- 1033 [1] A formal proof of the security of EAP-TLS when used with 1035 [IEEE-802.11] is provided in [He]. This proof relies on the 1036 assumption that the private key pairs used by the EAP peer and server 1037 are not shared with other parties or applications. For example, a 1038 backend authentication server supporting EAP-TLS SHOULD NOT utilize 1039 the same certificate with https. 1041 [2] Privacy is an optional feature described in Section 2.1.4. 1043 [3] BCP 86 [RFC3766] Section 5 offers advice on the required RSA or 1044 DH module and DSA subgroup size in bits, for a given level of attack 1045 resistance in bits. For example, a 2048-bit RSA key is recommended 1046 to provide 128-bit equivalent key strength. The National Institute 1047 for Standards and Technology (NIST) also offers advice on appropriate 1048 key sizes in [SP800-57]. 1050 [4] EAP-TLS inherits the secure ciphersuite negotiation features of 1051 TLS, including key derivation function negotiation when utilized with 1052 TLS v1.2 [RFC4346bis]. 1054 5.2. Peer and Server Identities 1056 The EAP-TLS peer name (Peer-Id) represents the identity to be used 1057 for access control and accounting purposes. The Server-Id represents 1058 the identity of the EAP server. Together the Peer-Id and Server-Id 1059 name the entities involved in deriving the MSK/EMSK. 1061 In EAP-TLS, the Peer-Id and Server-Id are determined from the subject 1062 or subjectAltName fields in the peer and server certificates. For 1063 details, see [RFC3280] Section 4.1.2.6. Where the subjectAltName 1064 field is present in the peer or server certificate, the Peer-Id or 1065 Server-Id MUST be set to the contents of the subjectAltName. If 1066 subject naming information is present only in the subjectAltName 1067 extension of a peer or server certificate, then the subject field 1068 MUST be an empty sequence and the subjectAltName extension MUST be 1069 critical. 1071 Where the peer identity represents a host, a subjectAltName of type 1072 dnsName SHOULD be present in the peer certificate. Where the peer 1073 identity represents a user and not a resource, a subjectAltName of 1074 type rfc822Name SHOULD be used, conforming to the grammar for the 1075 Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. If 1076 a dnsName or rfc822Name are not available other field types (for 1077 example a subjectAltName of type ipAddress or 1078 uniformResourceIdentifier) MAY be used. 1080 A server identity will typically represent a host, not a user or a 1081 resource. As a result, a subjectAltName of type dnsName SHOULD be 1082 present in the server certificate. If a dnsName is not available 1083 other field types (for example a subjectAltName of type ipAddress or 1084 uniformResourceIdentifier) MAY be used. 1086 Conforming implementations generating new certificates with Network 1087 Access Identifiers (NAIs) MUST use the rfc822Name in the subject 1088 alternative name field to describe such identities. The use of the 1089 subject name field to contain an emailAddress Relative Distinguished 1090 Name (RDN) is deprecated, and MUST NOT be used. The subject name 1091 field MAY contain other RDNs for representing the subject's identity. 1093 Where it is non-empty, the subject name field MUST contain an X.500 1094 distinguished name (DN). If subject naming information is present 1095 only in the subject name field of a peer certificate and the peer 1096 identity represents a host or device the subject name field SHOULD 1097 contain a CommonName (CN) RDN or serialNumber RDN. If subject naming 1098 information is present only in the subject name field of a server 1099 certificate, then the subject name field SHOULD contain a CN RDN or 1100 serialNumber RDN. 1102 It is possible for more than one subjectAltName field to be present 1103 in a peer or server certificate in addition to an empty or non-empty 1104 subject distinguished name. EAP-TLS implementations supporting 1105 export of the Peer-Id and Server-Id SHOULD export all the 1106 subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also 1107 export a non-empty subject distinguished name field within the Peer- 1108 Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are 1109 considered valid. 1111 EAP-TLS implementations supporting export of the Peer-Id and Server- 1112 Id SHOULD export Peer-Ids and Server-Ids in the same order in which 1113 they appear within the certificate. Such canonical ordering would 1114 aid in comparison operations and would enable using those identifiers 1115 for key derivation if that is deemed useful. However, the ordering 1116 of fields within the certificate SHOULD NOT be used for access 1117 control. 1119 5.3. Certificate Validation 1121 Since the EAP-TLS server is typically connected to the Internet, it 1122 SHOULD support validating the peer certificate using RFC 3280 1123 [RFC3280] compliant path validation, including the ability to 1124 retrieve intermediate certificates that may be necessary to validate 1125 the peer certificate. For details, see [RFC3280] Section 4.2.2.1. 1127 Where the EAP-TLS server is unable to retrieve intermediate 1128 certificates, it either will need to be pre-configured with the 1129 necessary intermediate certificates to complete path validation or it 1130 will rely on the EAP-TLS peer to provide this information as part of 1131 the TLS Handshake (see [RFC4346] section 7.4.6). 1133 In contrast to the EAP-TLS server, the EAP-TLS peer may not have 1134 Internet connectivity. Therefore the EAP-TLS server SHOULD provide 1135 its entire certificate chain minus the root to facilitate certificate 1136 validation by the peer. The EAP-TLS peer SHOULD support validating 1137 the server certificate using RFC 3280 [RFC3280] compliant path 1138 validation. 1140 Once a TLS session is established EAP-TLS peer and server 1141 implementations MUST validate that the identities represented in the 1142 certificate are appropriate and authorized for use with EAP-TLS. The 1143 authorization process makes use of the contents of the certificates 1144 as well as other contextual information. While authorization 1145 requirements will vary from deployment to deployment it is 1146 RECOMMENDED that implementations be able to authorize based on the 1147 EAP-TLS Peer-Id and Server-Id determined as described in Section 5.2. 1149 In the case of the EAP-TLS peer this involves ensuring that the 1150 certificate presented by the EAP-TLS server was intended to be used 1151 as a server certificate. Implementations SHOULD use the Extended Key 1152 Usage (see [RFC3280] section 4.2.1.13) extension and ensure that at 1153 least one of the following is true: 1155 1) The certificate issuer included no Extended Key Usage 1156 identifiers in the certificate. 1157 2) The issuer included the anyExtendedKeyUsage identifier 1158 in the certificate (see [RFC3280] section 4.2.1.13). 1159 3) The issuer included the id-kp-serverAuth identifier 1160 in the certificate (See [RFC3280] section 4.2.1.13). 1162 When performing this comparison implementations MUST follow the 1163 validation rules specified in [RFC2818] Section 3.1. In the case of 1164 the server this involves ensuring the certificate presented by the 1165 EAP-TLS peer was intended to be used as a client certificate. 1166 Implementations SHOULD use the Extended Key Usage (see [RFC3280] 1167 Section 4.2.1.13) extension and ensure that at least one of the 1168 following is true: 1170 1) The certificate issuer included no Extended Key Usage 1171 identifiers in the certificate. 1172 2) The issuer included the anyExtendedKeyUsage identifier in 1173 the certificate (see [RFC3280] section 4.2.1.13). 1174 3) The issuer included the id-kp-clientAuth identifier in 1175 the certificate (see [RFC3280] section 4.2.1.13). 1177 5.4. Certificate Revocation 1179 Certificates are long lived assertions of identity. Therefore it is 1180 important for EAP-TLS implementations to be capable of checking 1181 whether these assertions have been revoked. 1183 EAP-TLS peer and server implementations MUST support the use of 1184 Certificate Revocation Lists (CRLs); for details, see [RFC3280] 1185 section 3.3. EAP-TLS peer and server implementations SHOULD also 1186 support the Online Certificate Status Protocol (OCSP), described in 1187 "X.509 Internet Public Key Infrastructure Online Certificate Status 1188 Protocol - OCSP" [RFC2560]. OCSP messages are typically much smaller 1189 than CRLs which can shorten connection times especially in bandwidth 1190 constrained environments. While EAP-TLS servers are typically 1191 connected to the Internet during the EAP conversation, an EAP-TLS 1192 peer may not have Internet connectivity until authentication 1193 completes. 1195 In the case where the peer is initiating a voluntary Layer 2 tunnel 1196 using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically 1197 already have a PPP interface and Internet connectivity established at 1198 the time of tunnel initiation. 1200 However, in the case where the EAP-TLS peer is attempting to obtain 1201 network access, it will not have network connectivity and is 1202 therefore not capable of checking for certificate revocation until 1203 after authentication completes and network connectivity is available. 1204 For this reason EAP-TLS peers and servers SHOULD implement 1205 Certificate Status Request messages, as described in "Transport Layer 1206 Security (TLS) Extensions" [RFC4366] section 3.6. To enable 1207 revocation checking in situations where servers do not support 1208 Certificate Status Request messages and network connectivity is not 1209 available prior to authentication completion, peer implementations 1210 MUST also support checking for certificate revocation after 1211 authentication completes and network connectivity is available, and 1212 they SHOULD utilize this capability by default. 1214 5.5. Packet Modification Attacks 1216 The integrity protection of EAP-TLS packets does not extend to the 1217 EAP header fields (Code, Identifier, Length) or the Type or Flags 1218 fields. As a result, these fields can be modified by an attacker. 1220 In most cases modification of the Code or Identifier fields will only 1221 result in a denial of service attack. However, an attacker can add 1222 additional data to an EAP-TLS packet so as to cause it to be longer 1223 than implied by the Length field. EAP peers, authenticators or 1224 servers that do not check for this could be vulnerable to a buffer 1225 overrun. 1227 It is also possible for an attacker to modify the Type or Flags 1228 fields. By modifying the Type field, an attacker could cause one 1229 TLS-based EAP method to be negotiated instead of another. For 1230 example, the EAP-TLS Type field (13) could be changed to indicate 1231 another TLS-based EAP method. Unless the alternative TLS-based EAP 1232 method utilizes a different key derivation formula, it is possible 1233 that an EAP method conversation altered by a man-in-the-middle could 1234 run all the way to completion without detection. Unless the 1235 ciphersuite selection policies are identical for all TLS-based EAP 1236 methods utilizing the same key derivation formula, it may be possible 1237 for an attacker to mount a successful downgrade attack, causing the 1238 peer to utilize an inferior ciphersuite or TLS-based EAP method. 1240 6. References 1242 6.1. Normative References 1244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1245 Requirement Levels", BCP 14, RFC 2119, March 1997. 1247 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. 1248 Adams, "X.509 Internet Public Key Infrastructure Online 1249 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1251 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1253 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) 1254 Ciphersuites for Transport Layer Security (TLS)", RFC 1255 3268, June 2002. 1257 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1258 X.509 Public Key Infrastructure Certificate and 1259 Certificate Revocation List (CRL) Profile", RFC 3280, 1260 April 2002. 1262 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1263 Levkowetz, "Extensible Authentication Protocol (EAP)", 1264 RFC 3748, June 2004. 1266 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 1267 Network Access Identifier", RFC 4282, December 2005. 1268 Dierks, T. and E. Rescorla, 1270 [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1271 1.1", RFC 4346, April 2006. 1273 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. 1274 and T. Wright, "Transport Layer Security (TLS) 1275 Extensions", RFC 4366, April 2006. 1277 6.2. Informative References 1279 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 1280 and Metropolitan Area Networks: Port-Based Network Access 1281 Control", IEEE Standard 802.1X-2004, December 2004. 1283 [IEEE-802.11] Information technology - Telecommunications and 1284 information exchange between systems - Local and 1285 metropolitan area networks - Specific Requirements Part 1286 11: Wireless LAN Medium Access Control (MAC) and 1287 Physical Layer (PHY) Specifications, IEEE Std. 1288 802.11-2007, 2007. 1290 [IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE 1291 Standard for Local and Metropolitan Area Networks: Part 1292 16: Air Interface for Fixed and Mobile Broadband Wireless 1293 Access Systems: Amendment for Physical and Medium Access 1294 Control Layers for Combined Fixed and Mobile Operations 1295 in Licensed Bands", IEEE 802.16e, August 2005. 1297 [He] He, C., Sundararajan, M., Datta, A., Derek, A. and J. 1298 Mitchell, "A Modular Correctness Proof of IEEE 802.11i 1299 and TLS", CCS '05, November 7-11, 2005, Alexandria, 1300 Virginia, USA 1302 [KEYFRAME] Aboba, B., Simon, D. and P. Eronen, "Extensible 1303 Authentication Protocol (EAP) Key Management Framework", 1304 draft-ietf-eap-keying-22.txt, Internet Draft (work in 1305 progress), November 2007. 1307 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 1308 STD 51, RFC 1661, July 1994. 1310 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1311 RFC 2548, March 1999. 1313 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 1314 W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 1315 2637, July 1999. 1317 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1318 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1319 RFC 2661, August 1999. 1321 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 1322 Protocol", RFC 2716, October 1999. 1324 [RFC3766] Orman. H. and P. Hoffman, "Determining Strengths for 1325 Public Keys Used for Exchanging Symmetric Keys", RFC 1326 3766, April 2004. 1328 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "Extensible 1329 Authentication Protocol (EAP) Method Requirements for 1330 Wireless LANs", RFC 4017, March 2005. 1332 [RFC4284] Adrangi, F., Lortz, V., Bari, F. and P. Eronen, "Identity 1333 Selection Hints for the Extensible Authentication 1334 Protocol (EAP)", RFC 4284, January 2006. 1336 [SP800-57] National Institute of Standards and Technology, 1337 "Recommendation for Key Management", Special Publication 1338 800-57, May 2006. 1340 [RFC4346bis] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1341 1.2", draft-ietf-tls-rfc4346-bis-07.txt, Internet draft 1342 (work in progress), November 2007. 1344 [UNAUTH] Schulzrinne. H., McCann, S., Bajko, G. and H. Tschofenig, 1345 "Extensions to the Emergency Services Architecture for 1346 dealing with Unauthenticated and Unauthorized Devices", 1347 Internet draft (work in progress), draft-schulzrinne- 1348 ecrit-unauthenticated-access-01.txt, November 2007. 1350 Acknowledgments 1352 Thanks to Terence Spies, Mudit Goel, Anthony Leibovitz and Narendra 1353 Gidwani of Microsoft, Glen Zorn of NetCube, Joe Salowey of Cisco and 1354 Pasi Eronen of Nokia for useful discussions of this problem space. 1356 Authors' Addresses 1358 Dan Simon 1359 Microsoft Corporation 1360 One Microsoft Way 1361 Redmond, WA 98052-6399 1363 Phone: +1 425 882 8080 1364 Fax: +1 425 936 7329 1365 EMail: dansimon@microsoft.com 1367 Bernard Aboba 1368 Microsoft Corporation 1369 One Microsoft Way 1370 Redmond, WA 98052-6399 1372 Phone: +1 425 706 6605 1373 Fax: +1 425 936 7329 1374 EMail: bernarda@microsoft.com 1376 Ryan Hurst 1377 Microsoft Corporation 1378 One Microsoft Way 1379 Redmond, WA 98052-6399 1381 Phone: +1 425 882 8080 1382 Fax: +1 425 936 7329 1383 EMail: rmh@microsoft.com 1385 Appendix A - Changes from RFC 2716 1387 This Appendix lists the major changes between [RFC2716] and this 1388 document. Minor changes, including style, grammar, spelling, and 1389 editorial changes are not mentioned here. 1391 o As EAP is now in use with a variety of lower layers, not just PPP 1392 for which it was first designed, mention of PPP is restricted to 1393 situations relating to PPP-specific behavior and reference is made to 1394 other lower layers such as IEEE 802.11, IEEE 802.16, etc. 1396 o The document now cites TLS v1.1 as a normative reference (Sections 1397 1, 6.1). 1399 o The terminology section has been updated to reflect definitions 1400 from [RFC3748] (Section 1.2), and the EAP Key Management Framework 1401 [KEYFRAME] (Section 1.2). 1403 o Use for peer unauthenticated access is clarified (Section 2.1.1). 1405 o Privacy is supported as an optional feature (Section 2.1.4). 1407 o It is no longer recommended that the identity presented in the EAP- 1408 Response/Identity be compared to the identity provided in the peer 1409 certificate (Section 2.2). 1411 o The EAP-TLS key hierarchy is defined, using terminology from 1412 [RFC3748]. This includes formulas for the computation of TEKs as 1413 well as the MSK, EMSK, IV and Session-Id (Section 2.3). 1415 o Mandatory and recommended TLS ciphersuites are provided. The use 1416 of TLS ciphersuite negotiation for determining the lower layer 1417 ciphersuite is prohibited (Section 2.4). 1419 o The Start bit is not set within an EAP-Response packet (Section 1420 3.2). 1422 o A section on security claims has been added and advice on key 1423 strength is provided (Section 5.1). 1425 o The Peer-Id and Server-Id are defined (Section 5.2) and 1426 requirements for certificate validation (Section 5.3) and revocation 1427 (Section 5.4) are provided. 1429 o Packet modification attacks are described (Section 5.5). 1431 o The examples have been updated to reflect typical messages sent in 1432 the described scenarios. For example, where mutual authentication is 1433 performed, the EAP-TLS server is shown to request a client 1434 certificate and the peer is shown to provide a certificate_verify 1435 message. A privacy example is provided, and two faulty examples of 1436 session resume failure were removed. 1438 Full Copyright Statement 1440 Copyright (C) The IETF Trust (2007). 1442 This document is subject to the rights, licenses and restrictions 1443 contained in BCP 78, and except as set forth therein, the authors 1444 retain all their rights. 1446 This document and the information contained herein are provided on an 1447 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1448 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1449 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1450 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1451 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1452 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1454 Intellectual Property 1456 The IETF takes no position regarding the validity or scope of any 1457 Intellectual Property Rights or other rights that might be claimed to 1458 pertain to the implementation or use of the technology described in 1459 this document or the extent to which any license under such rights 1460 might or might not be available; nor does it represent that it has 1461 made any independent effort to identify any such rights. Information 1462 on the procedures with respect to rights in RFC documents can be 1463 found in BCP 78 and BCP 79. 1465 Copies of IPR disclosures made to the IETF Secretariat and any 1466 assurances of licenses to be made available, or the result of an 1467 attempt made to obtain a general license or permission for the use of 1468 such proprietary rights by implementers or users of this 1469 specification can be obtained from the IETF on-line IPR repository at 1470 http://www.ietf.org/ipr. 1472 The IETF invites any interested party to bring to its attention any 1473 copyrights, patents or patent applications, or other proprietary 1474 rights that may cover technology that may be required to implement 1475 this standard. Please address the information to the IETF at 1476 ietf-ipr@ietf.org. 1478 Acknowledgment 1480 Funding for the RFC Editor function is provided by the IETF 1481 Administrative Support Activity (IASA).