idnits 2.17.00 (12 Aug 2021) /tmp/idnits48551/draft-nir-tls-eap-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 711. 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 (April 4, 2008) is 5160 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 327 ** 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 (==), 10 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: October 6, 2008 H. Tschofenig 6 NSN 7 P. Gutmann 8 University of Auckland 9 April 4, 2008 11 TLS using EAP Authentication 12 draft-nir-tls-eap-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 6, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes an extension to the TLS protocol to allow TLS 46 clients to authenticate with legacy credentials using the Extensible 47 Authentication Protocol (EAP). 49 This work follows the example of IKEv2, where EAP has been added to 50 the IKEv2 protocol to allow clients to use different credentials such 51 as passwords, token cards, and shared secrets. 53 When TLS is used with EAP, additional records are sent after the 54 ChangeCipherSpec protocol message and before the Finished message, 55 effectively creating an extended handshake before the application 56 layer data can be sent. Each EapMsg handshake record contains 57 exactly one EAP message. Using EAP for client authentication allows 58 TLS to be used with various AAA back-end servers such as RADIUS or 59 Diameter. 61 TLS with EAP may be used for securing a data connection such as HTTP 62 or POP3. We believe it has three main benefits: 63 o The ability of EAP to work with backend servers can remove that 64 burden from the application layer. 65 o Moving the user authentication into the TLS handshake protects the 66 presumably less secure application layer from attacks by 67 unauthenticated parties. 68 o Using mutual authentication methods within EAP can help thwart 69 certain classes of phishing attacks. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. EAP Applicability . . . . . . . . . . . . . . . . . . . . 5 75 1.2. Comparison with Design Alternatives . . . . . . . . . . . 5 76 1.3. Conventions Used in This Document . . . . . . . . . . . . 5 77 2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6 78 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 79 3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8 80 3.2. The InterimAuth Handshake Message . . . . . . . . . . . . 8 81 3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 8 82 3.4. Calculating the Finished message . . . . . . . . . . . . . 9 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10 85 4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10 86 4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 11 87 5. Performance Considerations . . . . . . . . . . . . . . . . . . 12 88 6. Operational Considerations . . . . . . . . . . . . . . . . . . 13 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 91 9. Changes from Previous Versions . . . . . . . . . . . . . . . . 16 92 9.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 16 93 9.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 16 94 9.3. Changes from the protocol model draft . . . . . . . . . . 16 95 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 98 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 100 Intellectual Property and Copyright Statements . . . . . . . . . . 21 102 1. Introduction 104 This document describes a new extension to [TLS]. This extension 105 allows a TLS client to authenticate using [EAP] instead of performing 106 the authentication at the application level. The extension follows 107 [TLS-EXT]. For the remainder of this document we will refer to this 108 extension as TEE (TLS with EAP Extension). 110 TEE extends the TLS handshake beyond the regular setup, to allow the 111 EAP protocol to run between the TLS server (called an "authenticator" 112 in EAP) and the TLS client (called a "supplicant"). This allows the 113 TLS architecture to handle client authentication before exposing the 114 server application software to an unauthenticated client. In doing 115 this, we follow the approach taken for IKEv2 in [RFC4306]. However, 116 similar to regular TLS, we protect the user identity by only sending 117 the client identity after the server has authenticated. In this our 118 solution differs from that of IKEv2. 120 Currently used applications that rely on non-certificate user 121 credentials use TLS to authenticate the server only. After that, the 122 application takes over, and presents a login screen where the user is 123 expected to present their credentials. 125 This creates several problems. It allows a client to access the 126 application before authentication, thus creating a potential for 127 anonymous attacks on non-hardened applications. Additionally, web 128 pages are not particularly well suited for long shared secrets and 129 for interfacing with certain devices such as USB tokens. 131 TEE allows full mutual authentication to occur for all these 132 applications within the TLS exchange. The application receives 133 control only when the user is identified and authenticated. The 134 authentication can be built into the server infrastructure by 135 connecting to an AAA server. The client side can be integrated into 136 client software such as web browsers and mail clients. An EAP 137 infrastructure is already built into some operating systems providing 138 a user interface for each authentication method within EAP. 140 We intend TEE to be used for various protocols that use TLS such as 141 HTTPS, in cases where certificate based client authentication is not 142 practical. This includes web-based mail services, online banking, 143 premium content websites and mail clients. 145 Another class of applications that may see benefit from TEE are TLS 146 based VPN clients used as part of so-called "SSL VPN" products. No 147 such client protocols have so far been standardized. 149 1.1. EAP Applicability 151 Section 1.3 of [EAP] states that EAP is only applicable for network 152 access authentication, rather than for "bulk data transfer". It then 153 goes on to explain why the transport properties of EAP indeed make it 154 unsuitable for bulk data transfer, e.g. for large file transport. 155 Our proposed use of EAP falls squarely within the applicability as 156 defined, since we make no further use of EAP beyond access 157 authentication. 159 1.2. Comparison with Design Alternatives 161 It has been suggested to implement EAP authentication as part of the 162 protected application, rather than as part of the TLS handshake. A 163 BCP document could be used to describe a secure way of doing this. 164 The drawbacks we see in such an approach are listed below: 165 o EAP does not have a pre-defined transport method. Application 166 designers would need to specify an EAP transport for each 167 application. Making this a part of TLS has the benefit of a 168 single specification for all protected applications. 169 o The integration of EAP and TLS is security-sensitive and should be 170 standardized and interoperable. We do not believe that it should 171 be left to application designers to do this in a secure manner. 172 Specifically on the server-side, integration with AAA servers adds 173 complexity and is more naturally part of the underlying 174 infrastrcture. 175 o Our current proposal provides channel binding between TLS and EAP, 176 to counter the MITM attacks described in [MITM]. TLS does not 177 provide any standard way of extracting cryptographic material from 178 the TLS state, and in most implementations, the TLS state is not 179 exposed to the protected application. Because of this, it is 180 difficult for application designers to bind the user 181 authentication to the protected channel provided by TLS. 183 1.3. Conventions Used in This Document 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 2. Operating Environment 191 TEE will work between a client application and a server application, 192 performing either client authentication or mutual authentication 193 within the TLS exchange. 195 Client Server 196 +-------------------------+ +------------------------+ 197 | |GUI| | Client | |TLS+-+-----+-+TLS| |Server | | 198 | +-^-+ |Software| +-^-+ | +-+-^-+ |Application | | 199 | | +--------+ | | | | |Software | | 200 | | | | | | +------------+ | 201 | +-v----------------v-+ | | | | 202 | | EAP | | +---|--------------------+ 203 | | Infrastructure | | | 204 | +--------------------+ | | +--------+ 205 +-------------------------+ | | AAA | 206 | | Server | 207 +----- | 208 +--------+ 210 The above diagram shows the typical deployment. The client has 211 software that either includes a UI for some EAP methods, or else is 212 able to invoke some operating system EAP infrastructure that takes 213 care of the user interaction. The server is configured with the 214 address and protocol of the AAA server. Typically the AAA server 215 communicates using the RADIUS protocol with EAP ([RADIUS] and 216 [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]). 218 As stated in the introduction, we expect TEE to be used in both 219 browsers and applications. Further uses may be authentication and 220 key generation for other protocols, and tunneling clients, which so 221 far have not been standardized. 223 3. Protocol Overview 225 The TEE extension defines the following: 226 o A new extension type called tee_supported, used to indicate that 227 the communicating application (either client or server) supports 228 this extension. 229 o A new message type for the handshake protocol, called InterimAuth, 230 which is used to sign previous messages. 231 o A new message type for the handshake protocol, called EapMsg, 232 which is used to carry a single EAP message. 234 The diagram below outlines the protocol structure. For illustration 235 purposes only, we use the GPSK EAP method [EAP-GPSK]. 237 Client Server 238 ------ ------ 240 ClientHello(*) --------> 241 ServerHello(*) 242 (Certificate) 243 ServerKeyExchange 244 EapMsg(Identity-Request) 245 <-------- ServerHelloDone 246 ClientKeyExchange 247 (CertificateVerify) 248 ChangeCipherSpec 249 InterimAuth 250 EapMsg(Identity-Reply) --------> 251 ChangeCipherSpec 252 InterimAuth 253 EapMsg(GPSK-Request) 254 <-------- 255 EapMsg(GPSK-Reply) --------> 256 EapMsg(GPSK-Request) 257 <-------- 258 EapMsg(GPSK-Reply) --------> 259 EapMsg(Success) 260 <-------- Finished 261 Finished --------> 263 (*) The ClientHello and ServerHello include the tee_supported 264 extension to indicate support for TEE 266 The client indicates in the first message its support for TEE. The 267 server sends an EAP identity request in the reply. The client sends 268 the identity reply after the handshake completion. The EAP request- 269 response sequence continues until the client is either authenticated 270 or rejected. 272 3.1. The tee_supported Extension 274 The tee_supported extension is a ClientHello and ServerHello 275 extension as defined in section 2.3 of [TLS-EXT]. The extension_type 276 field is TBA by IANA. The extension_data is zero-length. 278 3.2. The InterimAuth Handshake Message 280 The InterimAuth message is identical in syntax to the Finished 281 message described in section 7.4.9 of [TLS]. It is calculated in 282 exactly the same way. 284 The semantics, however, are somewhat different. The "Finished" 285 message indicates that application data may now be sent. The 286 "InterimAuth" message does not indicate this. Instead, further 287 handshake messages are needed. 289 The HandshakeType value for the InterimAuth handshake message is TBA 290 by IANA. 292 3.3. The EapMsg Handshake Message 294 The EapMsg handshake message carries exactly one EAP message as 295 defined in [EAP]. 297 The HandshakeType value for the EapMsg handshake message is TBA by 298 IANA. 300 The EapMsg message is used to tunnel EAP messages between the 301 authentication server, which may be co-located with the TLS server, 302 or else may be a separate AAA server, and the supplicant, which is 303 co-located with the TLS client. TLS on either side receives the EAP 304 data from the EAP infrastructure, and treats it as opaque. TLS does 305 not make any changes to the EAP payload or make any decisions based 306 on the contents of an EapMsg handshake message. 308 Note that it is expected that the authentication server notifies the 309 TLS server about authentication success or failure, and so TLS need 310 not inspect the eap_payload within the EapMsg to detect success or 311 failure. 313 struct { 314 opaque eap_payload[4..65535]; 315 } EapMsg; 317 eap_payload is defined in section 4 of RFC 3748. It includes 318 the Code, Identifier, Length and Data fields of the EAP 319 packet. 321 3.4. Calculating the Finished message 323 If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the 324 Finished message is calculated as follows: 326 struct { 327 opaque verify_data[12]; 328 } Finished; 330 verify_data 331 PRF(MSK, finished_label, MD5(handshake_messages) + 332 SHA-1(handshake_messages)) [0..11]; 334 The finished_label and the PRF are as defined in section 7.4.9 of 335 [TLS]. 337 The handshake_messages field, unlike regular TLS, does not sign all 338 the data in the handshake. Instead it signs all the data that has 339 not been signed by the previous InterimAuth message. The 340 handshake_messages field includes all of the octets beginning with 341 and including the InterimAuth message, up to but not including this 342 Finished message. This is the concatenation of all the Handshake 343 structures exchanged thus far, and not yet signed, as defined in 344 section 7.4 of [TLS]and in this document. 346 The Master Session Key (MSK) is derived by the AAA server and by the 347 client if the EAP method is key-generating. On the server-side, it 348 is typically received from the AAA server over the RADIUS or Diameter 349 protocol. On the client-side, it is passed to TLS by some other 350 method. 352 If the EAP method is not key-generating, then the master_secret is 353 used to sign the messages instead of the MSK. For a discussion on 354 the use of such methods, see Section 4.1. 356 4. Security Considerations 358 4.1. InterimAuth vs. Finished 360 In regular TLS, the Finished message provides two functions: it signs 361 all preceding messages, and it signals that application data can now 362 be sent. In TEE, it only signs those messages that have not yet been 363 signed. 365 Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate 366 keys in addition to authenticating clients. Such methods are said to 367 be resistant to man-in-the-middle (MITM) attacks as discussed in 368 [MITM]. Such methods are called key-generating methods. 370 To realize the benefit of such methods, we need to verify the key 371 that was generated within the EAP method. This is referred to as the 372 MSK in EAP. In TEE, the InterimAuth message signs all previous 373 messages with the master_secret, just like the Finished message in 374 regular TLS. The Finished message signs the rest of the messages 375 using the MSK if such exists. If not, then the messages are signed 376 with the master_secret as in regular TLS. 378 The need for signing twice arises from the fact that we need to use 379 both the master_secret and the MSK. It was possible to use just one 380 Finished record and blend the MSK into the master_secret. However, 381 this would needlessly complicate the protocol and make security 382 analysis more difficult. Instead, we have decided to follow the 383 example of IKEv2, where two AUTH payloads are exchanged. 385 It should be noted that using non-key-generating methods may expose 386 the client to a MITM attack if the same method and credentials are 387 used in some other situation, in which the EAP is done outside of a 388 protected tunnel with an authenticated server. Unless it can be 389 determined that the EAP method is never used in such a situation, 390 non-key-generating methods SHOULD NOT be used. This issue is 391 discussed extensively in [Compound-Authentication]. 393 4.2. Identity Protection 395 Unlike [TLS-PSK], TEE provides identity protection for the client. 396 The client's identity is hidden from a passive eavesdropper using TLS 397 encryption. Active attacks are discussed in Section 4.3. 399 We could save one round-trip by having the client send its identity 400 within the Client Hello message. This is similar to TLS-PSK. 401 However, we believe that identity protection is a worthy enough goal, 402 so as to justify the extra round-trip. 404 4.3. Mutual Authentication 406 In order to achieve our security goals, we need to have both the 407 server and the client authenticate. Client authentication is 408 obviously done using the EAP method. The server authentication can 409 be done in either of two ways: 410 1. The client can verify the server certificate. This may work well 411 depending on the scenario, but implies that the client or its 412 user can recognize the right DN or alternate name, and 413 distinguish it from plausible alternatives. The introduction to 414 [I.D.Webauth-phishing] shows that at least in HTTPS, this is not 415 always the case. 416 2. The client can use a mutually authenticated (MA) EAP method such 417 as GPSK. In this case, server certificate verification does not 418 matter, and the TLS handshake may as well be anonymous. Note 419 that in this case, the client identity is sent to the server 420 before server authentication. 422 To summarize: 423 o Clients MUST NOT propose anonymous ciphersuites, unless they 424 support MA EAP methods. 425 o Clients MUST NOT accept non-MA methods if the ciphersuite is 426 anonymous. 427 o Clients MUST NOT accept non-MA methods if they are not able to 428 verify the server credentials. Note that this document does not 429 define what verification involves. If the server DN is known and 430 stored on the client, verifying certificate signature and checking 431 revocation may be enough. For web browsers, the case is not as 432 clear cut, and MA methods SHOULD be used. 434 5. Performance Considerations 436 Regular TLS adds two round-trips to a TCP connection. However, 437 because of the stream nature of TCP, the client does not really need 438 to wait for the server's Finished message, and can begin sending 439 application data immediately after its own Finished message. In 440 practice, many clients do so, and TLS only adds one round-trip of 441 delay. 443 TEE adds as many round-trips as the EAP method requires. For 444 example, EAP-MD5 requires 1 round-trip, while EAP-GPSK requires 2 445 round-trips. Additionally, the client MUST wait for the EAP-Success 446 message before sending its own Finished message, so we need at least 447 3 round-trips for the entire handshake. The best a client can do is 448 two round-trips plus however many round-trips the EAP method 449 requires. 451 It should be noted, though, that these extra round-trips save 452 processing time at the application level. Two extra round-trips take 453 a lot less time than presenting a log-in web page and processing the 454 user's input. 456 It should also be noted, that TEE reverses the order of the Finished 457 messages. In regular TLS the client sends the Finished message 458 first. In TEE it is the server that sends the Finished message 459 first. This should not affect performance, and it is clear that the 460 client may send application data immediately after the Finished 461 message. 463 6. Operational Considerations 465 Section 4.3 defines a dependency between the TLS state and the EAP 466 state in that it mandates that certain EAP methods should not be used 467 with certain TLS ciphersuites. To avoid such dependencies, there are 468 two approaches that implementations can take. They can either not 469 use any anonymous ciphersuites, or else they can use only MA EAP 470 methods. 472 Where certificate validation is problematic, such as in browser-based 473 HTTPS, we recommend the latter approach. 475 In cases where the use of EAP within TLS is not known before opening 476 the connection, it is necessary to consider the implications of 477 requiring the user to type in credentials after the connection has 478 already started. TCP sessions may time out, because of security 479 considerations, and this may lead to session setup failure. 481 7. IANA Considerations 483 IANA is asked to assign an extension type value from the 484 "ExtensionType Values" registry for the tee_supported extension. 486 IANA is asked to assign two handshake message types from the "TLS 487 HandshakeType Registry", one for "EapMsg" and one for "InterimAuth". 489 8. Acknowledgments 491 The authors would like to thank Josh Howlett for his comments. 493 The TLS Inner Application Extension work ([TLS/IA]) has inspired the 494 authors to create this simplified work. TLS/IA provides a somewhat 495 different approach to integrating non-certificate credentials into 496 the TLS protocol, in addition to several other features available 497 from the RADIUS namespace. 499 The authors would also like to thank the various contributors to 500 [RFC4306] whose work inspired this one. 502 9. Changes from Previous Versions 504 9.1. Changes in version -02 506 o Added discussion of alternative designs. 508 9.2. Changes in version -01 510 o Changed the construction of the Finished message 511 o Replaced MS-CHAPv2 with GPSK in examples. 512 o Added open issues section. 513 o Added reference to [Compound-Authentication] 514 o Fixed reference to MITM attack 516 9.3. Changes from the protocol model draft 518 o Added diagram for EapMsg 519 o Added discussion of EAP applicability 520 o Added discussion of mutually-authenticated EAP methods vs other 521 methods in the security considerations. 522 o Added operational considerations. 523 o Other minor nits. 525 10. Open Issues 527 Some have suggested that since the protocol is identical to regular 528 TLS up to the InterimAuth message, we should call that the Finished 529 message, and call the last message in the extended handshake 530 something like "EapFinished". This has the advantage that the 531 construction of Finished is already well defined and will not change. 532 However, the Finished message has a specific meaning as indicated by 533 its name. It means that the handshake is over and that application 534 data can now be sent. This is not true of what is in this draft 535 called InterimAuth. We'd like the opinions of reviewrs about this 536 issue. 538 The MSK from the EAP exchange is only used to sign the Finished 539 message. It is not used again in the data encryption. In this we 540 followed the example of IKEv2. The reason is that TLS already has 541 perfectly good ways of exchanging keys, and we do not need this 542 capability from EAP methods. Also, using the MSK in keys would 543 require an additional ChangeCipherSpec and would complicate the 544 protocol. We'd like the opinions of reviewrs about this issue. 546 Another response we got was that we should have a MUST requirement 547 that only mutually authenticated and key-generating methods be used 548 in TEE. This would simplify the security considerations section. 549 While we agree that this is a good idea, most EAP methods in common 550 use are not compliant. Additionally, such requirements assume that 551 EAP packets are visible to a passive attacker. As EAP is used in 552 protected tunnels such as in L2TP, in IKEv2 and here, this assumption 553 may not be required. If we consider the server authenticated by its 554 certificate, it may be acceptable to use a non-MA method. 556 It has been suggested that identity protection is not important 557 enough to add a roundtrip, and so we should have the client send the 558 username in the ClientHello. We are not sure about how others feel 559 about this, and would like to solicit the reviewers opinion. Note 560 that if this is done, the client sends the user name before ever 561 receiving any indication that the server actually supports TEE. This 562 might be acceptable in an email client, where the server is 563 preconfigured, but it may be unacceptable in other uses, such as web 564 browsers. 566 11. References 568 11.1. Normative References 570 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 571 Levkowetz, "Extensible Authentication Protocol (EAP)", 572 RFC 3748, June 2004. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 578 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 580 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 581 and T. Wright, "Transport Layer Security (TLS) 582 Extensions", RFC 4366, April 2006. 584 11.2. Informative References 586 [Compound-Authentication] 587 Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon, 588 "The Compound Authentication Binding Problem", 589 draft-puthenkulam-eap-binding-04 (work in progress), 590 October 2003. 592 [Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 593 Authentication Protocol (EAP) Application", RFC 4072, 594 August 2005. 596 [Diameter] 597 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 598 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 600 [EAP-GPSK] 601 Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared 602 Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in 603 progress), April 2007. 605 [I-D.ietf-eap-keying] 606 Aboba, B., "Extensible Authentication Protocol (EAP) Key 607 Management Framework", draft-ietf-eap-keying-18 (work in 608 progress), February 2007. 610 [I.D.Webauth-phishing] 611 Hartman, S., "Requirements for Web Authentication 612 Resistant to Phishing", draft-hartman-webauth-phishing-03 613 (work in progress), March 2007. 615 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 616 in Tunneled Authentication Protocols", IACR ePrint 617 Archive , October 2002. 619 [RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 620 Dial In User Service) Support For Extensible 621 Authentication Protocol (EAP)", RFC 3579, September 2003. 623 [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 624 "Remote Authentication Dial In User Service (RADIUS)", 625 RFC 2865, June 2000. 627 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 628 RFC 4306, December 2005. 630 [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 631 for Transport Layer Security (TLS)", RFC 4279, 632 December 2005. 634 [TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and 635 T. Hardjono, "TLS Inner Application Extension (TLS/IA)", 636 draft-funk-tls-inner-application-extension-03 (work in 637 progress), June 2006. 639 Authors' Addresses 641 Yoav Nir 642 Check Point Software Technologies Ltd. 643 5 Hasolelim st. 644 Tel Aviv 67897 645 Israel 647 Email: ynir@checkpoint.com 649 Yaron Sheffer 650 Check Point Software Technologies Ltd. 651 5 Hasolelim st. 652 Tel Aviv 67897 653 Israel 655 Email: yaronf at checkpoint dot com 657 Hannes Tschofenig 658 Nokia Siemens Networks 659 Otto-Hahn-Ring 6 660 Munich, Bavaria 81739 661 Germany 663 Email: Hannes.Tschofenig@siemens.com 664 URI: http://www.tschofenig.com 666 Peter Gutmann 667 University of Auckland 668 Department of Computer Science 669 New Zealand 671 Email: pgut001@cs.auckland.ac.nz 673 Full Copyright Statement 675 Copyright (C) The IETF Trust (2008). 677 This document is subject to the rights, licenses and restrictions 678 contained in BCP 78, and except as set forth therein, the authors 679 retain all their rights. 681 This document and the information contained herein are provided on an 682 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 683 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 684 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 685 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 686 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 687 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 689 Intellectual Property 691 The IETF takes no position regarding the validity or scope of any 692 Intellectual Property Rights or other rights that might be claimed to 693 pertain to the implementation or use of the technology described in 694 this document or the extent to which any license under such rights 695 might or might not be available; nor does it represent that it has 696 made any independent effort to identify any such rights. Information 697 on the procedures with respect to rights in RFC documents can be 698 found in BCP 78 and BCP 79. 700 Copies of IPR disclosures made to the IETF Secretariat and any 701 assurances of licenses to be made available, or the result of an 702 attempt made to obtain a general license or permission for the use of 703 such proprietary rights by implementers or users of this 704 specification can be obtained from the IETF on-line IPR repository at 705 http://www.ietf.org/ipr. 707 The IETF invites any interested party to bring to its attention any 708 copyrights, patents or patent applications, or other proprietary 709 rights that may cover technology that may be required to implement 710 this standard. Please address the information to the IETF at 711 ietf-ipr@ietf.org. 713 Acknowledgment 715 Funding for the RFC Editor function is provided by the IETF 716 Administrative Support Activity (IASA).