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