idnits 2.17.1 draft-nir-tee-pm-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 510. 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (February 21, 2007) is 6274 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 265 ** 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) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 2 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: August 25, 2007 H. Tschofenig 6 Siemens 7 February 21, 2007 9 Protocol Model for TLS with EAP Authentication 10 draft-nir-tee-pm-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 25, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes an extension to the TLS protocol to allow TLS 44 clients to authenticate with legacy credentials using the Extensible 45 Authentication Protocol (EAP). 47 This work follows the example of IKEv2, where EAP has been added to 48 the IKEv2 protocol to allow clients to use different credentials such 49 as passwords, token cards, and shared secrets. 51 When TLS is used with EAP, additional records are sent after the 52 ChangeCipherSpec protocol message, effectively creating an extended 53 handshake before the application layer data can be sent. Each EapMsg 54 handshake record contains exactly one EAP message. Using EAP for 55 client authentication allows TLS to be used with various AAA back-end 56 servers such as RADIUS or Diameter. 58 TLS with EAP may be used for securing a data connection such as HTTP 59 or POP3, where the ability of EAP to work with backend servers can 60 remove that burden from the application layer. 62 This document is a protocol model, rather than a full protocol 63 specification. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 69 2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6 70 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 71 3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8 72 3.2. The InterimAuth Handshake Message . . . . . . . . . . . . 8 73 3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 8 74 3.4. Calculating the Finished message . . . . . . . . . . . . . 8 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10 77 4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10 78 5. Performance Considerations . . . . . . . . . . . . . . . . . . 12 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 Intellectual Property and Copyright Statements . . . . . . . . . . 18 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 using a 91 certificate, or alternatively performing the authentication at the 92 application level. The extension follows [TLS-EXT]. For the 93 remainder of this document we will refer to this extension as TEE 94 (TLS with EAP Extension). The document is a protocol model as 95 described in [RFC4101]. 97 TEE extends the TLS handshake beyond the regular setup, to allow the 98 EAP protocol to run between the TLS server (called an "authenticator" 99 in EAP) and the TLS client (called a "supplicant"). This allows the 100 TLS architecture to handle client authentication before exposing the 101 server application software to an unauthenticated client. In doing 102 this, we follow the approach taken for IKEv2 in [IKEv2]. However, 103 similar to regular TLS, we protect the user identity by only sending 104 the client identity after the server has authenticated. In this our 105 solution defers from that of IKEv2. 107 Currently used applications use TLS to authenticate the server only. 108 After that, the application takes over, and presents a login screen 109 where the user is expected to present their credentials. 111 This creates several problems. It allows a client to access the 112 application before authentication, thus creating a potential for 113 anonymous attacks on non-hardened applications. Additionally, web 114 pages are not particularly well suited for long shared secrets and 115 for certain devices such as USB tokens. 117 TEE allows full mutual authentication to occur for all these 118 applications within the TLS exchange. The application receives 119 control only when the user is identified and authenticated. The 120 authentication can be built into the server infrastructure by 121 connecting to an AAA server. The client side can be integrated into 122 client software such as web browsers and mail clients. An EAP 123 infrastructure is already built-in to some operating systems 124 providing a user interface for each authentication method within EAP. 126 We intend TEE to be used for various protocols that use TLS such as 127 HTTPS, in cases where certificate based authentication is not 128 practical. This includes web-based mail services, online banking, 129 premium content websites and mail clients. 131 Another class of applications that may see benefit from TEE are TLS 132 based VPN clients used as part of so-called "SSL VPN" products. No 133 such client protocols have so far been standardized. 135 1.1. Conventions Used in This Document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 2. Operating Environment 143 TEE will work between a client application and a server application, 144 taking care of all encryption and authentication. 146 Client Server 147 +-------------------------+ +------------------------+ 148 | |GUI| | Client | |TLS+-+-----+-+TLS| |Server | | 149 | +-^-+ |Software| +-^-+ | +-+-^-+ |Application | | 150 | | +--------+ | | | | |Software | | 151 | | | | | | +------------+ | 152 | +-v----------------v-+ | | | | 153 | | EAP | | +---|--------------------+ 154 | | Infrastructure | | | 155 | +--------------------+ | | +--------+ 156 +-------------------------+ | | AAA | 157 | | Server | 158 +----- | 159 +--------+ 161 The above diagram shows the typical deployment. The client has 162 software that either includes a UI for some EAP methods, or else is 163 able to invoke some operating system EAP infrastructure that takes 164 care of the user interaction. The server is configured with the 165 address and protocol of the AAA server. Typically the AAA server 166 communicates using the RADIUS protocol with EAP ([RADIUS] and 167 [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]). 169 As stated in the introduction, we expect TEE to be used in both 170 browsers and applications. Further uses may be authentication and 171 key generation for other protocols, and tunneling clients, which so 172 far have not been standardized. 174 3. Protocol Overview 176 The TEE extension defines the following: 177 o A new extension type called tee_supported, used to indicate that 178 the client supports this extension. 179 o A new message type for the handshake protocol, called InterimAuth, 180 which is used to sign previous messages. 181 o A new message type for the handshake protocol, called EapMsg, 182 which is used to carry a single EAP message. 184 The diagram below outlines the protocol structure. For illustration 185 purposes only, we use the [I-D.dpotter-pppext-eap-mschap] EAP method 186 . 188 Client Server 189 ------ ------ 191 ClientHello(*) --------> 192 ServerHello(*) 193 (Certificate) 194 ServerKeyExchange 195 EapMsg(Identity-Request) 196 <-------- ServerHelloDone 197 ClientKeyExchange 198 (CertificateVerify) 199 ChangeCipherSpec 200 InterimAuth 201 EapMsg(Identity-Reply) --------> 202 ChangeCipherSpec 203 InterimAuth 204 EapMsg(MS-CHAP-v2-Request) 205 <-------- 206 EapMsg(MS-CHAP-v2-Reply) --------> 207 EapMsg(Success) 208 <-------- Finished 209 Finished --------> 211 (*) The ClientHello and ServerHello include the tee_supported 212 extension to indicate support for TEE 214 The client indicates in the first message its support for TEE. The 215 server sends an EAP identity request in the reply. The client sends 216 the identity reply after the handshake completion. The EAP request- 217 response sequence continues until the client is either authenticated 218 or rejected. 220 3.1. The tee_supported Extension 222 The tee_supported extension is a ClientHello and ServerHello 223 extension as defined in section 2.3 of [TLS-EXT]. The extension_type 224 field is TBA by IANA. The extension_data is zero-length. 226 3.2. The InterimAuth Handshake Message 228 The InterimAuth message is identical in syntax to the Finished 229 message described in section 7.4.9 of [TLS]. It is calculated in 230 exactly the same way. 232 The semantics, however, are somewhat different. The "Finished" 233 message indicates that application data may now be sent. The 234 "InterimAuth" message does not indicate this. Instead, further 235 handshake messages are needed. 237 Depending on the EAP method used, the Finished message may be 238 calculated differently. See Section 3.4 for details. 240 The HandshakeType value for the InterimAuth handshake message is TBA 241 by IANA. 243 3.3. The EapMsg Handshake Message 245 The EapMsg handshake message carries exactly one EAP message as 246 defined in [EAP]. 248 The HandshakeType value for the EapMsg handshake message is TBA by 249 IANA. 251 The EapMsg message is used to tunnel EAP messages between the 252 authentication server, which may be the co-located with the TLS 253 server, or may be a separate AAA server, and the supplicant, which is 254 co-located with the TLS client. TLS on either side receives the EAP 255 data from the EAP infrastructure, and treats it as opaque. TLS does 256 not make any changes to the EAP payload or make any decisions based 257 on the contents of an EapMsg handshake message. 259 3.4. Calculating the Finished message 261 If the EAP method is key-generating, the Finished message is 262 calculated as follows: 264 struct { 265 opaque verify_data[12]; 266 } Finished; 268 verify_data 269 PRF(MSK, finished_label, MD5(handshake_messages) + 270 SHA-1(handshake_messages)) [0..11]; 272 The finished_label is defined exactly as in section 7.4.9 of [TLS]. 274 The handshake_messages, similar to regular TLS is all of the data 275 from all messages in this handshake, including any EapMsg and 276 InterimAuth messages, up to but not including this Finished message. 277 This is the concatenation of all the Handshake structures, as defined 278 in section 7.4 of [TLS] and here, exchanged thus far. 280 The MSK is typically received from the AAA server over the RADIUS or 281 Diameter protocol. 283 If the EAP method is not key-generating, then the Finished message is 284 calculated exactly as described in [TLS]. Such methods however, are 285 NOT RECOMMENDED. See Section 4.1 for details. 287 4. Security Considerations 289 4.1. InterimAuth vs. Finished 291 In regular TLS, the Finished message provides two functions: it signs 292 all previous messages, and it signals that application data can now 293 be used. In TEE, we sign the previous messages twice. 295 Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate 296 keys in addition to authenticating clients. Such methods are said to 297 be resistant to MITM attacks as discussed in [MITM]. Such methods 298 are called key-generating methods. 300 To realize the benefit of such methods, we need to verify the key 301 that was generated within the EAP method. This is referred to as the 302 MSK in EAP. In TEE, the InterimAuth message signs all previous 303 messages with the master_secret, just like the Finished message in 304 regular TLS. The Finished message signs all previous messages using 305 the MSK if such exists. If not, then the messages are signed with 306 the master_secret as in regular TLS. 308 The need for signing twice arises from the fact that we need to use 309 both the master_secret and the MSK. It was possible to use just one 310 Finished record and blend the MSK into the master_secret. However, 311 this would needlessly complicate the protocol and make security 312 analysis more difficult. Instead, we have decided to follow the 313 example of IKEv2, where two AUTH payloads are exchanged. 315 It should be noted that using non-key-generating methods may expose 316 the client to a MITM attack if the same MITM method is used in some 317 other situation, in which the EAP is done outside of a protected 318 tunnel with an authenticated server. Unless it can be determined 319 that the EAP method is never used in such a situation, non-key- 320 generating methods SHOULD NOT be used. 322 4.2. Identity Protection 324 Unlike [TLS-PSK], TEE provides identity protection for the client. 325 The client's identity is hidden from a passive eavesdropper using TLS 326 encryption, and it is not sent to the server until after the server's 327 identity has been authenticated by verifying the certificate. 329 Active attacks are thwarted by the server authentication using a 330 certificate or by using a suitable EAP method. 332 We could save one round-trip by having the client send its identity 333 within the Client Hello message. This is similar to TLS-PSK. 334 However, we believe that identity protection is a worthy enough goal, 335 so as to justify the extra round-trip. 337 5. Performance Considerations 339 Regular TLS adds two round-trips to a TCP connection. However, 340 because of the stream nature of TCP, the client does not really need 341 to wait for the server's Finished message, and can begin sending 342 application data immediately after its own Finished message. In 343 practice, many clients do so, and TLS only adds one round-trip of 344 delay. 346 TEE adds as many round-trips as the EAP method requires. For 347 example, EAP-MD5 requires 1 round-trip, while EAP-SIM requires 2 348 round-trips. Additionally, the client MUST wait for the EAP-Success 349 message before sending its own Finished message, so we need at least 350 3 round-trips for the entire handshake. The best a client can do is 351 two round-trips plus however many round-trips the EAP method 352 requires. 354 It should be noted, though, that these extra round-trips save 355 processing time at the application level. Two extra round-trips take 356 a lot less time than presenting a log-in web page and processing the 357 user's input. 359 It should also be noted, that TEE reverses the order of the Finished 360 messages. In regular TLS the client sends the Finished message 361 first. In TEE it is the server that sends the Finished message 362 first. This should not affect performance, and it is clear that the 363 client may send application data immediately after the Finished 364 message. 366 6. IANA Considerations 368 IANA is asked to assign an extension type value from the 369 "ExtensionType Values" registry for the tee_supported extension. 371 IANA is asked to assign two handshake message types from the "TLS 372 HandshakeType Registry", one for "EapMsg" and one for "InterimAuth". 374 7. Acknowledgments 376 The TLS Innel Application Extension work ([TLS/IA]) has inspired the 377 authors to create this simplified work. TLS/IA provides a somewhat 378 different approach to integrating non-certificate credentials into 379 the TLS protocol, in addition to several other features available 380 from the RADIUS namespace. 382 The authors would also like to thanks the various contributors to 383 [IKEv2] whose work inspired this one. 385 8. References 387 8.1. Normative References 389 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 390 Levkowetz, "Extensible Authentication Protocol (EAP)", 391 RFC 3748, June 2004. 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 397 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 399 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 400 and T. Wright, "Transport Layer Security (TLS) 401 Extensions", RFC 4366, April 2006. 403 8.2. Informative References 405 [Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 406 Authentication Protocol (EAP) Application", RFC 4072, 407 August 2005. 409 [Diameter] 410 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 411 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 413 [I-D.dpotter-pppext-eap-mschap] 414 Potter, D. and J. Zamick, "PPP EAP MS-CHAP-V2 415 Authentication Protocol", 416 draft-dpotter-pppext-eap-mschap-01 (work in progress), 417 January 2002. 419 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 420 RFC 4306, December 2005. 422 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 423 in Tunneled Authentication Protocols", October 2002. 425 [RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 426 Dial In User Service) Support For Extensible 427 Authentication Protocol (EAP)", RFC 3579, September 2003. 429 [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 430 "Remote Authentication Dial In User Service (RADIUS)", 431 RFC 2865, June 2000. 433 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 434 June 2005. 436 [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 437 for Transport Layer Security (TLS)", RFC 4279, 438 December 2005. 440 [TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and 441 T. Hardjono, "TLS Inner Application Extension (TLS/IA)", 442 draft-funk-tls-inner-application-extension-03 (work in 443 progress), June 2006. 445 Authors' Addresses 447 Yoav Nir 448 Check Point Software Technologies Ltd. 449 3A Jabotinsky St. 450 Ramat Gan 52520 451 Israel 453 Email: ynir@checkpoint.com 455 Yaron Sheffer 456 Check Point Software Technologies Ltd. 457 3A Jabotinsky St. 458 Ramat Gan 52520 459 Israel 461 Email: yaronf at checkpoint dot com 463 Hannes Tschofenig 464 Siemens 465 Otto-Hahn-Ring 6 466 Munich, Bavaria 81739 467 Germany 469 Email: Hannes.Tschofenig@siemens.com 470 URI: http://www.tschofenig.com 472 Full Copyright Statement 474 Copyright (C) The IETF Trust (2007). 476 This document is subject to the rights, licenses and restrictions 477 contained in BCP 78, and except as set forth therein, the authors 478 retain all their rights. 480 This document and the information contained herein are provided on an 481 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 482 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 483 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 484 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 485 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 486 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 488 Intellectual Property 490 The IETF takes no position regarding the validity or scope of any 491 Intellectual Property Rights or other rights that might be claimed to 492 pertain to the implementation or use of the technology described in 493 this document or the extent to which any license under such rights 494 might or might not be available; nor does it represent that it has 495 made any independent effort to identify any such rights. Information 496 on the procedures with respect to rights in RFC documents can be 497 found in BCP 78 and BCP 79. 499 Copies of IPR disclosures made to the IETF Secretariat and any 500 assurances of licenses to be made available, or the result of an 501 attempt made to obtain a general license or permission for the use of 502 such proprietary rights by implementers or users of this 503 specification can be obtained from the IETF on-line IPR repository at 504 http://www.ietf.org/ipr. 506 The IETF invites any interested party to bring to its attention any 507 copyrights, patents or patent applications, or other proprietary 508 rights that may cover technology that may be required to implement 509 this standard. Please address the information to the IETF at 510 ietf-ipr@ietf.org. 512 Acknowledgment 514 Funding for the RFC Editor function is provided by the IETF 515 Administrative Support Activity (IASA).