idnits 2.17.1 draft-williams-tls-app-sasl-opt-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2010) is 5022 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) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 592, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Williams 3 Internet-Draft Oracle 4 Intended status: Standards Track July 26, 2010 5 Expires: January 27, 2011 7 TLS Extension for Optimizing Application Protocols, Specifically SASL 8 with GSS-API mechanisms 9 draft-williams-tls-app-sasl-opt-04.txt 11 Abstract 13 This document specifies Hello extensions to Transport Layer Security 14 (TLS). One extension is used for carrying application data which is 15 suitable for delayed integrity protection and does not require 16 privacy protection. Another extension is used to negotiate an early 17 start to the application data protocol in the case of initial TLS 18 connections (i.e., which do not resume sessions). 20 We describe how to use these extensions to reduce the number of round 21 trips needed for application-layer authentication, by piggy-backing 22 Simple Authentication (SASL) mechanism negotiation on the first leg 23 of a TLS handshake and the first round of SASL authentication 24 messages on the second leg of the same TLS handshake. Through SASL 25 we get support for Generic Security Services (GSS-API) mechanisms. 26 Channel binding is used from SASL authentication to the TLS channel. 27 This results in a two round-trip optimization for applications that 28 use SASL on top of TLS. 30 We also provide generic framing for SASL authentication messages 31 which, combined with the use of these extensions, will be referred to 32 as "TLS/SA". These extensions can also be used to optimize 33 application protocols separately from SASL. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on January 27, 2011. 57 Copyright Notice 59 Copyright (c) 2010 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Conventions used in this document . . . . . . . . . . . . . 5 76 2. TLS Extensions for Optimization of Application protocols . . 6 77 3. Sending Application Data in TLS Hello Messages . . . . . . . 9 78 3.1. Optimizing SASL Mechanism Negotiation . . . . . . . . . . . 9 79 4. Application Data Protocol Early Start . . . . . . . . . . . 10 80 5. Use with StartTLS-like Protocols . . . . . . . . . . . . . . 11 81 6. Using TLS with the GSS-API . . . . . . . . . . . . . . . . . 12 82 7. Using these Extensions with Existing SASL Applications . . . 13 83 8. TLS/SA (TLS + SASL with generic framing of SASL 84 authentication messages) . . . . . . . . . . . . . . . . . . 14 85 8.1. TLS/SA Exchanges . . . . . . . . . . . . . . . . . . . . . . 14 86 9. Channel Binding . . . . . . . . . . . . . . . . . . . . . . 20 87 10. Application Control of Authentication and Applicability 88 of TLS/SA . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 11. Contrived Examples of Non-SASL Optimizations of Existing 90 Application Protocols . . . . . . . . . . . . . . . . . . . 22 91 11.1. Contrived Example: LDAP . . . . . . . . . . . . . . . . . . 22 92 11.2. Contrived Example: SMTP . . . . . . . . . . . . . . . . . . 22 93 12. Impact on TLS Concentrators . . . . . . . . . . . . . . . . 23 94 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 95 14. Security Considerations . . . . . . . . . . . . . . . . . . 25 96 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 15.1. Normative References . . . . . . . . . . . . . . . . . . . . 26 98 15.2. Informative References . . . . . . . . . . . . . . . . . . . 26 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 Many applications use TLS [RFC5246] and then Simple Authentication 104 and Security Layers (SASL) [RFC4422] on top of TLS. This requires at 105 least two round trips for TLS, then one round trip for SASL mechanism 106 negotiation, then as many round trips as the negotiated SASL 107 mechanism requires. The TLS Hello exchanges can can carry extensions 108 bearing application data. We could also define additional non-Hello 109 Handshake extensions to carry application data, but it suffices to be 110 able to start using TLS application records as soon as the client's 111 Finished message is sent, without waiting for a server reply (in the 112 new TLS session case). Here we describe how to use such TLS 113 extensions to reduce the number of round trips needed for SASL 114 mechanism negotiation and authentication. 116 We define a TLS extension for use in Hello messages. This extension 117 will carry typed application data. We also define a TLS Hello 118 extension for negotiating an early start for the TLS application 119 record protocol. 121 Through the new SASL to GSS-API mechanism bridge, GS2 [RFC5801], we 122 obtain support for use of GSS-API [RFC2743] security mechanisms. 123 Altogether we achieve up to a two round-trip reduction for 124 applications using SASL over TLS. 126 We use the first TLS round trip to optimize the SASL mechanism 127 negotiation by piggybacking the mechanism negotiation on TLS Hello 128 messages. By negotiating an early start to the TLS application 129 record protocol we can send the first authentication message of the 130 selected SASL mechanism in the second leg of the TLS handshake, 131 immediately after the client's Finished message is sent. Note that 132 the TLS channel binding [RFC5929] is available just in time to start 133 the SASL authentication at that time, thus no special considerations 134 apply to how channel binding is done. Use of channel binding 135 protects against man-in-the-middle attacks as well as downgrade 136 attacks on mechanism negotiation. 138 These extensions are motivated by: 140 o a desire to reduce the number of round trips needed by SASL and 141 GSS-API applications running over TLS; 143 o a desire to replace an earlier proposal for "TLS/GSS" with one 144 that passes muster at the TLS implementor community; 146 o a desire to provide a profile that new applications may use for 147 TLS with SASL and/or GSS-API for user authentication. 149 The use of these extensions to optimize SASL/GSS-API authentication 150 is hereby termed "Transport Layer Security with Simple 151 Authentication", or "TLS/SA" for short. 153 1.1. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 2. TLS Extensions for Optimization of Application protocols 161 When a client application wishes to exchange one or more application 162 messages prior to the conclusion of a TLS exchange it uses TLS client 163 Hello message extensions to a) request permission to start the 164 application record protocol early, and b) optionally send the first 165 application message to the server. Such application data MUST NOT 166 require privacy or integrity protection, unless either a) the current 167 TLS handshake is part of a renegotiation [RFC5746] where the previous 168 negotiation established cipher suites that provide the required 169 protection or b) deferred integrity protection is sufficient. 171 When an application data bearing Hello message is received the server 172 will either ignore the extension or pass it to the application, which 173 then may respond to that application data via the server's Hello 174 message. If the server or server application ignores the client's 175 Hello extension then the client will discover that the server does 176 not support this extension when the client receives the server's 177 Hello. 179 The extension contents are defined by the application. In order to 180 save the application having to encode application "type" information 181 we define application data extension types and we allow the Client 182 Hello to carry one of each of these extensions: 184 o app_hello () 186 o sasl_sml () 188 o early_start () 190 It is the application's responsibility to define the contents of the 191 app_hello Hello extension. 193 The sasl_sml Hello extension represents a SASL server mechanism list 194 request. The server returns this list, if it can, via the same Hello 195 extension in its Hello. The client's sasl_sml MUST be have an empty 196 value. The client will use this server's SASL mechanism list to pick 197 a suitable SASL mechanism. See Section 3.1 for details of the 198 encoding of the server's SASL mechanism list. 200 The early_start extension requests permission to start the 201 application data record protocol on the client-side immediately after 202 sending the client's Finished message (which, in the case of initial 203 TLS connections, is sent before receiving the server's Finished 204 message). Servers that supports this extension MUST include the same 205 extension in its Hello message with the same value. The value of 206 early_start consists of an encoded enum (EarlyStartProto) that 207 indicates the kind of application data that will be sent early: 209 enum { app_protocol (0), generic_sasl(1), (255) 210 } EarlyStartProto; 212 Figure 1: EarlyStartProto TLS Hello extension 214 If the value of early_start is app_protocol (0), then the contents of 215 format of the early start application data is defined by the 216 application; see Section 7 and Section 11. If the value of 217 early_start is generic_sasl(1) then the application is said to be a 218 "TLS/SA" application, and SASL messages will be exchanged as 219 application records, with generic framing described in Section 8, 220 until authentication succeeds or fails, at which point the actual 221 application protocol will take over the TLS application records. 223 A generic application protocol using these TLS extensions might look 224 like: 226 Client Server 228 ClientHello w/ sasl_sml 229 early_start --------> 230 ServerHello w/ 231 sasl_sml 232 early_start 233 Certificate* 234 ServerKeyExchange* 235 CertificateRequest* 236 <-------- ServerHelloDone 237 Certificate* 238 ClientKeyExchange 239 CertificateVerify* 240 [ChangeCipherSpec] 241 Finished 242 SASL auth message as data --------> 243 [ChangeCipherSpec] 244 Finished 245 <-------- SASL auth message 246 SASL auth messages <-------> SASL auth messages 247 <-------- Outcome of SASL 248 authentication 249 Application Data <-------> Application Data 251 Figure 2: Message flow for initial TLS connections with SASL 252 mechanism negotiation and SASL authentication 254 Client Server 256 ClientHello w/ sasl_sml 257 early_start --------> 258 ServerHello w/ 259 sasl_sml 260 early_start 261 [ChangeCipherSpec] 262 <-------- Finished 263 [ChangeCipherSpec] 264 Finished 265 SASL auth message as data --------> 266 <-------- SASL auth message 267 SASL auth messages <-------> SASL auth messages 268 <-------- Outcome of SASL 269 authentication 270 Application Data <-------> Application Data 272 Figure 3: Message flow for resumed TLS connections with SASL 273 mechanism negotiation and SASL authentication 275 3. Sending Application Data in TLS Hello Messages 277 The app_hello client Hello message extension can be used to send 278 arbitrary application-specific messages in the client Hello. The 279 application MUST NOT use this extension unless both of these 280 requirements are met: 282 1. the application data being sent in the app_hello and the reply 283 expected in the app_hello reply MUST NOT require privacy 284 protection unless either the TLS connection is part of a 285 renegotiation of another that provides the required protection 286 and/or deferred integrity protetion is sufficient; 288 2. the application on the server side knows unambiguously what data 289 to expect in an app_hello. 291 For example, SMTP could use the app_hello extension to send its EHLO 292 before the TLS handshake completes. 294 The app_hello extension data and early-start application records are 295 ultimately integrity-protected once the TLS Finished message exchange 296 completes, if the TLS connection uses a non-null TLS ciphersuite. 298 3.1. Optimizing SASL Mechanism Negotiation 300 A client wishing to optimize SASL mechanism negotiation MUST send a 301 sasl_sml extension in the client's TLS Hello message. The client 302 MUST NOT send a payload in its sasl_sml client hello extension. 304 If the server supports SASL mechanism negotiation optimization and 305 the server's mechanism list is shorter than 2^16 - 1 bytes then the 306 server MUST include a sasl_sml Hello extension in its reply to the 307 client. The payload of the server's sasl_sml MUST be a string of 308 ASCII characters representing a comma-separated list of SASL 309 mechanism names (note: servers SHOULD NOT send a NUL string 310 terminator is needed, but if present the client MUST ignore the NUL). 312 4. Application Data Protocol Early Start 314 Applications may request that the TLS application data record 315 protocol commence immediately after the client's Finished message is 316 sent (which can be before the server's Finished message is received 317 in the case of initial TLS connections). To do this the client 318 includes the client Hello extension 'early_start' in its Hello 319 message. If the server responds with the same extension and 320 extension value in its server Hello message then the server will 321 allow the early start of the TLS application data record protocol. 323 This extension MUST NOT be used if the nature of the application data 324 to be sent early is such that the server must be authenticated to the 325 client before sending the data. For example, passwords MUST NOT be 326 sent early. 328 Note that in the case of TLS session resumption the early_start 329 feature has no effect as in that case the TLS handshake is already 330 abbreviated. Because the decision to abbreviate a TLS handshake 331 depends on client and server choices, clients that want an early 332 start of the application record protocol should use the early_start 333 extension even when requesting TLS session resumption. 335 5. Use with StartTLS-like Protocols 337 These extensions can be used in "raw TLS" and "StartTLS" application 338 protocols both. This section gives INFORMATIVE guidance to 339 application protocol developers regarding how to integrate TLS/SA 340 into their applications. 342 For example, the HyperText Transfer Protocol over TLS (HTTPS) 343 [RFC2818] is a "raw TLS" application protocol: clients initiate TCP 344 connections to servers, then they initiate TLS connections 345 immediately, then they run the application protocol (HTTP in this 346 case) over TLS. Whereas the Secure HyperText Transfer Protocol 347 (S-HTTP) [RFC2660] allows TLS to be "started" from within HTTP, at 348 which point the application protocol (HTTP) is run over TLS-over- 349 HTTP. The latter is commonly known as the "StartTLS" pattern. Other 350 examples of application protocols using raw TLS and StartTLS include 351 LDAP [RFC4511], IMAP4 [add ref], SMTP [add ref], etcetera. 353 Raw TLS applications need only use these optimizations to negotiate 354 and optimize SASL authentication, and as soon as SASL authentication 355 is complete they can begin the application protocol. We can call 356 these "raw TLS/SA" applications. 358 StartTLS applications might have performed SASL authentication before 359 starting TLS, in which case they have to redo SASL authentication. 361 StartTLS applications should treat the TLS handshake messages and any 362 subsequent SASL authentication messages as a TLS handshake messages 363 and frame them accordingly. When the TLS/SA authentication completes 364 the application should then consider the TLS handshake complete, and 365 the application may then start using the TLS record protocol for the 366 application protocol's needs. 368 6. Using TLS with the GSS-API 370 By using the SASL framework known as "GS2" [RFC5801], applications 371 can use GSS-API mechanisms as SASL mechanisms. 373 7. Using these Extensions with Existing SASL Applications 375 Applications that already use TLS and SASL can be trivially updated 376 to use the sasl_sml and early_start extensions as follows: a) 377 optimize the SASL mechanism negotiation as described in Section 3.1, 378 b) start the application data protocol early as described in 379 Section 4. Having listed the server's SASL mechanism list early the 380 application can then immediately begin authentication using its 381 preferred SASL mechanism. 383 Application protocol designers SHOULD, however, opt for the "TLS/SA" 384 profile of TLS and SASL described in Section 8. The rationale for 385 this SHOULD is that the fewer ways to combine TLS and SASL, the more 386 likely it is that developer frameworks will be produced to abstract 387 the combination for programmers. 389 Non-TLS/SA applications MUST NOT use any SASL mechanism that might 390 send credentials (passwords) in cleartext or cleartext-equivalent 391 ways before the TLS handshake completes (i.e., before the server's 392 Finished message is received and validated) unless the server has 393 already been authenticated by the TLS connection being renegotiated. 394 It is RECOMMENDED that non-TLS/SA applications use only SASL/GS2 395 [RFC5801] mechanisms using channel binding to TLS. Channel binding 396 to TLS is RECOMMENDED. 398 8. TLS/SA (TLS + SASL with generic framing of SASL authentication 399 messages) 401 Application protocols can use the sasl_sml and early_start extensions 402 to optimize SASL authentication. Each application would have to 403 provide the details of how to request SASL authentication start, how 404 to frame SASL authentication messages, and how to convey the outcome 405 of authentication to the client. A generic profile of TLS and the 406 sasl_sml and early_start extensions would allow many applications to 407 share a single TLS + SASL sub-protocol. 409 In this section we describe a generic profile of TLS and SASL 410 [RFC4422], using GS2 [RFC5801] mechanisms in TLS applications in a 411 round trip optimized manner. We call this generic profile "TLS/SA", 412 or "Transport Layer Security with Simple Authentication". TLS/SA 413 defines those parts of the SASL authentication process which SASL 414 [RFC4422] leaves to applications. 416 Existing SASL applications may, but need not use TLS/SA. New 417 application protocols that would otherwise use TLS and/or SASL SHOULD 418 use TLS/SA. 420 TLS/SA defines the framing of SASL authentication request, SASL 421 mechanism and SASL outcome of authentication messages. 423 SASL mechanism negotiation in TLS/SA is done as described in 424 Section 3.1. Channel binding to TLS is REQUIRED. The channel 425 binding type MUST be 'tls-unique'. Note that as of today there exist 426 no SASL mechanisms that support channel binding but which are not 427 SASL/GS2 mechanisms. 429 8.1. TLS/SA Exchanges 431 A client wishing to optimize a SASL/GS2 mechanism MUST: a) negotiate 432 a SASL mechanism to use using the method described in Section 3.1, b) 433 begin the SASL mechanism authentication message exchange immediately 434 after the client's Finished message as application data without 435 waiting for the server's Finished message, and using the TLS 436 connection's channel binding data for channel binding. 438 The first SASL mechanism authentication message (always sent by the 439 client in the case of SASL/GS2 mechanisms) MUST be prefixed with, and 440 in the following order: 442 1. the SASL name of the mechanism, NUL-terminated; 444 2. a NUL-terminated, possibly-empty comma-separated list of language 445 tags [RFC5646]; 447 3. a four octet, network byte order binary message length. 449 Subsequent SASL mechanism authentication messages are sent prefixed 450 with a four octet, network byte order binary message length. 452 Authentication messages MUST NOT be longer than 2^24 octets (i.e., 453 the 8 most significant bits of the message length MUST be zeros); if 454 SASL produces such messages then authentication MUST FAIL. 456 The server's "outcome of authentication exchange" message MUST 457 consist of a UTF-8 string containing supplementary information 458 prefixed with a network byte order four byte unsigned binary length 459 of of that string, with the most significant bit of the length set to 460 1. The next most significant bit MUST be 1 to indicate success, 0 to 461 indicate failure. The next most significant bit MUST be 1 to 462 indicate that authentication can be re-tried, otherwise it must be 463 set to 0, and MUST be 0 in the case of authentication success. The 464 supplementary information MUST NOT be longer than 2^16-1 bytes. The 465 supplementary information SHOULD be a human-readable message 466 localized to a language selected from the client's language tags 467 selected according to [RFC4647], or to one of the server's choice if 468 the client sent no language tags or the server did not support 469 localizations to any of them. [Question: should this message also 470 include the language tag chosen by the server? That could be done 471 using UTF-8 language tag codepoints, but IIRC those are deprecated 472 and hard to use.] 474 Where empty messages are required by SASL the application should send 475 an empty message with correspondingly set length octets. 477 If the last SASL mechanism authentication message is to be sent by 478 the server then the server's outcome of authentication message MUST 479 immediately follow the last mechanism message. That is: there is no 480 need for the client to send an empty message in response to the last 481 mechanism message just to get the outcome of authentication message. 482 This saves another round trip. 484 If authentication fails then the client MAY retry authentication, and 485 indicates this by sending four octets with all bits set, followed by 486 the first SASL authentication message of the next exchange. 487 Otherwise, the client MUST send four octets with all bits cleared 488 prior to commencing the application protocol. The server MAY abort 489 the TLS connection on authentication failure and/or re- 490 authentication. 492 If authentication succeeds then the application protocol takes over 493 the TLS record protocol contents. 495 Client Server 497 ClientHello w/ sasl_sml 498 early_start --------> 499 ServerHello w/ 500 early_start 501 sasl_sml 502 Certificate* 503 ServerKeyExchange* 504 CertificateRequest* 505 <-------- ServerHelloDone 506 Certificate* 507 ClientKeyExchange 508 CertificateVerify* 509 [ChangeCipherSpec] 510 Finished 511 SASL auth message as data --------> 512 [ChangeCipherSpec] 513 Finished 514 SASL auth message 515 <-------- Outcome of SASL 516 authentication 517 Application Data <-------> Application Data 519 Figure 4: Message flow for initial TLS connections with a one-round- 520 trip SASL mechanism for authentication 522 Client Server 524 ClientHello w/ sasl_sml 525 early_start --------> 526 ServerHello w/ 527 early_start 528 sasl_sml 529 [ChangeCipherSpec] 530 <-------- Finished 531 Certificate* 532 ClientKeyExchange 533 CertificateVerify* 534 [ChangeCipherSpec] 535 Finished 536 SASL auth message as data --------> 537 SASL auth message 538 <-------- Outcome of SASL 539 authentication 540 Application Data <-------> Application Data 542 Figure 5: Message flow for session resumption TLS connections with a 543 one-round-trip SASL mechanism for authentication 545 Client Server 547 ClientHello w/ sasl_sml 548 early_start --------> 549 ServerHello w/ 550 early_start 551 sasl_sml 552 Certificate* 553 ServerKeyExchange* 554 CertificateRequest* 555 <-------- ServerHelloDone 556 Certificate* 557 ClientKeyExchange 558 CertificateVerify* 559 [ChangeCipherSpec] 560 Finished 561 SASL auth message as data --------> 562 [ChangeCipherSpec] 563 Finished 564 <-------- SASL auth message 565 SASL auth message --------> 566 <-------- Outcome of SASL 567 authentication 568 Application Data <-------> Application Data 570 Figure 6: Message flow for initial TLS connections with one and a 571 half round-trip SASL mechanisms for authentication 573 And with a two round trip mechanism the protocol looks like: 575 Client Server 577 ClientHello w/ sasl_sml 578 early_start --------> 579 ServerHello w/ 580 early_start 581 sasl_sml 582 Certificate* 583 ServerKeyExchange* 584 CertificateRequest* 585 <-------- ServerHelloDone 586 Certificate* 587 ClientKeyExchange 588 CertificateVerify* 589 [ChangeCipherSpec] 590 Finished 591 SASL auth message as data --------> 592 [ChangeCipherSpec] 593 Finished 594 <-------- SASL auth message 595 SASL auth message --------> 596 SASL auth message 597 <-------- Outcome of SASL 598 authentication 599 Application Data <-------> Application Data 601 Figure 7: Message flow for initial TLS connections with two round- 602 trip SASL mechanisms for authentication 604 The reader can figure out what the protocol looks like for SASL 605 mechanisms with more than two round trips from the above.. 607 9. Channel Binding 609 Existing TLS channel binding types that are suitable for use with 610 SASL in this facility are: 612 o tls-server-end-point [RFC5929] 614 o tls-unique [RFC5929] 616 See [RFC5929] and the IANA channel binding type registry for more 617 information about these channel binding types. TLS/SA applications 618 MUST use the 'tls-unique' channel binding type. 620 10. Application Control of Authentication and Applicability of TLS/SA 622 Applications that should best be able to make use of these extensions 623 to optimize authentication are those where clients can be expected to 624 know a priori that authentication will be required. For example: 625 LDAP, SMTP, IMAP4, XMPP and non-browser HTTP applications. 627 TLS/SA is inapplicable to applications where decisions about when 628 authentication is required are made in context-specific manners by 629 the application, rather than by the TLS layer. Web browser-based 630 HTTP applications are a good example of this. For such applications 631 TLS/SA will not be usable, either at all or without HTTP extensions 632 that allow the server application to indicate that authentication is 633 required, letting the client re-try. Moreover, for applications that 634 make multiple short-lived TLS connections there is the need to bind 635 each TLS connection in an "application session" to the initial 636 authentication, and we do not provide a method for doing this other 637 than to authenticate each TLS connection. Different methods of 638 applying SASL/GSS-API authentication mechanisms will be needed for 639 web applications. 641 Even where full TLS/SA is not applicable, the sasl_sml extension can 642 be used to pre-negotiate SASL mechanisms in case that the application 643 later decides that SASL authentication is required. 645 11. Contrived Examples of Non-SASL Optimizations of Existing 646 Application Protocols 648 In this section and its sub-sections we INFORMATIVELY describe how a 649 number of existing TLS application protocols might be modified to 650 take advantage of the application data extension for optimization of 651 the application protocol. Implementors MUST NOT implement anything 652 described in this section, except for experimental purposes only. 654 It is crucial that clients only use the app_hello Hello extension for 655 operations that do not require that the user already be authenticated 656 (the server application MUST reject such uses of app_hello) or that 657 require privacy protection. There are likely no operations in IMAP 658 and POP3, for example, which are suitable for optimization via 659 app_hello, but there are for SMTP and LDAP. That's because IMAP and 660 POP3 deal exclusively with user data, while SMTP and LDAP have some 661 operations or objects which can be executed publicly and without user 662 authentication (see below). 664 By starting the application protocol early these applications can 665 obtain a similar round-trip optimization as for SASL in the TLS/SA 666 case. 668 11.1. Contrived Example: LDAP 670 In the case of LDAP the app_hello extension could be used to send a 671 single LDAP message, typically a search for the root DSE object. If 672 the server supports this extension then the server's app_hello Hello 673 extension can be used to return the result. If the server does not 674 support this extension then the client can repeat its search after 675 the TLS handshake is completed. 677 LDAP applications could also use an early_start request with value 678 app_protocol and begin the LDAP protocol early. If the first 679 operation performed were an LDAP Bind then the application will 680 obtain the same round-trip optimization that we get for SASL using 681 TLS/SA. 683 11.2. Contrived Example: SMTP 685 Clients could use the app_hello Hello extension to send a EHLO SMTP 686 command to the server, and the server may send the SMTP reply to it 687 in a app_hello Hello extension. 689 12. Impact on TLS Concentrators 691 This protocol is designed to have minimal impact on TLS server-side 692 proxies (a.k.a. concentrators). 694 The minimal changes to make to TLS concentrators in order to support 695 this protocol are: 697 o Add a configuration parameter through which the administrator may 698 list the SASL mechanisms available to the application servers 699 behind the concentrator; 701 o Add support for sasl_sml Hello extension, using the server SASL 702 mechanism list from the configuration parameter mentioned in the 703 previous item; 705 o Add a configuration parameter through which the administrator may 706 indicate whether the application supports the 'generic-sasl' 707 framing defined in Section 8. 709 o Add support for early_start, which means that the concentrator 710 MUST NOT consider it an error to receive TLS application data 711 record messages prior to sending the concentrator's Finished 712 message. 714 Implementors may also want to add support for unique channel binding 715 types, such as the 'tls-unique' channel binding type. This requires 716 being able to communicate to the application server the tls-unique 717 channel binding for each TLS connection, probably via an out of band 718 mechanism (though if the application protocol is HTTP then perhaps 719 the concentrator could use an HTTP request header to do this). 721 Implementors may also add a way to communicate app_hello Hello 722 extension to the application. 724 13. IANA Considerations 726 By the time this document is published, the values for the 'sasl_sml' 727 and 'early_start' TLS Hello extensions will be assined by the IANA. 728 The ExtensionType registry will have to be updated to reflect these 729 assignments. (These registries require IETF Consensus.) 731 14. Security Considerations 733 The security considerations of [RFC4422], [RFC5246] and [RFC5056] 734 apply, as do those of [RFC2743] when used via the SASL/GS2 bridge 735 [RFC5801]. Additionally, this document has security consideration 736 information throughout. 738 Needless to say, TLS applications that make use of TLS renegotiation 739 should ensure that they use the TLS renegotiation indication 740 extension [RFC5746]. 742 The initial SASL authentication message should not be considered 743 protected by TLS until the TLS handshake completes. If a TLS cipher 744 suite is used that does not authenticate the server, but a SASL 745 mechanism is used that does authenticate the server, then the SASL 746 exchanges should not be considered protected until authentication 747 completes and succeeds. Channel binding MUST be used in the 748 optimized authentication case (but then, channel binding should 749 always be used when SASL is used over TLS). 751 Non-SASL early_start application data should not be considered 752 protected by TLS until the TLS handshake completes. 754 The SASL mechanism negotiation and app_hello data should not be 755 considered protected by TLS until the TLS handshake completes, and, 756 if the application uses SASL, should not be considered protected 757 until SASL authentication completes successfully. 759 15. References 761 15.1. Normative References 763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, March 1997. 766 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 767 Security Layer (SASL)", RFC 4422, June 2006. 769 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 770 BCP 47, RFC 4647, September 2006. 772 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 773 Channels", RFC 5056, November 2007. 775 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 776 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 778 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 779 Languages", BCP 47, RFC 5646, September 2009. 781 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 782 "Transport Layer Security (TLS) Renegotiation Indication 783 Extension", RFC 5746, February 2010. 785 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 786 Service Application Program Interface (GSS-API) Mechanisms 787 in Simple Authentication and Security Layer (SASL): The 788 GS2 Mechanism Family", RFC 5801, July 2010. 790 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 791 for TLS", RFC 5929, July 2010. 793 15.2. Informative References 795 [RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText 796 Transfer Protocol", RFC 2660, August 1999. 798 [RFC2743] Linn, J., "Generic Security Service Application Program 799 Interface Version 2, Update 1", RFC 2743, January 2000. 801 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 803 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 804 (LDAP): The Protocol", RFC 4511, June 2006. 806 Author's Address 808 Nicolas Williams 809 Oracle 810 5300 Riata Trace Ct 811 Austin, TX 78727 812 US 814 Email: Nicolas.Williams@oracle.com