idnits 2.17.1 draft-nir-tls-eap-13.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 (December 19, 2011) is 4511 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 5246 (ref. 'TLS') (Obsoleted by RFC 8446) ** 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) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: June 21, 2012 Independent 6 H. Tschofenig 7 NSN 8 P. Gutmann 9 University of Auckland 10 December 19, 2011 12 A Flexible Authentication Framework for the Transport Layer Security 13 (TLS) Protocol using the Extensible Authentication Protocol (EAP) 14 draft-nir-tls-eap-13 16 Abstract 18 Many of today's Web security problems have their root in the 19 widespread usage of weak authentication mechanisms bundled with the 20 usage of password based credentials. Dealing with both of these 21 problems is the basis of this publication. 23 This document extends the Transport Layer Security (TLS) protocol 24 with a flexible and widely deployed authentication framework, namely 25 the Extensible Authentication Protocol (EAP), to improve security of 26 Web- as well as non-Web-based applications. The EAP framework allows 27 so-called EAP methods, i.e. authentication and key exchange 28 protocols, to be plugged into EAP without having to re-design the 29 underlying protocol. The benefit of such an easy integration is the 30 ability to run authentication protocols that fit a specific 31 deployment environment, both from a credential choice as well as from 32 the security and performance characteristics of the actual protocol. 34 This work follows the example of IKEv2, where EAP has been added to 35 allow clients to seamlessly use different forms of authentication 36 credentials, such as passwords, token cards, and shared secrets. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on June 21, 2012. 55 Copyright Notice 57 Copyright (c) 2011 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. EAP Applicability . . . . . . . . . . . . . . . . . . . . 5 74 1.2. Comparison with Design Alternatives . . . . . . . . . . . 5 75 1.3. Conventions Used in This Document . . . . . . . . . . . . 5 76 2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6 77 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 78 3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8 79 3.2. The EapFinished Handshake Message . . . . . . . . . . . . 8 80 3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 9 81 3.4. Calculating the EapFinished message . . . . . . . . . . . 9 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 4.1. EapFinished vs. Finished . . . . . . . . . . . . . . . . . 11 84 4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 11 85 4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 12 86 5. Performance Considerations . . . . . . . . . . . . . . . . . . 13 87 6. Operational Considerations . . . . . . . . . . . . . . . . . . 14 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 90 9. Changes from Previous Versions . . . . . . . . . . . . . . . . 17 91 9.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 17 92 9.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 17 93 9.3. Changes from the protocol model draft . . . . . . . . . . 17 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 This document describes a new extension to [TLS]. This extension 102 allows a TLS client to authenticate using [EAP] instead of performing 103 the authentication at the application level. The extension follows 104 [TLS-EXT]. For the remainder of this document we will refer to this 105 extension as TEE (TLS with EAP Extension). 107 TEE extends the TLS handshake beyond the regular setup, to allow the 108 EAP protocol to run between the TLS server (called an "authenticator" 109 in EAP) and the TLS client (called either a "supplicant" or a 110 "peer"). This allows the TLS architecture to handle client 111 authentication before exposing the server application software to an 112 unauthenticated client. In doing this, we follow the approach taken 113 for IKEv2 in [RFC5996]. However, similar to regular TLS, we protect 114 the user identity by only sending the client identity after the 115 server has authenticated. In this our solution differs from that of 116 IKEv2. 118 Currently used applications that rely on non-certificate user 119 credentials use TLS to authenticate the server only. After that, the 120 application takes over, and presents a login screen where the user is 121 expected to present their credentials. 123 This creates several problems. It allows a client to access the 124 application before authentication, thus creating a potential for 125 anonymous attacks on non-hardened applications. Additionally, web 126 pages are not particularly well suited for long shared secrets and 127 for interfacing with certain devices such as USB tokens. 129 TEE allows full mutual authentication to occur for all these 130 applications within the TLS exchange. The application receives 131 control only when the user is identified and authenticated. The 132 authentication can be built into the server infrastructure by 133 connecting to an AAA server. The client side can be integrated into 134 client software such as web browsers and mail clients. An EAP 135 infrastructure is already built into some operating systems providing 136 a user interface for each authentication method within EAP. 138 We intend TEE to be used for various protocols that use TLS such as 139 HTTPS, in cases where certificate based client authentication is not 140 practical. This includes web-based mail services, online banking, 141 premium content websites and mail clients. 143 Another class of applications that may see benefit from TEE are TLS 144 based VPN clients used as part of so-called "SSL VPN" products. No 145 such client protocols have so far been standardized. 147 1.1. EAP Applicability 149 Section 1.3 of [EAP] states that EAP is only applicable for network 150 access authentication, rather than for "bulk data transfer". It then 151 goes on to explain why the transport properties of EAP indeed make it 152 unsuitable for bulk data transfer, e.g. for large file transport. 153 Our proposed use of EAP falls squarely within the applicability as 154 defined, since we make no further use of EAP beyond access 155 authentication. 157 1.2. Comparison with Design Alternatives 159 It has been suggested to implement EAP authentication as part of the 160 protected application, rather than as part of the TLS handshake. A 161 BCP document could be used to describe a secure way of doing this. 162 The drawbacks we see in such an approach are listed below: 163 o EAP does not have a pre-defined transport method. Application 164 designers would need to specify an EAP transport for each 165 application. Making this a part of TLS has the benefit of a 166 single specification for all protected applications. 167 o The integration of EAP and TLS is security-sensitive and should be 168 standardized and interoperable. We do not believe that it should 169 be left to application designers to do this in a secure manner. 170 Specifically on the server-side, integration with AAA servers adds 171 complexity and is more naturally part of the underlying 172 infrastrcture. 173 o Our current proposal provides channel binding between TLS and EAP, 174 to counter the MITM attacks described in [MITM]. TLS does not 175 provide any standard way of extracting cryptographic material from 176 the TLS state, and in most implementations, the TLS state is not 177 exposed to the protected application. Because of this, it is 178 difficult for application designers to bind the user 179 authentication to the protected channel provided by TLS. 181 1.3. Conventions Used in This Document 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 2. Operating Environment 189 TEE will work between a client application and a server application, 190 performing either client authentication or mutual authentication 191 within the TLS exchange. 193 Client Server 194 +-------------------------+ +------------------------+ 195 | |GUI| | Client | |TLS+-+-----+-+TLS| |Server | | 196 | +-^-+ |Software| +-^-+ | +-+-^-+ |Application | | 197 | | +--------+ | | | | |Software | | 198 | | | | | | +------------+ | 199 | +-v----------------v-+ | | | | 200 | | EAP | | +---|--------------------+ 201 | | Infrastructure | | | 202 | +--------------------+ | | +--------+ 203 +-------------------------+ | | AAA | 204 | | Server | 205 +----- | 206 +--------+ 208 The above diagram shows the typical deployment. The client has 209 software that either includes a UI for some EAP methods, or else is 210 able to invoke some operating system EAP infrastructure that takes 211 care of the user interaction. Although the technical mechanisms have 212 been standardized for a AAA client to dynamically discover a AAA 213 server often the address of the AAA server is statically configured. 214 Typically the AAA server communicates using the RADIUS protocol with 215 EAP ([RADIUS] and [RAD-EAP]), or the Diameter protocol ([Diameter] 216 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 When TLS is used with EAP, additional records are sent after the 226 ChangeCipherSpec protocol message and before the Finished message, 227 effectively creating an extended handshake before the application 228 layer data can be sent. Each EapMsg handshake record contains 229 exactly one EAP message. Using EAP for client authentication allows 230 TLS to be used with various AAA back-end servers such as RADIUS or 231 Diameter. 233 TLS with EAP may be used for securing a data connection such as HTTP 234 or POP3. We believe it has three main benefits: 235 o The ability of EAP to work with backend servers can remove that 236 burden from the application layer. 237 o Moving the user authentication into the TLS handshake protects the 238 presumably less secure application layer from attacks by 239 unauthenticated parties. 240 o Using mutual authentication methods within EAP can help thwart 241 certain classes of phishing attacks. 243 The TEE extension defines the following: 244 o A new extension type called tee_supported, used to indicate that 245 the communicating application (either client or server) supports 246 this extension. 247 o A new message type for the handshake protocol, called EapMsg, 248 which is used to carry a single EAP message. 249 o A new message type for the handshake protocol, called EapFinished, 250 which is used to sign previous messages. 252 The diagram below outlines the protocol structure. For illustration 253 purposes only, we use EAP Generalized Pre-Shared Key (EAP-GPSK) 254 method [RFC5433]. This method is a lightweight shared-key 255 authentication protocol supporting mutual authentication and key 256 derivation. 258 Client Server 259 ------ ------ 261 ClientHello(*) --------> 262 ServerHello(*) 263 (Certificate) 264 ServerKeyExchange 265 EapMsg(Identity-Request) 266 <-------- ServerHelloDone 267 ClientKeyExchange 268 (CertificateVerify) 269 ChangeCipherSpec 270 Finished 271 EapMsg(Identity-Reply) --------> 272 ChangeCipherSpec 273 Finished 274 EapMsg(GPSK-Request) 275 <-------- 276 EapMsg(GPSK-Reply) --------> 277 EapMsg(GPSK-Request) 278 <-------- 279 EapMsg(GPSK-Reply) --------> 280 EapMsg(Success) 281 <-------- EaoFinished 282 EapFinished --------> 284 (*) The ClientHello and ServerHello include the tee_supported 285 extension to indicate support for TEE 287 The client indicates in the first message its support for TEE. The 288 server sends an EAP identity request in the reply. The client sends 289 the identity reply after the handshake completion. The EAP request- 290 response sequence continues until the client is either authenticated 291 or rejected. 293 3.1. The tee_supported Extension 295 The tee_supported extension is a ClientHello and ServerHello 296 extension as defined in section 2.3 of [TLS-EXT]. The extension_type 297 field is TBA by IANA. The extension_data is zero-length. 299 3.2. The EapFinished Handshake Message 301 The EapFinished message is identical in syntax to the Finished 302 message described in section 7.4.9 of [TLS]. It is calculated in 303 exactly the same way. 305 When TEE is used, application data cannot follow the "Finished" 306 message. Instead, it may only begin after the EapFinished message 308 The HandshakeType value for the EapFinished 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 EapFinished message 341 If the EAP method is key-generating (see [RFC5247]), the Finished 342 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 354 [TLS]. 356 The handshake_messages field does not include all the data in the 357 handshake. Instead it includes only the data that has not been 358 signed by the previous Finished message. The handshake_messages 359 field includes all of the octets beginning with and including the 360 Finished message, up to but not including this EapFinished message. 361 This is the concatenation of all the Handshake structures exchanged 362 thus far, and not yet signed, as defined in section 7.4 of [TLS]and 363 in this document. 365 The Master Session Key (MSK) is derived by the AAA server and by the 366 client if the EAP method is key-generating. On the server-side, it 367 is typically received from the AAA server over the RADIUS or Diameter 368 protocol. On the client-side, it is passed to TLS by some other 369 method. 371 If the EAP method is not key-generating, then the master_secret is 372 used to sign the messages instead of the MSK. For a discussion on 373 the use of such methods, see Section 4.1. 375 4. Security Considerations 377 4.1. EapFinished vs. Finished 379 In regular TLS, the Finished message provides two functions: it signs 380 all preceding messages, and it signals that application data can now 381 be sent. In TEE, it only signs, and the signal is given by 382 EapFinished. 384 Many EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM, generate 385 keys in addition to authenticating clients. Such methods are 386 resistant to man-in-the-middle (MITM) attacks, as discussed in [MITM] 387 and are called key-generating methods. 389 To realize the benefit of such methods, we need to verify the key 390 that was generated within the EAP method. This is referred to as the 391 MSK in EAP. In TEE, the EapFinished message signs the messages that 392 have not yet been signed by the Finished message using the MSK if 393 such exists. If not, then the messages are signed with the 394 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 EAP-GPSK. The client would be authenticated to the AAA server 436 and vice versa. Additionally authenticating the application 437 server to the client is not necessary and the TLS handshake may 438 as well be anonymous. Note that the authenticated client 439 identity may be sent from the AAA server to the application 440 server (acting as a AAA client) if the authenticated identity 441 indeed matters for the purpose of the service fulfillment and 442 with the user's permission. 444 To summarize: 445 o Clients MUST NOT propose anonymous ciphersuites, unless they 446 support MA EAP methods. 447 o Clients MUST NOT accept non-MA methods if the ciphersuite is 448 anonymous. 449 o Clients MUST NOT accept non-MA methods if they are not able to 450 verify the server credentials. Note that this document does not 451 define what verification involves. If the server DN is known and 452 stored on the client, verifying certificate signature and checking 453 revocation may be enough. For web browsers, the case is not as 454 clear cut, and MA methods SHOULD be used. 456 5. Performance Considerations 458 Regular TLS adds two round-trips to a TCP connection. However, 459 because of the stream nature of TCP, the client does not really need 460 to wait for the server's Finished message, and can begin sending 461 application data immediately after its own Finished message. In 462 practice, many clients do so, and TLS only adds one round-trip of 463 delay. 465 TEE adds as many round-trips as the EAP method requires. For 466 example, EAP-MD5 requires 1 round-trip, while EAP-GPSK requires 2 467 round-trips. Additionally, the client MUST wait for the EAP-Success 468 message before sending its own Finished message, so we need at least 469 3 round-trips for the entire handshake. The best a client can do is 470 two round-trips plus however many round-trips the EAP method 471 requires. 473 It should be noted, though, that these extra round-trips save 474 processing time at the application level. Two extra round-trips take 475 a lot less time than presenting a log-in web page and processing the 476 user's input. 478 It should also be noted, that TEE reverses the order of the Finished 479 messages. In regular TLS the client sends the Finished message 480 first. In TEE it is the server that sends the Finished message 481 first. This should not affect performance, and it is clear that the 482 client may send application data immediately after the Finished 483 message. 485 6. Operational Considerations 487 Section 4.3 defines a dependency between the TLS state and the EAP 488 state in that it mandates that certain EAP methods should not be used 489 with certain TLS ciphersuites. To avoid such dependencies, there are 490 two approaches that implementations can take. They can either not 491 use any anonymous ciphersuites, or else they can use only MA EAP 492 methods. 494 Where certificate validation is problematic, such as in browser-based 495 HTTPS, we recommend the latter approach. 497 In cases where the use of EAP within TLS is not known before opening 498 the connection, it is necessary to consider the implications of 499 requiring the user to type in credentials after the connection has 500 already started. TCP sessions may time out, because of security 501 considerations, and this may lead to session setup failure. 503 7. IANA Considerations 505 IANA is asked to assign an extension type value from the 506 "ExtensionType Values" registry for the tee_supported extension. 508 IANA is asked to assign two handshake message types from the "TLS 509 HandshakeType Registry", one for "EapMsg" and one for "EapFinished". 511 8. Acknowledgments 513 The authors would like to thank Josh Howlett for his comments. 515 The TLS Inner Application Extension work ([TLSIA]) has inspired the 516 authors to create this simplified work. TLS/IA provides a somewhat 517 different approach to integrating non-certificate credentials into 518 the TLS protocol, in addition to several other features available 519 from the RADIUS namespace. 521 The authors would also like to thank the various contributors to 522 [RFC5996] whose work inspired this one. 524 9. Changes from Previous Versions 526 9.1. Changes in version -02 528 o Added discussion of alternative designs. 530 9.2. Changes in version -01 532 o Changed the construction of the Finished message 533 o Replaced MS-CHAPv2 with GPSK in examples. 534 o Added open issues section. 535 o Added reference to [Compound-Authentication] 536 o Fixed reference to MITM attack 538 9.3. Changes from the protocol model draft 540 o Added diagram for EapMsg 541 o Added discussion of EAP applicability 542 o Added discussion of mutually-authenticated EAP methods vs other 543 methods in the security considerations. 544 o Added operational considerations. 545 o Other minor nits. 547 10. References 549 10.1. Normative References 551 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 552 Levkowetz, "Extensible Authentication Protocol (EAP)", 553 RFC 3748, June 2004. 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 559 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 561 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 562 and T. Wright, "Transport Layer Security (TLS) 563 Extensions", RFC 4366, April 2006. 565 10.2. Informative References 567 [Compound-Authentication] 568 Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon, 569 "The Compound Authentication Binding Problem", 570 draft-puthenkulam-eap-binding-04 (work in progress), 571 October 2003. 573 [Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 574 Authentication Protocol (EAP) Application", RFC 4072, 575 August 2005. 577 [Diameter] 578 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 579 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 581 [I.D.Webauth-phishing] 582 Hartman, S., "Requirements for Web Authentication 583 Resistant to Phishing", draft-hartman-webauth-phishing-09 584 (work in progress), August 2008. 586 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 587 in Tunneled Authentication Protocols", IACR ePrint 588 Archive , October 2002. 590 [RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 591 Dial In User Service) Support For Extensible 592 Authentication Protocol (EAP)", RFC 3579, September 2003. 594 [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 595 "Remote Authentication Dial In User Service (RADIUS)", 596 RFC 2865, June 2000. 598 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 599 Authentication Protocol (EAP) Key Management Framework", 600 RFC 5247, August 2008. 602 [RFC5433] Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared 603 Key (EAP-GPSK)", RFC 5433, February 2009. 605 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 606 "Internet Key Exchange Protocol: IKEv2", RFC 5996, 607 September 2010. 609 [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 610 for Transport Layer Security (TLS)", RFC 4279, 611 December 2005. 613 [TLSIA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and 614 T. Hardjono, "TLS Inner Application Extension (TLS/IA)", 615 draft-funk-tls-inner-application-extension-03 (work in 616 progress), June 2006. 618 Authors' Addresses 620 Yoav Nir 621 Check Point Software Technologies Ltd. 622 5 Hasolelim st. 623 Tel Aviv 67897 624 Israel 626 Email: ynir@checkpoint.com 628 Yaron Sheffer 629 Independent 631 Email: yaronf.ietf@gmail.com 633 Hannes Tschofenig 634 Nokia Siemens Networks 635 Linnoitustie 6 636 Espoo 02600 637 Finland 639 Phone: +358 (50) 4871445 640 Email: Hannes.Tschofenig@gmx.net 641 URI: http://www.tschofenig.priv.at 643 Peter Gutmann 644 University of Auckland 645 Department of Computer Science 646 New Zealand 648 Email: pgut001@cs.auckland.ac.nz