idnits 2.17.1 draft-nystrom-http-sasl-12.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 3667, Section 5.1 on line 1859. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1895. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1887), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 32. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 44 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 45 pages -- Found 45 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2616], [RFC2222]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RC2222' is mentioned on line 1510, but not defined == Missing Reference: 'SASL' is mentioned on line 1724, but not defined == Unused Reference: 'RFC2026' is defined on line 1782, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 1830, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2831 (Obsoleted by RFC 6331) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) -- No information found for draft-ietf-sasl-saslprep-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLPrep' -- No information found for draft-ietf-sasl-rfc2222bis-XX - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2829 (Obsoleted by RFC 4510, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) Summary: 20 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Magnus Nystrom 2 July, 2004 RSA Security 3 Expires: January, 2005 Alexey Melnikov 4 Intended category: Standards track Isode Ltd. 6 SASL in HTTP/1.1 8 draft-nystrom-http-sasl-12.txt 10 Status of this Memo 12 By submitting this Internet-Draft, we certify that any applicable 13 patent or other IPR claims of which we are aware have been disclosed, 14 or will be disclosed, and any of which we become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This memo suggest the use of SASL [RFC2222] as a framework to enable 37 the use of strong authentication mechanisms in HTTP/1.1 [RFC2616], 38 and describes one approach to accomplish this. 40 Please send comments on this document directly to authors or to the 41 relevant mailing lists, e.g. ietf-sasl@imc.org. 43 Table of contents 45 1 Conventions used in this memo ... ......................... 3 46 2 Introduction .............................................. 4 47 2.1 The HTTP/1.1 challenge-response framework ................ X 48 3 Relationship with the HTTP/1.1 specification .............. X 49 4 SASL framework ............................................ 4 50 4.1 Introduction and examples ................................ X 51 4.1.1 Introduction ........................................... X 52 4.1.2 Example sequence diagrams .............................. X 53 4.2 SASL authentication scheme ............................... X 54 4.2.1 Recognition of the scheme .............................. X 55 4.2.2 SASL authentication response header sent by server ..... X 56 4.2.3 SASL authorization request header sent by client ....... X 57 4.3 Usage model .............................................. X 58 4.3.1 SASL handshake initiation .............................. X 59 4.3.2 Client response ........................................ X 60 4.3.3 Server behavior upon receiving a "SASL" 61 token ................................................. XX 62 4.3.4 Client behavior upon receiving a "SASL" 63 token ................................................. XX 64 4.3.5 Subsequent requests ................................... XX 65 4.3.6 Client aborting a handshake ........................... XX 66 4.3.7 Pipelining considerations ............................. XX 67 4.3.8 Caching considerations................................. XX 68 4.3.9 "Web farm" considerations ............................. XX 69 4.3.10 HTTP header and state management ..................... XX 70 4.4 Request/response encoding ............................... XX 71 4.4.1 SASL challenge/response encoding ...................... XX 72 4.4.2 Security layer......................................... XX 73 4.4.3 Interaction with TLS................................... XX 74 4.4.4 Mandatory to implement SASL mechanism.................. XX 75 4.5 Status codes and error handling ......................... XX 76 4.5.1 HTTP/1.1 status codes.................................. XX 77 4.5.2 Client error handling.................................. XX 78 4.6 Authorization identity .................................. XX 79 4.7 Examples ................................................ XX 80 4.7.1 Example 1 - Server requires authentication ............ XX 81 4.7.2 Example 2 - Initial response .......................... XX 82 4.7.3 Example 3 - One mechanism only ........................ XX 83 4.7.4 Example 4 - Server sends additional data .............. XX 84 4.7.5 Example 5 - Abort ..................................... XX 85 4.7.6 Example 6 - Client requires authentication ............ XX 86 4.7.7 Example 7 - Client requires authentication, server 87 supports multiple realm ............................... XX 88 4.7.8 Example 8 - Client uses POST request .................. XX 89 4.7.9 Example 9 - Client authentication fails ............... XX 90 4.8 Interoperability with existing HTTP/1.1 clients and 91 servers ................................................. XX 92 4.9 Preferences ............................................. XX 93 4.10 SASL mechanism recommendations ......................... XX 94 5 IANA considerations ...................................... XX 95 5.1 GSSAPI/SASL service name ................................ XX 96 5.2 HTTP/1.1 Status codes ................................... XX 97 6 Security considerations .................................. XX 98 6.1 Introduction ............................................ XX 99 6.2 Active attacks .......................................... XX 100 6.2.1 Man-in-the-middle ..................................... XX 101 6.2.2 Denial of service ..................................... XX 102 6.2.3 Replay ................................................ XX 103 6.3 Passive attacks ......................................... XX 104 6.4 Protecting the body of POST/PUT requests ................ XX 105 6.5 Other considerations .................................... XX 106 7 Implementation considerations (informative)............... XX 107 7.1 The SASL authentication exchange context ................ XX 108 7.2 SASL security layer handling ............................ XX 109 7.3 SASL Profile Checklist .................................. XX 110 8 Acknowledgements ......................................... XX 111 9 References ............................................... XX 112 9.1 Normative references .................................... XX 113 9.2 Informative references .................................. XX 114 10 Authors' addresses ...................................... XX 115 11 IPR Disclosure Acknowledgement .......................... XX 116 12 Intellectual Property Statement ......................... XX 117 13 Full Copyright Statement ................................ XX 118 Appendix A. Changes since previous revisions ................ XX 120 1 Conventions used in this memo 122 The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in 123 this document are to be interpreted as defined in "Key words for use 124 in RFCs to Indicate Requirement Levels" [RFC2119]. 126 General understanding of SASL [RFC2222] is required before reading of 127 this document. [RFC2222] defines several terms used through out this 128 document, in particular "authorization identity" and "security 129 layer". 131 In the examples, "C:" and "S:" indicate lines sent by a client and a 132 server respectively; "CP:" and "SP:" indicate lines sent by a client 133 and a server respectively with a SASL security layer active. 135 2 Introduction 137 The Hypertext Transfer Protocol, HTTP/1.1 [RFC2616], supports only 138 two authentication schemes, namely the "Basic Access Authentication 139 Scheme" and the "Digest Access Authentication Scheme" [RFC2617]. 140 Neither of these can be considered to be strong authentication 141 schemes. The former is extremely insecure unless used in conjunction 142 with a lower-level protocol offering security services, since it 143 sends cleartext passwords. The latter is an improvement, but is still 144 vulnerable to man-in-the-middle attacks. 146 The Simple Authentication and Security Layer (SASL [RFC2222]) 147 provides a method for adding authentication and security services to 148 connection-oriented protocols in a flexible manner, enabling a 149 variety of authentication and security mechanisms (e.g. mechanisms 150 based on one-time-passwords, public key technology or password-based 151 public-key cryptography), and also a flexible means to negotiate 152 these mechanisms subject to local policies and security requirements. 153 This memo therefore suggests a method to use SASL in HTTP/1.1 and 154 solicit comments on the suggested approach. 156 This document is using the HTTP/1.1 challenge-response framework to 157 implement SASL in HTTP/1.1. The challenge-response framework is 158 outlines in Section 2.1. 160 2.1 The HTTP/1.1 challenge-response framework 162 HTTP/1.1 provides a simple challenge-response mechanism that can be 163 used by a server or proxy to challenge a client request and by a 164 client to provide authentication information. The reader is referred 165 to [RFC2616] and [RFC2617] for a more detailed description of this 166 mechanism. The relevant ABNF productions are: 168 challenge = auth-scheme 1*SP 1#auth-param 170 auth-scheme = token 172 auth-param = token "=" (token | quoted-string) 174 The challenge will be found in a WWW-Authenticate or a Proxy- 175 Authenticate header field. 177 The client response, containing the client's credentials is defined 178 as follows: 180 credentials = auth-scheme 1*SP 1#auth-param 182 The response will be found in an Authorization or a Proxy- 183 Authorization header field. 185 3 Relationship with the HTTP/1.1 specification 187 This memo relies on the HTTP/1.1 [RFC2616] specification. As with RFC 188 2616, it uses the ABNF [RFC2234] grammar of that document and relies 189 on both non-terminals and other aspects of it. 191 Further, this memo REQUIRES persistent connections whenever a SASL 192 security layer (see Section 4.4.2) is negotiated. Note, that a SASL 193 security layer is an optional (to negotiate) feature of SASL, 194 however, once negotiated it can't be turned off (or not used), until 195 a subsequent reauthentication completes successfully on the same TCP 196 connection. It is also RECOMMENDED to use a persistent connection 197 while performing a SASL authentication exchange. See also Section 198 4.3.10 for additional discussions of this issue. 200 4 SASL framework 202 4.1 Introduction and examples 204 4.1.1 Introduction 206 The SASL protocol itself is relatively straightforward. It consists 207 of a number of exchanges between the client and the server. 208 Typically, the initial exchange negotiates the authentication 209 mechanism and then remaining exchanges actually authenticate the 210 client to the server. 212 The following figure shows, in schematic fashion a typical SASL 213 authentication handshake which authenticates the client using the 214 CRAM-MD5 mechanism. See Section 4.7.1 for the detailed example on how 215 this will look in HTTP. 217 Client Server 218 ------ ------ 219 <- Please authenticate, I speak 220 CRAM-MD5, GSSAPI, and 221 DIGEST-MD5 223 I choose CRAM-MD5 -> 225 <- Go ahead, your challenge 226 is "abcdef" 228 I am user "user8", and -> 229 my response is 230 "0123456789ABCDEF" 232 <- Ok user "user8", your are 233 authenticated. 235 Note that other mechanisms may require a larger number of round 236 trips. 238 This document describes how to use SASL as an authentication 239 mechanism for HTTP. Standard HTTP authentication headers are used, 240 but they contain SASL data. SASL messages sent by the client are 241 carried in the Authorization header. SASL messages sent by the server 242 are carried in the WWW-Authenticate header. 244 4.1.2 Example sequence diagrams 246 Server initiated authentication: 248 Client Server 250 ----------------- Initial Request -----------------------> 252 <------ 401 WWW-Authenticate SASL (mechanisms,realm,id) -- 254 --- Authorization (mechanism,id[,realm]) ----------------> 256 <------ 401 WWW-Authenticate SASL (id,challenge) --------- 258 --- Authorization (id,credential)------------------------> 260 [ 261 <------ 401 WWW-Authenticate SASL (id,challenge) --------- 263 --- Authorization (id,credential)------------------------> 265 ](0 or more times depending on the SASL mechanism) 267 <------ 235 WWW-Authenticate SASL (id) ------------------- 269 ----------------- Initial Request (retry) ---------------> 271 <------ 200 Server performs the requested operation ------ 273 Client initiated authentication: 275 Client Server 276 --- OPTIONS request with Authorization ([realm]) --------> 278 <------ 401 WWW-Authenticate SASL (mechanisms,realm,id) -- 280 --- Authorization (mechanism,id) ------------------------> 282 <------ 401 WWW-Authenticate SASL (id,challenge) --------- 284 --- Authorization (id,credential)------------------------> 286 [ 287 <------ 401 WWW-Authenticate SASL (id,challenge) --------- 289 --- Authorization (id,credential)------------------------> 291 ](0 or more times depending on the SASL mechanism) 293 <------ 235 WWW-Authenticate SASL (id) ------------------- 295 ----------------- Initial Request -----------------------> 297 <------ 200 Server performs the requested operation ------ 299 <> 301 4.2 SASL authentication scheme 303 4.2.1 Recognition of the scheme 305 A server MUST use the auth-scheme token "SASL" if it supports SASL 306 and is willing to perform authentication using a SASL-based 307 mechanism. 309 4.2.2 SASL authentication response header sent by server 311 For the "SASL" , the authentication response header is 312 as follows: 314 challenge = SASL 1*SP sasl-response-parameters 316 sasl-response-parameters 317 = [sasl-mechanisms WSAC] [realm WSAC] sasl-sid 318 [WSAC sasl-challenge] [WSAC sasl-status] 319 [WSAC http-authzid] 321 sasl-mechanisms = "mechanisms" "=" <"> 1#sasl-mech-name <"> 322 realm = "realm" "=" quoted-string 323 ; See RFC 2617 325 sasl-sid = "id" "=" quoted-string 327 sasl-challenge = "challenge" "=" <"> base64-string <"> 329 sasl-status = "status" "=" quoted-string 331 http-authzid = "http-authzid" "=" sasl-authzid 333 sasl-authzid = <"> URI <"> 334 ; Usually a URI using the "http" scheme. 335 ; URI is defined in [RFC2396] 337 sasl-mech-name = 1*20 SASLCHAR 338 ; Name must be from IANA set of registered SASL mechanisms, 339 ; e.g. "SECURID" 341 base64-string = *base64-group [base64-fingroup] 342 ; Encoding must be in accordance with Section 3 of [RFC3548], 343 ; except not limited to 76 chars/line. 344 ; Spaces are not allowed. 346 base64-group = 4*BASE64 348 base64-fingroup = 4*BASE64 | (3*BASE64 "=") | (2*BASE64 "==") 350 SASLCHAR = UPALPHA | DIGIT | "-" | "_" 351 ; Characters allowed in SASL mechanism name 353 BASE64 = DIGIT | ALPHA | "+" | "/" 355 WSAC = *LWS "," *LWS 357 Note: All directives ("mechanisms", "id", "realm", "challenge", etc.) 358 are case-insensitive. All directive values are case-sensitive. 360 The meanings of the values of the directives used above are as 361 follows: 363 sasl-mechanisms 364 A list of registered SASL mechanisms acceptable to the 365 server. MUST be sent by the server unless a mechanism already has 366 been agreed upon (see example 2 in Section 4.7.2). A server should 367 list supported SASL mechanisms in its preferred order - from the 368 most preferred to the least preferred. However a client MUST NOT 369 blindly trust the order of the mechanisms in the received 370 sasl-mechanisms directive. The client must enforce own mechanism 371 selection policy first, e.g. "only use mechanisms that provide 372 mutual authentication", and only use the order specified by the 373 server if everything else is equal. 375 realm 376 As defined in [RFC2617]. The directive MUST be present in initial 377 challenges and when the realm otherwise would not be known by the 378 client. 380 sasl-sid 381 A session identifier identifying a particular SASL authentication 382 exchange (handshake) context (see also Section 7.1). MUST always be 383 present. Sasl-sids are chosen by the server and at any given point 384 in time MUST be unique for each established connection. 386 sasl-challenge 387 A Base64-encoded challenge (or server credentials, at the end 388 of an authentication exchange) in accordance with a selected SASL 389 mechanism. MUST NOT be sent unless there is exactly one SASL 390 mechanism in the directive. 392 sasl-status 393 A string indicating the resulting status of a SASL authentication 394 exchange. For this version of this profile, this parameter is only 395 used when client authentication has failed, in which case the 396 parameter's value shall be "failed" (see further Section 4.3.3). 398 http-authzid 399 Upon successful authentication the server MAY (and if the client 400 specified options="http-authzid" the server MUST) return the 401 resulting protocol-specific authorization identifier for the 402 authenticated client. The returned identifier informs the client of 403 the established HTTP/1.1 authorization identity. 405 4.2.3 SASL authorization request header sent by client 407 For the SASL scheme, the authorization request header is as follows: 409 credentials = SASL [1*SP sasl-request-parameters] 411 sasl-request-parameters 412 = [sasl-mechanism WSAC] [sasl-sid WSAC] 413 [realm WSAC] [sasl-options WSAC] [sasl- 414 credentials] 416 sasl-mechanism = "mechanism" "=" <"> sasl-mech-name <"> 417 sasl-credentials = "credentials" "=" 418 <"> (base64-string <"> | cancel-token) <"> 420 sasl-options = "options" "=" <"> 1#token <"> 422 cancel-token = "*" 424 The meanings of the values of the directives used above are as 425 follows: 427 sasl-mechanism 428 A SASL mechanism acceptable to the client, chosen from the list 429 provided by the server or set by some configuration. MUST be sent 430 by the client unless a mechanism already has been agreed upon. 432 sasl-sid 433 A session identifier identifying a particular SASL authentication 434 exchange context, previously set by a server. MUST always be sent 435 by 436 the client except for the case of "initial responses," see Section 437 4.3.1 below. 439 realm 440 As defined in [RFC2617]. MUST always be sent by the client unless 441 the realm is possible to determine by other means. 443 sasl-credentials 444 Base64-encoded credentials in accordance with a selected SASL 445 mechanism, or a ("*"). MUST be sent if a 446 directive has been received by the client. 448 sasl-options 449 Allows the client to request SASL specific options. Currently 450 only a single option "http-authzid" is defined. Sending of the 451 "http-authzid" option instructs the server to return a 452 directive upon successful authentication (see also 453 Section 4.2.2). The "http-authzid" option MUST only be sent in the 454 request in which the client selects the authentication mechanism to 455 be used. Other options may have other restrictions. 457 4.3 Usage model 459 4.3.1 SASL handshake initiation 461 4.3.1.1 Server initiated authentication 463 When a client makes a request for a resource on a server that 464 requires SASL-based authentication, the server MUST respond with a 465 401 - Unauthorized (407 - Proxy Authentication Required) response 466 including a WWW-Authenticate (or Proxy-Authenticate) header field 467 that contains a "SASL" . 469 The server MUST list all supported and acceptable SASL mechanisms in 470 the directive. If the server only supports one SASL 471 mechanism, it MAY include a directive in order to 472 reduce the number of roundtrips (see the example in Section 4.7.3). 473 The server MUST include a directive to identify the 474 particular authenticaton exchange context. This value MUST be the 475 same for all messages associated with that authentication exchange. 477 Further, the server MUST include a directive in accordance 478 with [RFC2617], however if a particular SASL mechanism defines its 479 own "realm" as a part of its authentication exchange, the mechanism 480 specific version of "realm" MUST be used by the mechanism. 482 If the server supports multiple realms for the requested resource, it 483 MUST return multiple SASL challenges formatted as described above, 484 each including different s (and potentially different s for different realms). 487 The server MAY also return additional challenges if Basic and/or 488 Digest [RFC2617] access authentication is supported for the requested 489 resource. 491 4.3.1.2 Client initiated authentication 493 A client, which is about to issue a request to a server, and knows 494 that the server requires a certain SASL mechanism, MAY include a a 495 "SASL" token in an Authorization (or Proxy- 496 Authorization) header field in its request. If the client chooses to 497 do so, it MUST include a directive identifying the 498 used SASL mechanism, but MUST NOT include a directive, as 499 session identifiers are chosen by the server. The client MAY also 500 specify a directive (if it is known) and a 501 directive in the request. If the chosen SASL mechanism requires that 502 the client sends data first, the client MUST also include a directive, c.f. the "initial response" in [RFC2222] (see 504 also the example in Section 4.7.2). This minimizes the number of 505 roundtrips, since otherwise the server would be required to send an 506 empty challenge. 508 If the client requires authentication, but doesn't know which 509 mechanisms are supported by the server, the client SHOULD issue an 510 OPTIONS request that includes a Request-URI header for the desired 511 resource and an Authorization (or Proxy-Authorization) header field 512 containing a "SASL" token that MAY contain , but 513 MUST NOT contain any of the , or directives. This provides a way for the client to query 515 the server about supported SASL mechanisms for the requested 516 resource. 518 This document REQUIRES that a compliant SASL-aware server handles an 519 OPTIONS request with the "SASL" token described in the 520 previous paragraph by listing all supported and acceptable SASL 521 mechanisms in the directive in the WWW-Authenticate 522 (or Proxy-Authenticate) header field as described in Section 4.3.1.1. 523 When replying to OPTIONS request the server SHALL use the 401 - 524 Unauthorized (407 - Proxy Authentication Required) response, if the 525 requested resource requires client authentication. <> The server SHALL use the 200 - OK response, 528 if unauthenticated users are allowed to see the resource. In both 529 cases, the presense of the WWW-Authenticate (or Proxy-Authenticate) 530 header field containing "SASL" signifies that SASL 531 authentication is supported for the requested resource; the absence 532 of any WWW-Authenticate (or Proxy-Authenticate) header field with 533 "SASL" signifies that SASL authentication is not 534 supported for the requested resource. For example, the server SHALL 535 use the 200 - OK response including a WWW-Authenticate (or Proxy- 536 Authenticate) header field with "SASL" , if 537 unauthenticated users are allowed to see the resource and SASL 538 authentication is supported for the resource. See also an example in 539 Section 4.7.6. 541 <> 543 If the client has specified a wrong value (i.e. a 544 value that is not recognized by the server or a value that 545 doesn't control access to the requested resource) or has not provided 546 any value and the server supports multiple realms for the 547 requested resource, than the server MUST ignore data sent in the 548 client's request and respond with a 401 - Unauthorized (407 - Proxy 549 Authentication Required) response containing multiple SASL challenges 550 formatted as described in section 4.3.1.1, each SASL challenge 551 including different s. The client can than select a proper 552 value and retry the authentication request. See also example 553 in Section 4.7.7. 555 4.3.2 Client response 557 A client, which receives a "SASL" authentication 558 response token containing the directive in a WWW- 559 Authenticate (Proxy-Authenticate) header in a 401 - Unauthorized (407 560 - Proxy Authentication Required) response, examines the list of the 561 available SASL mechanism found in the directive. If 562 the client can't find a supported and otherwise appropriate (for 563 accessing the resource) SASL mechanism (see also note below), it MUST 564 NOT continue the authentication exchange using a SASL mechanism not 565 on the provided list. If no acceptable SASL mechanism is found, the 566 client MAY try Digest and/or Basic authentication [RFC2617]. <> If 568 the client has found an acceptable SASL mechanism, it constructs a 569 new request as described below. This request MAY contain the headers 570 from the original request, MUST contain an Authorization (Proxy- 571 Authorization) header containing a "SASL" token, but 572 SHOULD NOT contain the body of the original request (if any). We will 573 reference any such request as a "SASL request". The purpose of SASL 574 requests is to avoid sending the body of a request with each 575 authentication step. 577 Note: In cases where the 401 - Unauthorized (407 - Proxy 578 Authentication Required) response also contains a WWW-Authenticate 579 (Proxy-Authenticate) header with a "Basic" and/or a "Digest" token, the selected authentication scheme will be subject to 581 local client policy. Clients are RECOMMENDED never to select Basic 582 authentication over any other server-suggested method. 584 The "SASL" token in the SASL request MUST include the 585 value provided by the server and a 586 directive with the chosen SASL mechanism name. If the chosen 587 mechanism allows for "initial response" type messages, the client 588 MUST also include the initial response in a 589 directive. If the client is transmitting an initial response of zero 590 length, it MUST transmit the response as the empty token (i.e. 591 credentials=""). This indicates that the response is present, but 592 contains no data. The client MAY also include a 593 directive. 595 If the client is able and willing to negotiate a SASL security layer, 596 it MUST establish an end-to-end tunnel using the CONNECT method as 597 described in Section 5.3 of [RFC2817] before starting an 598 authentication exchange. The Authorization header MUST NOT be used in 599 a CONNECT request. However, in order to save round trips, a Proxy- 600 Authorization header MAY be used in a CONNECT request. 602 Note: A direct connection (any intermediate proxies operating in 603 tunnel mode) is required whenever a security layer is in effect, 604 since at that point complete HTTP/1.1 messages may be encrypted. 606 When two or more authentication exchanges are performed in parallel 607 on the same connection ("mixed"), the client MUST NOT negotiate a 608 security layer on more than one of them. Multiple 609 directives SHOULD NOT be "mixed" on the same connection, except for 610 the case when a client starts an authentication exchange with the 611 target server and an intervening proxy server asks the client to 612 authenticate to it first. In this case, the client must perform an 613 authentication exchange to the proxy first and then resume 614 authentication to the end server. 616 The following diagram demonstrates a "mixed" authentication exchange: 618 Client Server 620 ----------- Start Authentication Exchange 1 -------------> 622 <--------- Reply to Authentication Exchange 1 ------------ 624 ----------- Start Authentication Exchange 2 -------------> 626 <--------- Reply to Authentication Exchange 2 ------------ 628 ----------- Continue Authentication Exchange 1 ----------> 630 If the client receives a "SASL" authentication response 631 token containing a directive in a WWW-Authenticate 632 (Proxy-Authenticate) header for a 401 - Unauthorized (407 - Proxy 633 Authentication Required) response, the client should behave as 634 described in Section 4.3.4. 636 4.3.3 Server behavior upon receiving a "SASL" token 638 If the token contains a directive, then the 639 server MUST check if the SASL authentication exchange context 640 identified by is valid. If it is not, the server SHALL 641 reply with a 401 - Unauthorized (407 - Proxy Authentication Required) 642 response, that contains a new value and the session 643 continues as described in Section 4.3.1.1, i.e. the server MUST list 644 all supported and acceptable SASL mechanisms in the 645 directive. 647 If the token contains a directive, the 648 server MUST check if it mechanism is acceptable. If it is not, the 649 server MUST reply with a 450 - "Authentication mechanism not 650 accepted" response and, if the request included a 651 directive, delete the SASL authentication context identified by the 652 . 654 If the token contains a directive, 655 the server MUST check if the supplied credentials authenticates the 656 client. If the directive contains a then the server MUST reject the exchange with a 401 - 658 Unauthorized reply. 660 Otherwise, the server uses the value of directive 661 to check if the client is authenticated. If the client is not (yet) 662 authenticated, the server uses the supplied credential value to 663 calculate a new as per the currently selected SASL 664 mechanism. If the new is successfully calculated, it 665 is returned in the WWW-Authenticate (or Proxy-Authenticate) header of 666 a new 401 - Unauthorized (407 - Proxy Authentication Required) 667 response. 669 If the client authentication failed, the server SHALL reply with a 670 401 - Unauthorized (407 - Proxy Authentication Required) response 671 containing a WWW-Authenticate (or Proxy-Authenticate) header 672 containing a "SASL" authentication token with exactly 673 two directives: and . The value 674 for the directive shall be "failed". When receiving a 675 message with a WWW-Authenticate (Proxy-Authenticate) header of this 676 type, the client shall interpret the response in accordance with 677 Section 10.4.2 of [RFC2616]. For an example of this, see Section 678 4.7.9. 680 Note: This method of conveying information about a failed 681 authentication differs slightly from that defined in [RFC2616]. The 682 reason for this discrepancy is twofold: There may be SASL methods for 683 which two consecutive challenges are identical, and the method 684 defined in 10.6.2 of [RFC2616] was not designed for multiple-step 685 authentication exchanges. 687 Whenever an authentication exchange fails, both the client and the 688 server MUST return to their previous authentication state, i.e. as if 689 the authentication attempt never took place. 691 The server MAY also choose to reply with a 432 - Transition Needed 692 response, which indicates that the user name is valid, but the entry 693 in the authentication database needs to be updated in order to permit 694 authentication with the specified SASL mechanism. A client, which 695 receives a 432 - Transition Needed response, MAY retry authentication 696 using the SASL PLAIN mechanism. This SHOULD NOT be done unless an 697 appropriate TLS protection is in place. An interactive client MUST 698 NOT perform PLAIN authentication automatically and MUST warn the user 699 before proceeding. 701 If the client is authenticated, the server MUST at least include the 702 directive with its "SASL" authentication 703 response token. If the chosen SASL mechanism requires that further 704 challenge/response data (i.e. "server returns success with additional 705 data" in [RFC2222]) be sent by the server, the server MUST respond 706 with a 401 - Unauthorized (407 - Proxy Authentication Required) 707 response containing a directive with its "SASL" 708 authentication response token in a WWW-Authenticate (or 709 Proxy-Authenticate) header. Unless the server fails authentication, 710 the client MUST reply to this with a new SASL request containing an 711 Authorization header with a directive and an empty directive. The server will reply to this with a 235 - 713 Authentication Completed (236 - Proxy Authentication Completed) 714 response and at this point authentication is complete, and a SASL 715 security layer may take effect (see Section 4.4.2). 717 If the client is authenticated and the server does not need to send 718 any further challenge information, the server replies with a 235 - 719 Authentication Completed (236 - Proxy Authentication Completed) 720 response. 722 In both cases, when the server replies with a 235 - Authentication 723 Completed (236 - Proxy Authentication Completed) response, it MAY 724 include an directive in the "SASL" 725 authentication response token. The SHALL contain the 726 authorization identity of the authenticated client in the form of a 727 URI. Note that the content of a 235 - Authentication Completed (236 - 728 Proxy Authentication Completed) response (and thus the 729 directive) is not protected by a SASL security layer. In some 730 deployments, the value of the directive may also 731 contain confidential information which might require privacy 732 protection. 734 Upon receipt of a 235/236 response the client shall consider 735 authentication successful and may retry the original request (with 736 the body of the request, if any), possibly protected by a negotiated 737 security session (see Section 4.4.2). 739 4.3.4 Client behavior upon receiving a "SASL" token 741 The client, upon receipt of a "SASL" authentication 742 response token containing a directive in a WWW- 743 Authenticate (Proxy-Authenticate) header for a 401 - Unauthorized 744 (407 - Proxy Authentication Required) response, calculates its 745 credentials and responds with a new SASL request containing a 746 (possibly empty, see previous section) directive 747 and a "SASL" token in an Authorization (Proxy- 748 Authorization) header. The client repeats this until the 749 authentication exchange is successful or the server responds with a 750 401 (407) message without the SASL token (see previous 751 section). 753 4.3.5 Subsequent requests 755 The same HTTP server (host identifier) may serve data governed by 756 multiple realms that may have separate associated authentication 757 databases. If the client leaves the authentication realm it is 758 currently authenticated in, e.g. by issuing a request for a resource 759 in a different realm, the server MAY force the client to re- 760 authenticate in the new realm. In this case a new authentication 761 exchange is started as described in 4.3.1. However there is a change 762 in how the security layer is established (see Section 4.4.2). If a 763 security layer is currently active and the new authentication 764 exchange negotiates a new security layer, it MUST replace the 765 existing one. This includes the case when the new security layer is 766 the NULL layer, i.e. the connection reverts to a state where no SASL 767 security layer is present). See Section 4.4.2 for a description of 768 when the security layer is being replaced/dropped. 770 4.3.6 Client aborting a handshake 772 A client may abort a handshake by letting the value of the field consist of the , "*". For an example 774 of this, see Section 4.7.5. 776 4.3.7 Pipelining considerations 778 When pipelining multiple authentication requests (or authentication 779 requests together with other requests), the client MUST observe the 780 rules established in Section 4.4.2. This means that an authentication 781 request that completes a SASL authentication exchange and activates a 782 SASL security layer, MUST be the last request in a group of requests. 783 If this rule is not followed, the client will start sending cleartext 784 data that may be interpreted by the server as encrypted. This can 785 lead to a packet decode error on the server side and dropped 786 connections. 788 When a SASL security layer has been negotiated clients MAY put 789 multiple HTTP requests (and server may put multiple HTTP responses) 790 inside a single SASL buffer of protected data. See also Section 791 4.4.2. 793 4.3.8 Caching considerations 795 As described in [RFC2616] Section 14.8, a shared cache MUST NOT 796 return a response to a request containing an Authorization header to 797 any other requests unless special circumstances apply. To ensure that 798 these circumstances do not apply here, the server MUST send a "Cache- 799 Control: no-store" header together with the "WWW-Authenticate" header 800 in all handshake responses. 802 4.3.9 "Web farm" considerations 804 Implementation and configuration of the SASL negotiation mechanism 805 described in this memo requires special considerations in the case of 806 "web farm" environments where several servers may serve client 807 requests since authentication state information otherwise may be 808 lost. In particular, means for sharing of authentication negotiation 809 state must be available. 811 4.3.10 HTTP header and state management 813 There MUST NOT be more than one WWW-Authenticate or Proxy- 814 Authenticate header field containing a SASL authentication response 815 in any HTTP response. The WWW-Authenticate or Proxy-Authenticate 816 header MUST NOT contain more than one SASL authentication response. 818 The only exception to these rules is when the server lists available 819 SASL mechanisms and the access to the requested resource is 820 controlled by more than one realm (see section 4.3.1). 822 There MUST NOT be more than one Authorization or Proxy-Authorization 823 header field containing a SASL authorization request in any HTTP 824 request. 826 Since support for persistent connections is optional in HTTP/1.1, all 827 servers MUST implement some method for state management of SASL 828 authentication exchanges. This may include (but is not limited to) 829 session caching, session expiration, dealing with duplicated 830 authentication requests. 832 This document does not specify methods for servers to manage session 833 state once the client has been authenticated. For an example of such 834 methods, see [RFC2965]. 836 4.4 Request/response encoding 838 4.4.1 SASL challenge/response Encoding 840 The directive and the directive 841 contain SASL challenges and responses respectively. The challenges 842 and responses MUST be base64 ([RFC3548], section 3) encoded before 843 being placed in these fields. The base64 string may in general be 844 arbitrarily long. Clients and servers MUST be able to support 845 challenges and responses that are as long as are generated by the 846 authentication mechanisms they support, independent of any line 847 length limitations the client or server may have in other parts of 848 its protocol implementation. 850 Note that, as described in Section 4.3.6, instead of containing a 851 base64-encoded string, a value may consist of the 852 single "*" character, indicating to the server that the client aborts 853 the handshake. 855 4.4.2 Security layer 857 If a protection mechanism is negotiated as part of the SASL security 858 session, then it MUST be applied to all subsequent requests and 859 responses sent between the server and the client for the given realm. 860 Any negotiated security layer takes effect immediately following the 861 that concludes the authentication exchange for the 862 client, and the of 235 (236) response for the server. 863 I.e., for later requests (and responses) all data - including the 864 status line and headers - will be protected by the new security 865 layer. 867 The same rules apply in a case of reauthentication. Whenever a new 868 security layer (including the empty one) is negotiated due to 869 reauthentication, the current layer gets replaced (dropped) 870 immediately after transmission (receipt) of the 235 (236) response. 872 A client that requires a security layer MUST check, after successful 873 authentication, that such a layer indeed was negotiated. 875 Note that a security layer requires HTTP/1.1 persistent connection. 877 4.4.3 Interaction with TLS 879 A client may not perform an HTTP/1.1 "Upgrade" to TLS [RFC2817] while 880 conducting a SASL negotiation, but is free to do so after, or before, 881 the SASL negotiation takes place. 883 This document allows for both a TLS and a SASL security layer to be 884 active at the same time. No matter in which order they were 885 negotiated, any data will be transformed by the SASL security layer 886 first and then by TLS, i.e. the relevant protocol stack will be as 887 follows: 889 +---------+ 890 | HTTP | 891 +---------+ 892 | SASL | 893 +---------+ 894 | TLS | 895 +---------+ 896 | TCP | 897 +---------+ 899 4.4.4 Mandatory to implement SASL mechanism 901 In order to guarantee interoperability, all client and server 902 implementations conformant to this document MUST support the DIGEST- 903 MD5 [RFC2831] SASL mechanism. Since support for persistent 904 connections is optional in HTTP/1.1, this implies that all clients 905 and servers MUST support DIGEST-MD5 in non-persistent mode. 907 4.5 Status codes and error handling 909 4.5.1 HTTP/1.1 status codes 911 HTTP/1.1 status codes which apply to SASL-based mechanisms are: 913 -235 - Authentication Completed 914 This status code indicates that SASL authentication with the server 915 is complete and the client may retry sending the original request. 916 -236 - Proxy Authentication Completed 917 This status code indicates that SASL authentication with the proxy 918 is complete and the client may retry sending the original request. 919 -401 - Unauthorized 920 An HTTP/1.1 server will use this status code when credentials 921 supplied by a client could not be validated, in addition to the use 922 described in Section 4.3 above. 923 -407 - Proxy Authentication Required 924 An HTTP/1.1 proxy will use this status code when credentials 925 supplied by a client could not be validated, in addition to the use 926 described in Section 4.3 above. 927 -432 - Transition Needed 928 This status codes indicates that the user name is valid, but the 929 entry in the authentication database needs to be updated in 930 order to permit authentication with the specified SASL mechanism. 931 This typically is done by authenticating once using the PLAIN 932 authentication mechanism. See Section 4.3.4. 934 This status code can be sent, for example, if a user has an entry in 935 a system authentication database such as Unix /etc/passwd, but does 936 not have credentials suitable for use by the specified mechanism. 937 -450 - Authentication mechanism not accepted 938 An HTTP/1.1 server will use this status code when a client suggests 939 an authentication mechanism which is not supported or accepted by 940 the server. 942 4.5.2 Client error handling 944 When a client does not support any of the security mechanisms 945 suggested by a server, or is otherwise unable to complete a SASL 946 mechanism handshake with a server, it shall close the connection. 948 (instead of closing the connection the client MAY also cancel the 949 SASL exchange by specifying a "*" in a directive 950 as described in Section 4.3.6). User-oriented clients SHOULD provide 951 the user with information about the failed handshake, and MUST fail 952 in a controlled, predictable manner. 954 4.6 Authorization identity 956 This document defines an authorization identity in the HTTP profile 957 of SASL to be a sequence of Unicode characters (excluding NUL), 958 encoded in UTF-8. This sequence is further prepared using the 959 "SASLPrep" profile [SASLPrep] of the "stringprep" algorithm 960 [RFC3454]. The latter restriction is required in order to have a 961 predictable result when comparing two authorization identities 962 entered by two different individuals, potentially using different 963 input mechanisms. This is also required as many SASL mechanisms use 964 authorization identities to produce hash values. 966 Clients MUST use the algorithm described above on authorization 967 identities entered by a user (for interactive clients) or read from a 968 configuration file. Servers MUST verify that a received authorization 969 identity is in the correct form. If the preparation of the 970 authorization identity fails or results in an empty string, the 971 server MUST fail the authentication exchange. The only exception to 972 this rule is when the received authorization identity is already the 973 empty string. 975 4.7 Examples 977 Note: In the examples, some lines are wrapped for readability 978 reasons. 980 4.7.1 Example 1 - Server requires authentication 982 This example illustrates a client requesting a URL and a server 983 responding with a list of supported SASL mechanisms. The client 984 selects one of these and responds with a new request containing an 985 initial-response type directive. The server then 986 issues a directive back to the client which once 987 again responds with a directive in the 988 Authorization header field. 990 C: GET http://classified.example.com/classified.html HTTP/1.1 991 Host: classified.example.com 993 S: HTTP/1.1 401 Unauthorized 994 Cache-Control: no-store 995 WWW-Authenticate: SASL 996 mechanisms="DIGEST-MD5,GSSAPI,CRAM-MD5", 997 realm="testrealm@example.com", 998 id="jfkasdgru42705" 1000 C: GET http://classified.example.com/classified.html HTTP/1.1 1001 Cache-Control: no-store 1002 Pragma: no-cache 1003 Host: classified.example.com 1004 Authorization: SASL 1005 mechanism="CRAM-MD5", 1006 id="jfkasdgru42705" 1008 S: HTTP/1.1 401 Unauthorized 1009 Cache-Control: no-store 1010 WWW-Authenticate: SASL 1011 id="jfkasdgru42705", 1012 challenge="PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u 1013 Lm1jaS5uZXQ+" 1015 C: GET http://classified.example.com/classified.html HTTP/1.1 1016 Cache-Control: no-store 1017 Pragma: no-cache 1018 Host: classified.example.com 1019 Authorization: SASL 1020 id="jfkasdgru42705", 1021 credentials="dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNG 1022 QzODkw" 1024 S: HTTP/1.1 235 OK 1025 Cache-Control: no-store 1026 WWW-Authenticate: SASL 1027 id="jfkasdgru42705" 1029 Client now retries the original request: 1031 C: GET http://classified.example.com/classified.html HTTP/1.1 1032 Host: classified.example.com 1034 S: HTTP/1.1 200 OK 1035 Cache-Control: no-store 1036 ...Requested Document follows... 1038 4.7.2 Example 2 - Initial response 1040 In this example a client knows in advance that a certain SASL 1041 mechanism is required. The mechanism allows for an initial-response 1042 type message and the client therefore includes a 1043 directive in its Authorization header. The server accepts the 1044 credentials and responds with the requested information. 1046 C: GET http://classified.example.com/classified.html HTTP/1.1 1047 Cache-Control: no-store 1048 Pragma: no-cache 1049 Host: classified.example.com 1050 Authorization: SASL 1051 mechanism="SECURID", 1052 credentials="AG1hZ251cwAxMjM0NTY3OAA=" 1054 (the client doesn't know if authentication is complete at this point, 1055 as certain SASL mechanisms have a variable number of steps.) 1057 S: HTTP/1.1 235 OK 1058 Cache-Control: no-store 1059 WWW-Authenticate: SASL 1060 id="jfkasdgru42705" 1062 C: GET http://classified.example.com/classified.html HTTP/1.1 1063 Host: classified.example.com 1065 S: HTTP/1.1 200 OK 1066 Cache-Control: no-store 1067 ...Requested Document follows... 1069 4.7.3 Example 3 - One mechanism only 1071 In this example a server supports only one SASL mechanism, which 1072 allows for sending of an initial challenge to a client. 1074 C: GET http://classified.example.com/classified.html HTTP/1.1 1075 Host: classified.example.com 1077 S: HTTP/1.1 401 Unauthorized 1078 Cache-Control: no-store 1079 WWW-Authenticate: SASL 1080 mechanisms="CRAM-MD5", 1081 realm="testrealm@example.com", 1082 id="jfkasdgru42705", 1083 challenge="PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u 1084 Lm1jaS5uZXQ+" 1086 C: GET http://classified.example.com/classified.html HTTP/1.1 1087 Cache-Control: no-store 1088 Pragma: no-cache 1089 Host: classified.example.com 1090 Authorization: SASL 1091 id="jfkasdgru42705", 1092 credentials="dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNG 1093 QzODkw" 1095 S: HTTP/1.1 235 OK 1096 Cache-Control: no-store 1097 WWW-Authenticate: SASL 1098 id="jfkasdgru42705" 1100 C: GET http://classified.example.com/classified.html HTTP/1.1 1101 Host: classified.example.com 1103 S: HTTP/1.1 200 OK 1104 Cache-Control: no-store 1105 ...Requested Document follows... 1107 4.7.4 Example 4 - Server sends additional data 1109 This example demonstrates the use of an integrity/privacy layer. 1110 Note that the client is using the CONNECT method, as it is willing to 1111 negotiate integrity/privacy protection provided by the DIGEST-MD5 1112 SASL mechanism. 1114 In its third message, the client specifies options="http-authzid", 1115 which instructs the server to return an directive upon 1116 successful authentication. 1118 C: GET http://classified.example.com/classified.html HTTP/1.1 1119 Host: classified.example.com 1121 S: HTTP/1.1 401 Unauthorized 1122 Cache-Control: no-store 1123 WWW-Authenticate: SASL 1124 mechanisms="DIGEST-MD5,GSSAPI,CRAM-MD5", 1125 realm="testrealm@example.com", 1126 id="0001" 1128 C: CONNECT classified.example.com:80 HTTP/1.1 1129 Host: classified.example.com 1131 S: HTTP/1.1 200 OK 1133 C: GET http://classified.example.com/classified.html HTTP/1.1 1134 Cache-Control: no-store 1135 Pragma: no-cache 1136 Host: classified.example.com 1137 Authorization: SASL 1138 mechanism="DIGEST-MD5", 1139 id="0001", options="http-authzid" 1141 S: HTTP/1.1 401 Unauthorized 1142 Cache-Control: no-store 1143 WWW-Authenticate: SASL 1144 id="0001", 1145 challenge="cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl 1146 PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv 1147 cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA==" 1149 C: GET http://classified.example.com/classified.html HTTP/1.1 1150 Cache-Control: no-store 1151 Pragma: no-cache 1152 Host: classified.example.com 1153 Authorization: SASL 1154 id="0001", 1155 credentials="Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLH 1156 JlYWxtPSJlbHdvb2QuaW5ub3NvZnQuY29tIixub25jZT 1157 0iT0E2TUc5dEVRR20yaGgiLG5jPTAwMDAwMDAxLGNub 1158 25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9 1159 ImltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9 1160 uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxND 1161 NhZjcscW9wPWF1dGg=" 1163 S: HTTP/1.1 401 Unauthorized 1164 Cache-Control: no-store 1165 WWW-Authenticate: SASL 1166 id="0001", 1167 challenge="cnNwYXV0aD00YjJiYjM3ZjA0OTEwNTA1Nzc3YzJmNjM 1168 4YzkyMjcyNQ==" 1170 C: GET http://classified.example.com/classified.html HTTP/1.1 1171 Cache-Control: no-store 1172 Pragma: no-cache 1173 Host: classified.example.com 1174 Authorization: SASL 1175 id="0001" 1177 S: HTTP/1.1 235 OK 1178 Cache-Control: no-store 1179 WWW-Authenticate: SASL 1180 id="0001", 1181 http-authzid="http://example.com/testrealm/users/lisa" 1183 CP: GET http://classified.example.com/classified.html HTTP/1.1 1184 Host: classified.example.com 1186 SP: HTTP/1.1 200 OK 1187 ...Requested Document follows... 1189 CP: ...Any subsequent request for a data on the same server, 1190 unless the server requests reauthentication... 1192 4.7.5 Example 5 - Abort 1194 The following example shows how a client can abort an authentication 1195 exchange. 1197 C: GET http://classified.example.com/classified.html HTTP/1.1 1198 Host: classified.example.com 1200 S: HTTP/1.1 401 Unauthorized 1201 Cache-Control: no-store 1202 WWW-Authenticate: SASL 1203 mechanisms="DIGEST-MD5,GSSAPI,CRAM-MD5", 1204 realm="testrealm@example.com", 1205 id="0001" 1207 C: GET http://classified.example.com/classified.html HTTP/1.1 1208 Cache-Control: no-store 1209 Pragma: no-cache 1210 Host: classified.example.com 1211 Authorization: SASL 1212 mechanism="DIGEST-MD5", 1213 id="0001" 1215 S: HTTP/1.1 401 Unauthorized 1216 Cache-Control: no-store 1217 WWW-Authenticate: SASL 1218 id="0001", 1219 challenge="cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl 1220 PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv 1221 cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA==" 1223 C: GET http://classified.example.com/classified.html HTTP/1.1 1224 Cache-Control: no-store 1225 Pragma: no-cache 1226 Host: classified.example.com 1227 Authorization: SASL 1228 id="0001", 1229 credentials="*" 1231 S: HTTP/1.1 401 Authentication Canceled 1232 ... 1234 4.7.6 Example 6 - Client requires authentication 1236 The following example is almost identical to Example 1, but here the 1237 client requires authentication to the server. 1239 C: OPTIONS http://classified.example.com/classified.html HTTP/1.1 1240 Authorization: SASL 1241 Host: classified.example.com 1243 S: HTTP/1.1 401 Unauthorized 1244 Cache-Control: no-store 1245 WWW-Authenticate: SASL 1246 mechanism="DIGEST-MD5,GSSAPI,CRAM-MD5", 1247 realm="testrealm@example.com", 1248 id="jfkasdgru42705" 1250 C: GET http://classified.example.com/classified.html HTTP/1.1 1251 Cache-Control: no-store 1252 Pragma: no-cache 1253 Host: classified.example.com 1254 Authorization: SASL 1255 mechanism="CRAM-MD5", 1256 id="jfkasdgru42705" 1258 S: HTTP/1.1 401 Unauthorized 1259 Cache-Control: no-store 1260 WWW-Authenticate: SASL 1261 id="jfkasdgru42705", 1262 challenge="PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u 1263 Lm1jaS5uZXQ+" 1265 C: GET http://classified.example.com/classified.html HTTP/1.1 1266 Cache-Control: no-store 1267 Pragma: no-cache 1268 Host: classified.example.com 1269 Authorization: SASL 1270 id="jfkasdgru42705", 1271 credentials="dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNG 1272 QzODkw" 1274 S: HTTP/1.1 235 OK 1275 Cache-Control: no-store 1276 WWW-Authenticate: SASL 1277 id="jfkasdgru42705" 1279 Upon receipt of a 235 response the client submits the request it 1280 originally intended to submit: 1282 C: GET http://classified.example.com/classified.html HTTP/1.1 1283 Host: classified.example.com 1285 S: HTTP/1.1 200 OK 1286 Cache-Control: no-store 1287 ...Requested Document follows... 1289 4.7.7 Example 7 - Client requires authentication, server supports 1290 multiple realm 1292 The following example is almost identical to Example 2, but here the 1293 server supports multiple realms. 1295 C: GET http://classified.example.com/classified.html HTTP/1.1 1296 Cache-Control: no-store 1297 Pragma: no-cache 1298 Host: classified.example.com 1299 Authorization: SASL 1300 mechanism="SECURID", 1301 credentials="AG1hZ251cwAxMjM0NTY3OAA=" 1303 As the server supports multiple realms for the requested resource, 1304 it forces the client to select the proper realm 1306 S: HTTP/1.1 401 Unauthorized 1307 Cache-Control: no-store 1308 WWW-Authenticate: SASL 1309 mechanisms="DIGEST-MD5,SECURID", 1310 realm="testrealm@sales.example.com", 1311 id="jfkasdgru42705" 1312 WWW-Authenticate: SASL 1313 mechanisms="SECURID", 1314 realm="testrealm@example.com", 1315 id="jfkasdgru42705" 1317 (Note that the server may choose to return multiple SASL challenges 1318 in a single WWW-Authenticate response, in this case the last server 1319 response may also look like: 1321 S: HTTP/1.1 401 Unauthorized 1322 Cache-Control: no-store 1323 WWW-Authenticate: SASL 1324 mechanisms="DIGEST-MD5,SECURID", 1325 realm="testrealm@sales.example.com", 1326 id="jfkasdgru42705", SASL 1327 mechanisms="SECURID", 1328 realm="testrealm@example.com", 1329 id="jfkasdgru42705" 1331 Also note, that different SASL challenges may use the same or 1332 different "id".) 1333 C: GET http://classified.example.com/classified.html HTTP/1.1 1334 Cache-Control: no-store 1335 Pragma: no-cache 1336 Host: classified.example.com 1337 Authorization: SASL 1338 mechanism="SECURID", id="jfkasdgru42705", 1339 realm="testrealm@sales.example.com", 1340 credentials="AG1hZ251cwAxMjM0NTY3OAA=" 1342 S: HTTP/1.1 235 OK 1343 Cache-Control: no-store 1344 WWW-Authenticate: SASL 1345 id="jfkasdgru42705" 1347 C: GET http://classified.example.com/classified.html HTTP/1.1 1348 Host: classified.example.com 1350 S: HTTP/1.1 200 OK 1351 Cache-Control: no-store 1352 ...Requested Document follows... 1354 4.7.8 Example 8 - Client uses POST request 1356 In this example the client is willing to perform a POST request but 1357 the server requires authentication and the establishment of a 1358 security layer. 1360 Note that since the client sends its information unprotected in the 1361 initial POST message, in effect only the server's response (and any 1362 later messages) will benefit from this security layer. 1364 C: POST http://classified.example.com/update_classified.php 1365 HTTP/1.1 1366 Host: classified.example.com 1367 Content-Type: ... 1368 Content-Length: ... 1370 ...request body... 1372 S: HTTP/1.1 401 Unauthorized 1373 Cache-Control: no-store 1374 WWW-Authenticate: SASL 1375 mechanisms="DIGEST-MD5,GSSAPI,OTP", 1376 realm="testrealm@example.com", 1377 id="0001" 1379 C: CONNECT classified.example.com:80 HTTP/1.1 1380 Host: classified.example.com 1382 S: HTTP/1.1 200 OK 1384 C: POST http://classified.example.com/update_classified.php 1385 HTTP/1.1 1386 Cache-Control: no-store 1387 Pragma: no-cache 1388 Host: classified.example.com 1389 Authorization: SASL 1390 mechanism="OTP",id="0001",credentials="AHRpbQ==" 1392 S: HTTP/1.1 401 Unauthorized 1393 Cache-Control: no-store 1394 WWW-Authenticate: SASL 1395 id="0001",challenge="b3RwLW1kNSAxMjMga2UxMjM0IGV4dA==" 1397 C: POST http://classified.example.com/update_classified.php 1398 HTTP/1.1 1399 Cache-Control: no-store 1400 Pragma: no-cache 1401 Host: classified.example.com 1402 Authorization: SASL 1403 id="0001",credentials="aGV4OjExZDRjMTQ3ZTIyN2MxZjE=" 1405 S: HTTP/1.1 235 OK 1406 Cache-Control: no-store 1407 WWW-Authenticate: SASL id="0001" 1409 CP: POST http://classified.example.com/update_classified.php 1410 HTTP/1.1 1411 Host: classified.example.com 1412 Content-Type: ... 1413 Content-Length: ... 1415 ...request body... 1417 SP: HTTP/1.1 200 OK 1418 ...Response to POST, if any... 1420 CP: ...Any subsequent request for a data on the same server, 1421 unless the server requests reauthentication... 1423 4.7.9 Example 9 - Client authentication fails. 1425 In this example the client authentication fails and the server 1426 indicates this in its final message using the 1427 directive. 1429 C: GET http://classified.example.com/classified.html HTTP/1.1 1430 Host: classified.example.com 1432 S: HTTP/1.1 401 Unauthorized 1433 Cache-Control: no-store 1434 WWW-Authenticate: SASL 1435 mechanisms="DIGEST-MD5,GSSAPI,CRAM-MD5", 1436 realm="testrealm@example.com", 1437 id="jfkasdgru42705" 1439 C: GET http://classified.example.com/classified.html HTTP/1.1 1440 Cache-Control: no-store 1441 Pragma: no-cache 1442 Host: classified.example.com 1443 Authorization: SASL 1444 mechanism="CRAM-MD5", 1445 id="jfkasdgru42705" 1447 S: HTTP/1.1 401 Unauthorized 1448 Cache-Control: no-store 1449 WWW-Authenticate: SASL 1450 id="jfkasdgru42705", 1451 challenge="PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u 1452 Lm1jaS5uZXQ+" 1454 C: GET http://classified.example.com/classified.html HTTP/1.1 1455 Cache-Control: no-store 1456 Pragma: no-cache 1457 Host: classified.example.com 1458 Authorization: SASL 1459 id="jfkasdgru42705", 1460 credentials="dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNG 1461 QzODkw" 1463 S: HTTP/1.1 401 Unauthorized 1464 Cache-Control: no-store 1465 WWW-Authenticate: SASL 1466 id="jfkasdgru42705" 1467 status="failed" 1469 At this point, both the server and the client shall return to their 1470 initial state wrt. the SASL authentication. 1472 4.8 Interoperability with existing HTTP/1.1 clients and servers 1474 A client supporting a certain SASL-based authentication mechanism 1475 allowing for initial responses MUST NOT include a 1476 directive in a "SASL" authorization request in an 1477 Authorization or Proxy-Authorization header unless it knows that the 1478 server supports the SASL mechanism in question. The client SHOULD use 1479 an OPTIONS request to discover the server's SASL capabilities (see 1480 Section 4.3.1.2 for more details). 1482 A server supporting SASL-based authentication SHOULD include a 1483 "Basic" and a "Digest Access" token in a WWW- 1484 Authenticate or Proxy-Authenticate header field, if these 1485 authentication methods are acceptable to the server. This ensures 1486 proper interworking with clients only capable of performing a "Basic" 1487 or "Digest Access" authentication. Since these authentication 1488 mechanisms does not offer strong security, the risk of downgrading 1489 attacks should be carefully considered (see also the "Security 1490 Considerations" section in this memo and Section 4.1 and 4.2 in 1491 [RFC2617]). 1493 4.9 Preferences 1495 Servers MUST list authentication mechanisms in the WWW-Authenticate 1496 (Proxy-Authenticate) header field in preferred order. 1498 4.10 SASL mechanism recommendations 1500 It is RECOMMENDED that an SASL mechanism that supports the 1501 negotiation of a security layer with integrity protection be used, 1502 and that this protection be enabled to avoid the connection being 1503 hijacked after authentication has taken place. [RFC2222] discusses 1504 some of the security issues related to SASL mechanisms. 1506 5 IANA considerations 1508 5.1 GSSAPI/SASL service name 1510 For use with SASL [RC2222], a protocol must specify a service name to 1511 be used with various SASL mechanisms, such as GSSAPI. For HTTP, the 1512 service name shall be "http". 1514 5.2 HTTP/1.1 Status codes 1516 This memo defines the following HTTP/1.1 status codes: 1518 -235 "Authentication Completed" 1519 -236 "Proxy Authentication Completed" 1520 -432 "Transition Needed" 1521 -450 "Authentication mechanism not accepted" 1523 6 Security considerations 1525 6.1 Introduction 1527 This memo describes a method to integrate the SASL framework in 1528 HTTP/1.1. SASL as such allows a wide variety of mechanism, each with 1529 their own security characteristics. The following sections represent 1530 an attempt to discuss threats that can be regarded to be generic in 1531 the sense that they apply to the integration itself rather than 1532 specific SASL mechanisms. Security services offered by, and security 1533 considerations applying to, particular SASL mechanisms can be found 1534 through the IANA SASL mechanism registry. 1536 6.2 Active attacks 1538 6.2.1 Man-in-the-middle 1540 Users of SASL in HTTP/1.1 SHOULD recognize that certain man-in-the- 1541 middle attacks are possible since the negotiation of the particular 1542 SASL security mechanism to be used is not necessarily protected. For 1543 example, if the server suggests SASL mechanisms A, B and C in a 1544 "SASL" token where A is a "strong" mechanism (for some 1545 definition of "strong") but B and C are "weak" or provide fewer 1546 security attributes than A, then an attacker could simply remove A 1547 from the list. This forces the client to choose a "weaker" mechanism 1548 and neither side will necessarily detect the changes made by the 1549 attacker. 1551 To mitigate these attacks, servers SHOULD only suggest SASL 1552 mechanisms that will provide adequate security for the task at hand. 1554 Similarly, the SASL token may be removed from the WWW- 1555 Authenticate (Proxy-Authenticate) header, thus forcing use of either 1556 the Basic or Digest Access method. For this reason, and unless other 1557 precautions (such as only accepting certain SASL mechanisms) are 1558 taken, it is RECOMMENDED that this authentication mechanism be used 1559 only in conjunction with a transport, e.g. TLS, providing protection 1560 against these attacks (server authentication and integrity protection 1561 of messages). Note however that when using client authentication 1562 mechanisms within a server-authenticated TLS tunnel, care must be 1563 taken to avoid the attack described in [MITM]. 1565 6.2.2 Denial of service 1567 Since HTTP/1.1 requests and responses are not protected against 1568 modification per se, an attacker may, by removing SASL elements from 1569 HTTP/1.1 headers hinder a client from accessing a certain service. 1570 This is however a generic threat and not specific to the mechanism 1571 described herein. 1573 6.2.3 Replay 1575 Use of the "Cache-Control: no-store" and "Pragma: no-cache" headers 1576 when indicated in requests and responses ensures that proxies do not 1577 inadvertently store and/or deliver SASL handshake messages that 1578 otherwise could be used in replay attacks. 1580 6.3 Passive attacks 1582 Unless a transport security providing confidentiality is employed, 1583 the method described in this memo is susceptible to passive attacks 1584 where an attacker wants to find out about the mechanisms that are 1585 supported by a particular client. 1587 6.4 Protecting the body of POST/PUT requests 1589 When the client performs a POST/PUT request in the clear and gets 1590 Unauthorized response back from the server it is already too late to 1591 protect the body of the POST/PUT request, as it was already sent in 1592 the clear. Arguably, if the client sent some data in the clear with 1593 the user's permission, the user doesn't find the information being 1594 sent worth protecting. However, existing web clients are able to 1595 warn users about sending data in the clear, but don't have an option 1596 to establish a secure connection first. 1598 The described problem is not specific to this document. HTTP over TLS 1599 uses a different URL schema to notify the client that it has to 1600 establish a secure connection first with TLS. 1602 So, one way to mitigate the problem would be to define a new URL 1603 schema (or an extension to the existing URL schema) for SASL in HTTP. 1604 This is however outside of the scope for this document. 1606 A client wishing to protect body of a POST/PUT request from 1607 modification and/or disclosure should first establish a channel 1608 protection using TLS and/or SASL. In general, an interactive client 1609 SHOULD ask a user (or be configurable) to establish channel 1610 protection before performing any POST/PUT. 1612 6.5 Other considerations 1614 Section 8.2 of [RFC2817] contains relevant security considerations 1615 for the CONNECT method. 1617 Note that SASL mechanisms offering confidentiality and integrity 1618 protection of messages are only usable in conjunction with the 1619 CONNECT method as described, since a proxy otherwise would be unable 1620 to handle the messages properly. 1622 Section 6.3 ("Multiple authentications") of [RFC2222bis] contains 1623 security considerations regarding replacing a SASL security layer 1624 with no layer on reauthentication. 1626 7 Implementation considerations 1628 This section is informative. 1630 7.1 The SASL authentication exchange context 1632 This memo assumes the existence of a SASL authentication exchange 1633 context during the lifetime of a SASL handshake. The SASL 1634 authentication exchange context is a SASL structure that represents 1635 all SASL state associated with the authentication exchange identified 1636 by sasl-sid. It may include (but is not limited to): the current step 1637 in a multiple-step authentication exchange, an authentication id, any 1638 material derived from password, private key, etc. 1640 The context should be kept for some period of time after the 1641 connection goes away. This period is implementation defined. The SASL 1642 context should be deleted once the session expires, and must be 1643 deleted once the authentication exchange completes with success or 1644 failure, or the session otherwise becomes invalid (e.g. when a 1645 duplicated authentication exchange was received for the same 1646 session). 1648 Although, a particular implementation may choose to store any SASL 1649 security layer state (e.g. encryption/decryption keys) as a part of 1650 the SASL context, this document considers a SASL security layer state 1651 to be a separate entity from the corresponding SASL context. The SASL 1652 security layer state is deleted when the connection it is protecting 1653 is closed or the corresponding authentication exchange fails. In the 1654 latter case we are talking about partially created SASL security 1655 layer states. However, as opposed to the SASL context, the SASL 1656 security layer state is not deleted when the authentication exchange 1657 completes successfully. 1659 7.2 SASL security layer handling 1661 This section attempts to summarize client and server behaviour with 1662 regards to SASL security layer negotiation. 1664 A client willing to negotiate a SASL security layer must perform all 1665 of the following steps: 1667 a) Use persistent connection to perform a SASL authentication 1668 exchange (Section 4.4.2). A SASL security layer (if supported 1669 by the server and negotiated) can only be used on the TCP 1670 connection that was used for the final "round" (i.e. C->S: 1671 client response, S->C: server confirms that authentication 1672 was successful) of the authentication exchange. Note that some 1673 SASL mechanisms use IP addresses in authentication exchange, 1674 which effectively requires the use of a persistent connection 1675 during the whole authentication exchange. 1677 b) Use CONNECT to establish an end to end tunnel through proxies, 1678 unless the client has a prior knowledge that it talks directly 1679 to the target server (Section 4.3.2). 1681 c) Notify the SASL layer/library being used that it supports 1682 channel integrity and/or confidentiality. 1684 As the SASL security layer is an optional feature of SASL, the rules 1685 a)-c) do not guarantee that a security layer will be negotiated. A 1686 client that requires a security layer must check, after successful 1687 authentication, that such a layer indeed was negotiated. 1689 Regarding c) above, if a client is not able and/or not willing to 1690 negotiate a SASL security layer it must notify the SASL layer/library 1691 being used that it doesn't support channel integrity or 1692 confidentiality. Failure to do so may result in a situation when both 1693 parties negotiate a SASL security layer, but the client is unable to 1694 use it. The client doesn't have to do step b) and may not do step 1695 a). 1697 Similarly, a server willing to negotiate a SASL security layer must 1698 perform all of the following steps: 1700 a) Use a persistent connection to perform a SASL authentication 1701 exchange (Section 4.4.2). A SASL security layer (if supported 1702 by the client and negotiated) can only be used on the TCP 1703 connection that was used for the final "round" of the 1704 authentication exchahge. 1706 b) Support the CONNECT method (Section 4.3.2). 1708 c) Notify the SASL layer/library being used that it supports 1709 channel integrity and/or confidentiality. 1711 As for clients above, rules a)-c) do not guarantee that a security 1712 layer will be negotiated. A server, which requires a security layer, 1713 must check, after successful authentication, that such a layer indeed 1714 was negotiated. 1716 If a server is not able and/or not willing to negotiate a SASL 1717 security layer it must notify the SASL layer/library being used that 1718 it doesn't support channel integrity or confidentiality. Failure to 1719 do so may result in a situation when both ends negotiate a SASL 1720 security layer, but the server is unable to use it. 1722 7.3 SASL Profile Checklist 1724 The profiling requirements of [SASL] require that the following 1725 information be supplied by a protocol definition: 1727 service name: "http" (section 5.1) 1729 authentication protocol exchange initiation: section 4.3.1 1731 listing supported SASL mechanisms: 1732 a) if server requires authentication: section 4.3.1.1 1733 b) client request the list: section 4.3.1.2 1735 Initial client response: sections 4.3.1.2, 4.3.2 1737 Initial server challenge: section 4.3.1.1 1739 exchange sequence: client -> server: section 4.3.3 1740 server -> client : section 4.3.2, 4.3.4 1741 server sends failure: sections 4.3.3, 4.4.1 1742 server sends success: section 4.3.3 1744 client aborts exchange: section 4.3.6, also sections 4.4.1, 4.2.3 1746 optional data with success: not supported, see section 4.3.3 1748 security layer negotiation: section 4.4.2 1750 order of SASL security layer and TLS, 1751 if both are negotiated: section 4.4.3 1753 use of the authorization identity: section 4.6 1755 multiple authentications: yes, see section 4.3.5, also section 4.4.2 1757 Interaction of SASL exchange with line lenght limits: section 4.4.1 1759 Specific Issues: 1760 multiple realms: sections 4.3.1.1 and 4.3.1.2 1761 persistent connection: sections 3 and 4.3.10 1762 mixing multiple authentications on the same connection: section 4.3.2 1763 OPTIONS method: 4.3.1.2 1765 8 Acknowledgements 1767 Text for Section 4.6 was borrowed from [RFC2829]. Thanks to Keith 1768 Burdis, Raif S. Naffah, Mark Nottingham, Joe Orton, John P. Speno, 1769 Lisa Dusseault and Eric Rescorla for providing useful feedback and 1770 suggestions. 1772 Robert Zuccherato, Entrust Inc., made significant contributions to 1773 earlier drafts of this work. 1775 A large part of this document was written while Alexey was working 1776 for MessagingDirect. 1778 9 References 1780 9.1 Normative references 1782 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1783 3," IETF RFC 2026, October 1996. 1785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1786 Requirement Levels," IETF RFC 2119, March 1997. 1788 [RFC2222] Myers, J., "Simple Authentication and Security Layer," IETF 1789 RFC 2222, October 1997. 1791 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 1792 Specifications: ABNF," IETF RFC 2234, November 1997. 1794 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1795 Resource Identifiers (URI): Generic Syntax," IETF RFC 2396, August 1796 1998. 1798 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 1799 L., Leach, P., Berners-Lee, T., "Hypertext Transfer Protocol -- 1800 HTTP/1.1," IETF RFC 2616, June 1999. 1802 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1803 Leach, P., Luotonen, A., Stewart, L., "HTTP Authentication: Basic and 1804 Digest Access Authentication," IETF RFC 2617, June 1999. 1806 [RFC2817] Khare, R., Lawrence, S., "Upgrading to TLS Within 1807 HTTP/1.1," IETF RFC 2817, May 2000. 1809 [RFC2831] Leach, P. C. Newman, "Using Digest Authentication as a SASL 1810 Mechanism," IETF RFC 2831, May 2000. 1812 [RFC3454] P. Hoffman, M. Blanchet, "Preparation of Internationalized 1813 Strings ("stringprep")," IETF RFC 3454, December 2002. 1815 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1816 Encodings," IETF RFC 3548, July 2003 1818 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user names 1819 and passwords," Work in progress, draft-ietf-sasl-saslprep-XX.txt. 1821 9.2 Informative references 1823 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in 1824 Tunnelled Authentication Protocols." Available from 1825 http://eprint.iacr.org/2002/163/ 1827 [RFC2222bis] Melnikov, A., "Simple Authentication and Security Layer 1828 (SASL)", Work in progress, draft-ietf-sasl-rfc2222bis-XX.txt. 1830 [RFC2246] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0," 1831 IETF RFC 2246, January 1999. 1833 [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, 1834 "Authentication Methods for LDAP," IETF RFC 2829, May 2000. 1836 [RFC2965] Kristol, D., L. Montulli, "HTTP State Management 1837 Mechanism," IETF RFC 2965, October 2000. 1839 10 Authors' addresses 1841 Magnus Nystrom Email: magnus@rsasecurity.com 1842 RSA Security 1843 Box 10704 1844 121 29 Stockholm 1845 Sweden 1847 Alexey Melnikov Email: Alexey.Melnikov@isode.com 1848 Isode Limited 1849 5 Castle Business Village, 1850 36 Station Road, 1851 Hampton, Middlesex, 1852 United Kingdom, TW12 2BX 1854 11 IPR Disclosure Acknowledgement 1856 By submitting this Internet-Draft, I certify that any applicable 1857 patent or other IPR claims of which I am aware have been disclosed, 1858 and any of which I become aware will be disclosed, in accordance with 1859 RFC 3668. 1861 12 Intellectual Property Statement 1863 The IETF takes no position regarding the validity or scope of any 1864 intellectual property or other rights that might be claimed to 1865 pertain to the implementation or use of the technology described in 1866 this document or the extent to which any license under such rights 1867 might or might not be available; neither does it represent that it 1868 has made any effort to identify any such rights. Information on the 1869 IETF's procedures with respect to rights in standards-track and 1870 standards-related documentation can be found in BCP-11. Copies of 1871 claims of rights made available for publication and any assurances of 1872 licenses to be made available, or the result of an attempt made to 1873 obtain a general license or permission for the use of such 1874 proprietary rights by implementors or users of this specification can 1875 be obtained from the IETF Secretariat. 1877 The IETF invites any interested party to bring to its attention any 1878 copyrights, patents or patent applications, or other proprietary 1879 rights which may cover technology that may be required to practice 1880 this standard. Please address the information to the IETF Executive 1881 Director. 1883 13 Full Copyright Statement 1885 Copyright (C) The Internet Society (2004). This document is subject 1886 to the rights, licenses and restrictions contained in BCP 78 and 1887 except as set forth therein, the authors retain all their rights. 1889 This document and the information contained herein are provided on an 1890 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1891 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1892 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1893 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1894 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1895 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1897 Acknowledgement 1899 Funding for the RFC Editor function is currently provided by the 1900 Internet Society. 1902 Appendix A. Changes since previous revisions 1904 Changes since -11 1906 Editorial changes: Made "Conventioned used in this document" the 1907 first section. Moved 4.1.1 into new section 1. Moved 4.3.7 at the 1908 beginning of Section 4 (now section 4.1.2). 1910 Added clarification note that a SASL security layer is an optional to 1911 negotiate feature of SASL. 1913 Added Introduction text as suggested by Eric Rescorla. 1915 Clarified significance and handling of the order of SASL mechanisms 1916 in the sasl-mechanisms directive as per comment by Eric. 1918 Clarified server behaviour when receiving and OPTIONS request as per 1919 comments by Lisa (Sections 4.3.1.2 and 4.8.1) 1921 Clarified the meaning of "a client ... MUST choose one of the 1922 available mechanisms" in Section 4.3.2. (List/Eric) 1924 Other minor editorial changes as suggested by Lisa/Eric. 1926 Updated Copyright/IPR as per new IETF policy. 1928 Changes since -10 1930 Added text on client prioritization when receiving both a "SASL" 1931 auth-scheme and a "Basic" or "Digest" auth-scheme in a 401 or 407 1932 response. 1934 Replaced "SASL block" with "SASL buffer of protected data". The 1935 latter is defined in RFC 2222. 1937 Other editorial changes based on feedback by Lisa Dusseault. 1939 Changed ABNF and updated examples in order to allow for an empty 1940 challenge/response. 1942 Added http-authzid directive as suggested by Lisa Dusseault. Added 1943 sasl-options directive. 1945 Changes since -09 1947 Added empty initial credentials 1949 New method for specifying failed authentication, including an 1950 example. 1952 Rewording of 4.3.8. 1954 Added mandatory to support SASL mechanism. 1956 Added explanatory text for multiple SASL challenges and for client 1957 abort of handshakes. 1959 Added reference to [RFC2222bis] and [MITM]. 1961 Added an example when server supports multiple realms. 1963 Added "SASL Profile Checklist" section. 1965 Editorial clarifications and corrections. 1967 Changes since -08 1969 Editorial clarifications and corrections. 1971 Changes since -07 1973 Added "Implementation consideration" section with big discussion on 1974 how to correctly implement a SASL security layer. (Comment by Keith 1975 Burdis) 1977 Moved the biggest part of "SASL Context" definition to the 1978 "Implementation consideration". 1980 Added text describing that SASLPrep should be used on authorization 1981 identities. 1983 Added section describing ways to protect/help protect body of a 1984 POST/PUT request. (Comment by Keith Burdis) 1986 Several minor fixes. 1988 Changes since -06 1990 Changed 102 status code back to 401. 1992 "credentials" directive is no longer returned by the server, only 1993 "challenge" is used. 1995 Added text about SASL context. 1997 Split "SASL handshake initiation" section into Client and Server 1998 initiated. 2000 Added text about performing multiple authentications in parallel. 2002 Clarified the use of persistent connection with SASL. Added warnings 2003 about session caching and expiration. Updated text to tell when SASL 2004 context is destroyed. 2006 Added new status codes: 450 "Authentication mechanism not accepted". 2008 Expired session is denoted by a 401 (407) response with a new value. 2011 Clarified when security layer is replaced/dropped on 2012 reauthentication. 2014 Added warning that the server is required to keep track of 2015 authenticated clients. Removed the text that was saying that the 2016 server must return sasl-sid in 200 responses when authentication is 2017 complete. 2019 Updated examples as a result of the changes mentioned above. 2021 Other minor clarifications. 2023 Changes since -05 2025 Replaced "Cache-Control: no-cache" with "Cache-Control: no-store" as 2026 per Mark Nottingham comment. 2028 ABNF corrections from Joe Orton and John P Speno. 2030 More corrections from Joe Orton. 2032 Changed 401 to a new status code 102 used solely for authentication. 2034 Added Transition Needed status code (432). Should check if this code 2035 conflicts with anything. 2037 Added new "Expect: 102-continue" header. 2039 Reworked Section 4.3 to describe more error cases and more detailed 2040 implementation instructions. 2042 Disallow TLS Upgrade during SASL authentication (it is fine before or 2043 after). Clarified order of security layers. 2045 Clarified that Authorization header with SASL response MUST NOT be 2046 used with CONNECT. 2048 Relaxed restriction for mixing SASL session ids on the same 2049 connection in certain cases. 2051 Added new 235/236 status codes for successfully completed 2052 authentication. 2054 Clarified that the body of the original request MUST NOT be sent 2055 until authentication is complete. Updated examples to reflect that. 2057 Added an example with a POST request. 2059 Changes since -04 2061 Reworked the Introduction section. 2063 Updated example 4.7.4 to include Authorization header in CONNECT 2064 request. This saves a round trip. 2066 Added text that the client must use OPTIONS to find out which SASL 2067 mechanisms are supported by the server. Added an example. 2069 Added text regarding the server requiring reauthentication when the 2070 client leaves the realm it authenticated in. 2072 Some clarification about the CONNECT method. Added text that a 2073 CONNECT request should start the authentication exchange. 2075 Incorporated comments from Raif S. Naffah and Keith Burdis. 2077 Changes since -03 2079 Fixed several errors in examples due to change from "sasl-mechanism" 2080 to "sasl-mechanisms". 2082 More comments from Keith Burdis. 2084 Changes since -02 2086 Added discussions about CONNECT and session protection. 2088 Added "Proxy servers considerations" Section. Updated examples to 2089 include headers that prevent caching. 2091 Added Web farm considerations section that talks about a next 2092 response going to a different backend web-server. 2094 Incorporated many suggestions/corrections from Keith Burdis. 2096 Editorial changes. Cleanup some SHOULDs and MUSTs. 2098 Changes since -01 2100 Added examples 2102 Split ABNF into client and server side. ABNF cleanup. 2104 Many editorial changes.