idnits 2.17.00 (12 Aug 2021) /tmp/idnits52872/draft-nir-tls-eap-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2010) is 4458 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: '12' on line 345 ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (ref. 'TLS-EXT') (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. 'Diameter') (Obsoleted by RFC 6733) == Outdated reference: draft-ietf-emu-eap-gpsk has been published as RFC 5433 == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Y. Nir 3 Internet-Draft Y. Sheffer 4 Intended status: Standards Track Check Point 5 Expires: September 8, 2010 H. Tschofenig 6 NSN 7 P. Gutmann 8 University of Auckland 9 March 7, 2010 11 TLS using EAP Authentication 12 draft-nir-tls-eap-07 14 Abstract 16 This document describes an extension to the TLS protocol to allow TLS 17 clients to authenticate with legacy credentials using the Extensible 18 Authentication Protocol (EAP). 20 This work follows the example of IKEv2, where EAP has been added to 21 the protocol to allow clients to use different credentials such as 22 passwords, token cards, and shared secrets. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 8, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. EAP Applicability . . . . . . . . . . . . . . . . . . . . 5 77 1.2. Comparison with Design Alternatives . . . . . . . . . . . 5 78 1.3. Conventions Used in This Document . . . . . . . . . . . . 5 79 2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6 80 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 81 3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8 82 3.2. The InterimAuth Handshake Message . . . . . . . . . . . . 8 83 3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 9 84 3.4. Calculating the Finished message . . . . . . . . . . . . . 9 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 11 87 4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 11 88 4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 12 89 5. Performance Considerations . . . . . . . . . . . . . . . . . . 13 90 6. Operational Considerations . . . . . . . . . . . . . . . . . . 14 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 93 9. Changes from Previous Versions . . . . . . . . . . . . . . . . 17 94 9.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 17 95 9.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 17 96 9.3. Changes from the protocol model draft . . . . . . . . . . 17 97 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 100 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 103 1. Introduction 105 This document describes a new extension to [TLS]. This extension 106 allows a TLS client to authenticate using [EAP] instead of performing 107 the authentication at the application level. The extension follows 108 [TLS-EXT]. For the remainder of this document we will refer to this 109 extension as TEE (TLS with EAP Extension). 111 TEE extends the TLS handshake beyond the regular setup, to allow the 112 EAP protocol to run between the TLS server (called an "authenticator" 113 in EAP) and the TLS client (called a "supplicant"). This allows the 114 TLS architecture to handle client authentication before exposing the 115 server application software to an unauthenticated client. In doing 116 this, we follow the approach taken for IKEv2 in [RFC4306]. However, 117 similar to regular TLS, we protect the user identity by only sending 118 the client identity after the server has authenticated. In this our 119 solution differs from that of IKEv2. 121 Currently used applications that rely on non-certificate user 122 credentials use TLS to authenticate the server only. After that, the 123 application takes over, and presents a login screen where the user is 124 expected to present their credentials. 126 This creates several problems. It allows a client to access the 127 application before authentication, thus creating a potential for 128 anonymous attacks on non-hardened applications. Additionally, web 129 pages are not particularly well suited for long shared secrets and 130 for interfacing with certain devices such as USB tokens. 132 TEE allows full mutual authentication to occur for all these 133 applications within the TLS exchange. The application receives 134 control only when the user is identified and authenticated. The 135 authentication can be built into the server infrastructure by 136 connecting to an AAA server. The client side can be integrated into 137 client software such as web browsers and mail clients. An EAP 138 infrastructure is already built into some operating systems providing 139 a user interface for each authentication method within EAP. 141 We intend TEE to be used for various protocols that use TLS such as 142 HTTPS, in cases where certificate based client authentication is not 143 practical. This includes web-based mail services, online banking, 144 premium content websites and mail clients. 146 Another class of applications that may see benefit from TEE are TLS 147 based VPN clients used as part of so-called "SSL VPN" products. No 148 such client protocols have so far been standardized. 150 1.1. EAP Applicability 152 Section 1.3 of [EAP] states that EAP is only applicable for network 153 access authentication, rather than for "bulk data transfer". It then 154 goes on to explain why the transport properties of EAP indeed make it 155 unsuitable for bulk data transfer, e.g. for large file transport. 156 Our proposed use of EAP falls squarely within the applicability as 157 defined, since we make no further use of EAP beyond access 158 authentication. 160 1.2. Comparison with Design Alternatives 162 It has been suggested to implement EAP authentication as part of the 163 protected application, rather than as part of the TLS handshake. A 164 BCP document could be used to describe a secure way of doing this. 165 The drawbacks we see in such an approach are listed below: 166 o EAP does not have a pre-defined transport method. Application 167 designers would need to specify an EAP transport for each 168 application. Making this a part of TLS has the benefit of a 169 single specification for all protected applications. 170 o The integration of EAP and TLS is security-sensitive and should be 171 standardized and interoperable. We do not believe that it should 172 be left to application designers to do this in a secure manner. 173 Specifically on the server-side, integration with AAA servers adds 174 complexity and is more naturally part of the underlying 175 infrastrcture. 176 o Our current proposal provides channel binding between TLS and EAP, 177 to counter the MITM attacks described in [MITM]. TLS does not 178 provide any standard way of extracting cryptographic material from 179 the TLS state, and in most implementations, the TLS state is not 180 exposed to the protected application. Because of this, it is 181 difficult for application designers to bind the user 182 authentication to the protected channel provided by TLS. 184 1.3. Conventions Used in This Document 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 2. Operating Environment 192 TEE will work between a client application and a server application, 193 performing either client authentication or mutual authentication 194 within the TLS exchange. 196 Client Server 197 +-------------------------+ +------------------------+ 198 | |GUI| | Client | |TLS+-+-----+-+TLS| |Server | | 199 | +-^-+ |Software| +-^-+ | +-+-^-+ |Application | | 200 | | +--------+ | | | | |Software | | 201 | | | | | | +------------+ | 202 | +-v----------------v-+ | | | | 203 | | EAP | | +---|--------------------+ 204 | | Infrastructure | | | 205 | +--------------------+ | | +--------+ 206 +-------------------------+ | | AAA | 207 | | Server | 208 +----- | 209 +--------+ 211 The above diagram shows the typical deployment. The client has 212 software that either includes a UI for some EAP methods, or else is 213 able to invoke some operating system EAP infrastructure that takes 214 care of the user interaction. The server is configured with the 215 address and protocol of the AAA server. Typically the AAA server 216 communicates using the RADIUS protocol with EAP ([RADIUS] and 217 [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]). 219 As stated in the introduction, we expect TEE to be used in both 220 browsers and applications. Further uses may be authentication and 221 key generation for other protocols, and tunneling clients, which so 222 far have not been standardized. 224 3. Protocol Overview 226 When TLS is used with EAP, additional records are sent after the 227 ChangeCipherSpec protocol message and before the Finished message, 228 effectively creating an extended handshake before the application 229 layer data can be sent. Each EapMsg handshake record contains 230 exactly one EAP message. Using EAP for client authentication allows 231 TLS to be used with various AAA back-end servers such as RADIUS or 232 Diameter. 234 TLS with EAP may be used for securing a data connection such as HTTP 235 or POP3. We believe it has three main benefits: 236 o The ability of EAP to work with backend servers can remove that 237 burden from the application layer. 238 o Moving the user authentication into the TLS handshake protects the 239 presumably less secure application layer from attacks by 240 unauthenticated parties. 241 o Using mutual authentication methods within EAP can help thwart 242 certain classes of phishing attacks. 244 The TEE extension defines the following: 245 o A new extension type called tee_supported, used to indicate that 246 the communicating application (either client or server) supports 247 this extension. 248 o A new message type for the handshake protocol, called InterimAuth, 249 which is used to sign previous messages. 250 o A new message type for the handshake protocol, called EapMsg, 251 which is used to carry a single EAP message. 253 The diagram below outlines the protocol structure. For illustration 254 purposes only, we use the GPSK EAP method [EAP-GPSK]. 256 Client Server 257 ------ ------ 259 ClientHello(*) --------> 260 ServerHello(*) 261 (Certificate) 262 ServerKeyExchange 263 EapMsg(Identity-Request) 264 <-------- ServerHelloDone 265 ClientKeyExchange 266 (CertificateVerify) 267 ChangeCipherSpec 268 InterimAuth 269 EapMsg(Identity-Reply) --------> 270 ChangeCipherSpec 271 InterimAuth 272 EapMsg(GPSK-Request) 273 <-------- 274 EapMsg(GPSK-Reply) --------> 275 EapMsg(GPSK-Request) 276 <-------- 277 EapMsg(GPSK-Reply) --------> 278 EapMsg(Success) 279 <-------- Finished 280 Finished --------> 282 (*) The ClientHello and ServerHello include the tee_supported 283 extension to indicate support for TEE 285 The client indicates in the first message its support for TEE. The 286 server sends an EAP identity request in the reply. The client sends 287 the identity reply after the handshake completion. The EAP request- 288 response sequence continues until the client is either authenticated 289 or rejected. 291 3.1. The tee_supported Extension 293 The tee_supported extension is a ClientHello and ServerHello 294 extension as defined in section 2.3 of [TLS-EXT]. The extension_type 295 field is TBA by IANA. The extension_data is zero-length. 297 3.2. The InterimAuth Handshake Message 299 The InterimAuth message is identical in syntax to the Finished 300 message described in section 7.4.9 of [TLS]. It is calculated in 301 exactly the same way. 303 The semantics, however, are somewhat different. The "Finished" 304 message indicates that application data may now be sent. The 305 "InterimAuth" message does not indicate this. Instead, further 306 handshake messages are needed. 308 The HandshakeType value for the InterimAuth handshake message is TBA 309 by IANA. 311 3.3. The EapMsg Handshake Message 313 The EapMsg handshake message carries exactly one EAP message as 314 defined in [EAP]. 316 The HandshakeType value for the EapMsg handshake message is TBA by 317 IANA. 319 The EapMsg message is used to tunnel EAP messages between the 320 authentication server, which may be co-located with the TLS server, 321 or else may be a separate AAA server, and the supplicant, which is 322 co-located with the TLS client. TLS on either side receives the EAP 323 data from the EAP infrastructure, and treats it as opaque. TLS does 324 not make any changes to the EAP payload or make any decisions based 325 on the contents of an EapMsg handshake message. 327 Note that it is expected that the authentication server notifies the 328 TLS server about authentication success or failure, and so TLS need 329 not inspect the eap_payload within the EapMsg to detect success or 330 failure. 332 struct { 333 opaque eap_payload[4..65535]; 334 } EapMsg; 336 eap_payload is defined in section 4 of RFC 3748. It includes the 337 Code, Identifier, Length and Data fields of the EAP packet. 339 3.4. Calculating the Finished message 341 If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the 342 Finished message is calculated as follows: 344 struct { 345 opaque verify_data[12]; 346 } Finished; 348 verify_data 349 PRF(MSK, finished_label, MD5(handshake_messages) + 350 SHA-1(handshake_messages)) [0..11]; 352 The finished_label and the PRF are as defined in section 7.4.9 of 353 [TLS]. 355 The handshake_messages field, unlike regular TLS, does not sign all 356 the data in the handshake. Instead it signs all the data that has 357 not been signed by the previous InterimAuth message. The 358 handshake_messages field includes all of the octets beginning with 359 and including the InterimAuth message, up to but not including this 360 Finished message. This is the concatenation of all the Handshake 361 structures exchanged thus far, and not yet signed, as defined in 362 section 7.4 of [TLS]and in this document. 364 The Master Session Key (MSK) is derived by the AAA server and by the 365 client if the EAP method is key-generating. On the server-side, it 366 is typically received from the AAA server over the RADIUS or Diameter 367 protocol. On the client-side, it is passed to TLS by some other 368 method. 370 If the EAP method is not key-generating, then the master_secret is 371 used to sign the messages instead of the MSK. For a discussion on 372 the use of such methods, see Section 4.1. 374 4. Security Considerations 376 4.1. InterimAuth vs. Finished 378 In regular TLS, the Finished message provides two functions: it signs 379 all preceding messages, and it signals that application data can now 380 be sent. In TEE, it only signs those messages that have not yet been 381 signed. 383 Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate 384 keys in addition to authenticating clients. Such methods are said to 385 be resistant to man-in-the-middle (MITM) attacks as discussed in 386 [MITM]. Such methods are called key-generating methods. 388 To realize the benefit of such methods, we need to verify the key 389 that was generated within the EAP method. This is referred to as the 390 MSK in EAP. In TEE, the InterimAuth message signs all previous 391 messages with the master_secret, just like the Finished message in 392 regular TLS. The Finished message signs the rest of the messages 393 using the MSK if such exists. If not, then the messages are signed 394 with the master_secret as in regular TLS. 396 The need for signing twice arises from the fact that we need to use 397 both the master_secret and the MSK. It was possible to use just one 398 Finished record and blend the MSK into the master_secret. However, 399 this would needlessly complicate the protocol and make security 400 analysis more difficult. Instead, we have decided to follow the 401 example of IKEv2, where two AUTH payloads are exchanged. 403 It should be noted that using non-key-generating methods may expose 404 the client to a MITM attack if the same method and credentials are 405 used in some other situation, in which the EAP is done outside of a 406 protected tunnel with an authenticated server. Unless it can be 407 determined that the EAP method is never used in such a situation, 408 non-key-generating methods SHOULD NOT be used. This issue is 409 discussed extensively in [Compound-Authentication]. 411 4.2. Identity Protection 413 Unlike [TLS-PSK], TEE provides identity protection for the client. 414 The client's identity is hidden from a passive eavesdropper using TLS 415 encryption. Active attacks are discussed in Section 4.3. 417 We could save one round-trip by having the client send its identity 418 within the Client Hello message. This is similar to TLS-PSK. 419 However, we believe that identity protection is a worthy enough goal, 420 so as to justify the extra round-trip. 422 4.3. Mutual Authentication 424 In order to achieve our security goals, we need to have both the 425 server and the client authenticate. Client authentication is 426 obviously done using the EAP method. The server authentication can 427 be done in either of two ways: 428 1. The client can verify the server certificate. This may work well 429 depending on the scenario, but implies that the client or its 430 user can recognize the right DN or alternate name, and 431 distinguish it from plausible alternatives. The introduction to 432 [I.D.Webauth-phishing] shows that at least in HTTPS, this is not 433 always the case. 434 2. The client can use a mutually authenticated (MA) EAP method such 435 as GPSK. In this case, server certificate verification does not 436 matter, and the TLS handshake may as well be anonymous. Note 437 that in this case, the client identity is sent to the server 438 before server authentication. 440 To summarize: 441 o Clients MUST NOT propose anonymous ciphersuites, unless they 442 support MA EAP methods. 443 o Clients MUST NOT accept non-MA methods if the ciphersuite is 444 anonymous. 445 o Clients MUST NOT accept non-MA methods if they are not able to 446 verify the server credentials. Note that this document does not 447 define what verification involves. If the server DN is known and 448 stored on the client, verifying certificate signature and checking 449 revocation may be enough. For web browsers, the case is not as 450 clear cut, and MA methods SHOULD be used. 452 5. Performance Considerations 454 Regular TLS adds two round-trips to a TCP connection. However, 455 because of the stream nature of TCP, the client does not really need 456 to wait for the server's Finished message, and can begin sending 457 application data immediately after its own Finished message. In 458 practice, many clients do so, and TLS only adds one round-trip of 459 delay. 461 TEE adds as many round-trips as the EAP method requires. For 462 example, EAP-MD5 requires 1 round-trip, while EAP-GPSK requires 2 463 round-trips. Additionally, the client MUST wait for the EAP-Success 464 message before sending its own Finished message, so we need at least 465 3 round-trips for the entire handshake. The best a client can do is 466 two round-trips plus however many round-trips the EAP method 467 requires. 469 It should be noted, though, that these extra round-trips save 470 processing time at the application level. Two extra round-trips take 471 a lot less time than presenting a log-in web page and processing the 472 user's input. 474 It should also be noted, that TEE reverses the order of the Finished 475 messages. In regular TLS the client sends the Finished message 476 first. In TEE it is the server that sends the Finished message 477 first. This should not affect performance, and it is clear that the 478 client may send application data immediately after the Finished 479 message. 481 6. Operational Considerations 483 Section 4.3 defines a dependency between the TLS state and the EAP 484 state in that it mandates that certain EAP methods should not be used 485 with certain TLS ciphersuites. To avoid such dependencies, there are 486 two approaches that implementations can take. They can either not 487 use any anonymous ciphersuites, or else they can use only MA EAP 488 methods. 490 Where certificate validation is problematic, such as in browser-based 491 HTTPS, we recommend the latter approach. 493 In cases where the use of EAP within TLS is not known before opening 494 the connection, it is necessary to consider the implications of 495 requiring the user to type in credentials after the connection has 496 already started. TCP sessions may time out, because of security 497 considerations, and this may lead to session setup failure. 499 7. IANA Considerations 501 IANA is asked to assign an extension type value from the 502 "ExtensionType Values" registry for the tee_supported extension. 504 IANA is asked to assign two handshake message types from the "TLS 505 HandshakeType Registry", one for "EapMsg" and one for "InterimAuth". 507 8. Acknowledgments 509 The authors would like to thank Josh Howlett for his comments. 511 The TLS Inner Application Extension work ([TLS/IA]) has inspired the 512 authors to create this simplified work. TLS/IA provides a somewhat 513 different approach to integrating non-certificate credentials into 514 the TLS protocol, in addition to several other features available 515 from the RADIUS namespace. 517 The authors would also like to thank the various contributors to 518 [RFC4306] whose work inspired this one. 520 9. Changes from Previous Versions 522 9.1. Changes in version -02 524 o Added discussion of alternative designs. 526 9.2. Changes in version -01 528 o Changed the construction of the Finished message 529 o Replaced MS-CHAPv2 with GPSK in examples. 530 o Added open issues section. 531 o Added reference to [Compound-Authentication] 532 o Fixed reference to MITM attack 534 9.3. Changes from the protocol model draft 536 o Added diagram for EapMsg 537 o Added discussion of EAP applicability 538 o Added discussion of mutually-authenticated EAP methods vs other 539 methods in the security considerations. 540 o Added operational considerations. 541 o Other minor nits. 543 10. Open Issues 545 Some have suggested that since the protocol is identical to regular 546 TLS up to the InterimAuth message, we should call that the Finished 547 message, and call the last message in the extended handshake 548 something like "EapFinished". This has the advantage that the 549 construction of Finished is already well defined and will not change. 550 However, the Finished message has a specific meaning as indicated by 551 its name. It means that the handshake is over and that application 552 data can now be sent. This is not true of what is in this draft 553 called InterimAuth. We'd like the opinions of reviewrs about this 554 issue. 556 The MSK from the EAP exchange is only used to sign the Finished 557 message. It is not used again in the data encryption. In this we 558 followed the example of IKEv2. The reason is that TLS already has 559 perfectly good ways of exchanging keys, and we do not need this 560 capability from EAP methods. Also, using the MSK in keys would 561 require an additional ChangeCipherSpec and would complicate the 562 protocol. We'd like the opinions of reviewrs about this issue. 564 Another response we got was that we should have a MUST requirement 565 that only mutually authenticated and key-generating methods be used 566 in TEE. This would simplify the security considerations section. 567 While we agree that this is a good idea, most EAP methods in common 568 use are not compliant. Additionally, such requirements assume that 569 EAP packets are visible to a passive attacker. As EAP is used in 570 protected tunnels such as in L2TP, in IKEv2 and here, this assumption 571 may not be required. If we consider the server authenticated by its 572 certificate, it may be acceptable to use a non-MA method. 574 It has been suggested that identity protection is not important 575 enough to add a roundtrip, and so we should have the client send the 576 username in the ClientHello. We are not sure about how others feel 577 about this, and would like to solicit the reviewers opinion. Note 578 that if this is done, the client sends the user name before ever 579 receiving any indication that the server actually supports TEE. This 580 might be acceptable in an email client, where the server is 581 preconfigured, but it may be unacceptable in other uses, such as web 582 browsers. 584 11. References 586 11.1. Normative References 588 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 589 Levkowetz, "Extensible Authentication Protocol (EAP)", 590 RFC 3748, June 2004. 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, March 1997. 595 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 596 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 598 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 599 and T. Wright, "Transport Layer Security (TLS) 600 Extensions", RFC 4366, April 2006. 602 11.2. Informative References 604 [Compound-Authentication] 605 Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon, 606 "The Compound Authentication Binding Problem", 607 draft-puthenkulam-eap-binding-04 (work in progress), 608 October 2003. 610 [Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 611 Authentication Protocol (EAP) Application", RFC 4072, 612 August 2005. 614 [Diameter] 615 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 616 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 618 [EAP-GPSK] 619 Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared 620 Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in 621 progress), April 2007. 623 [I-D.ietf-eap-keying] 624 Aboba, B., "Extensible Authentication Protocol (EAP) Key 625 Management Framework", draft-ietf-eap-keying-18 (work in 626 progress), February 2007. 628 [I.D.Webauth-phishing] 629 Hartman, S., "Requirements for Web Authentication 630 Resistant to Phishing", draft-hartman-webauth-phishing-03 631 (work in progress), March 2007. 633 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 634 in Tunneled Authentication Protocols", IACR ePrint 635 Archive , October 2002. 637 [RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 638 Dial In User Service) Support For Extensible 639 Authentication Protocol (EAP)", RFC 3579, September 2003. 641 [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 642 "Remote Authentication Dial In User Service (RADIUS)", 643 RFC 2865, June 2000. 645 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 646 RFC 4306, December 2005. 648 [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 649 for Transport Layer Security (TLS)", RFC 4279, 650 December 2005. 652 [TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and 653 T. Hardjono, "TLS Inner Application Extension (TLS/IA)", 654 draft-funk-tls-inner-application-extension-03 (work in 655 progress), June 2006. 657 Authors' Addresses 659 Yoav Nir 660 Check Point Software Technologies Ltd. 661 5 Hasolelim st. 662 Tel Aviv 67897 663 Israel 665 Email: ynir@checkpoint.com 667 Yaron Sheffer 668 Check Point Software Technologies Ltd. 669 5 Hasolelim st. 670 Tel Aviv 67897 671 Israel 673 Email: yaronf@checkpoint.com 675 Hannes Tschofenig 676 Nokia Siemens Networks 677 Linnoitustie 6 678 Espoo 02600 679 Finland 681 Phone: +358 (50) 4871445 682 Email: Hannes.Tschofenig@gmx.net 683 URI: http://www.tschofenig.priv.at 685 Peter Gutmann 686 University of Auckland 687 Department of Computer Science 688 New Zealand 690 Email: pgut001@cs.auckland.ac.nz