idnits 2.17.1 draft-vanrein-httpauth-sasl-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '...Whether channel binding is used SHOULD...' RFC 2119 keyword, line 156: '...exchange. In addition, the server MAY...' RFC 2119 keyword, line 158: '... that it MAY try again to achieve be...' RFC 2119 keyword, line 162: '...uthentication. The identity SHOULD be...' RFC 2119 keyword, line 163: '...ently from the URI; prior settings MAY...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2020) is 1485 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) == Unused Reference: 'RFC3986' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'I-D.vanrein-dnstxt-krb1' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC4505' is defined on line 578, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4559 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7615 (Obsoleted by RFC 9110) == Outdated reference: A later version (-11) exists of draft-vanrein-dnstxt-krb1-09 -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Van Rein 3 Internet-Draft ARPA2.net 4 Intended status: Standards Track March 4, 2020 5 Expires: September 5, 2020 7 HTTP Authentication with SASL 8 draft-vanrein-httpauth-sasl-04 10 Abstract 12 Most application-level protocols standardise their authentication 13 exchanges under the SASL framework. HTTP has taken another course, 14 and often ends up replicating the work to allow individual 15 mechanisms. This specification adopts full SASL authentication into 16 HTTP. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 5, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Embedding SASL in HTTP . . . . . . . . . . . . . . . . . . . 3 54 2.1. HTTP Request and Response Messages . . . . . . . . . . . 4 55 2.2. Authentication Field Definitions . . . . . . . . . . . . 5 56 2.3. Caching Authentication Results . . . . . . . . . . . . . 6 57 3. Server-Side User Name . . . . . . . . . . . . . . . . . . . . 6 58 4. Authentication Session Example . . . . . . . . . . . . . . . 7 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 63 7.2. Informative References . . . . . . . . . . . . . . . . . 12 64 Appendix A. HTTP Server Environment Variables . . . . . . . . . 13 65 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 68 1. Introduction 70 HTTP has historically followed its own path for client 71 authentication, while many other end-user protocols standardised on 72 SASL; examples of SASL protocols include SMTP, IMAP, POP, XMPP, LDAP, 73 AMQP and MQTT. This specification introduces SASL to HTTP, so it may 74 share in past and future work done for SASL in general. 76 Among the work that could be shared is backend authentication 77 integration, which is possible due to protocol-independent SASL 78 exchanges for any given method, making it easy to take them out of 79 one protocol and inserting them into another. Although HTTP has 80 adopted several SASL-compatible authentication methods, it uses 81 various notations and so it still needs method-specific support at 82 the HTTP level to translate them to a SASL backend. 84 In front-ends, a similar situation has arisen. The varying syntaxes 85 for authentication methods have made it difficult to rely on support 86 in most or all HTTP clients. When such clients could externalise 87 their SASL handling to generic software such as a SASL library, then 88 any extension to a library automatically spills over into the HTTP 89 sphere. It is common for developers of web clients to also produce 90 email clients, so a shared code base (and credential store) is not 91 difficult to imagine. 93 Sharing of authentication mechanisms is beneficial in both 94 directions. HTTP benefits by being able to use anything from strong 95 password mechanisms [RFC5802] without explicit support [RFC7804] in 96 applications, up to GS2 mechanisms [RFC5801] with channel binding 97 [RFC5056] [RFC5554] to TLS [RFC5929] based on pinning either the 98 certificate for the TLS server or even a unique part of the 99 individual TLS connection; for instance Kerberos5 [RFC4120] currently 100 uses Negotiate authentication [RFC4559] which is not as secure as 101 GS2-KRB5-PLUS over SASL. 103 SASL also benefits; had it been the norm for HTTP, then the work to 104 pass SAML over it [RFC6595] would probably have been done 105 immediately. In fact, HTTP can still benefit from receiving 106 standardised SAML20 inquiries over SASL, because it resolves the need 107 for configuration of initiation paths and practices. Also, it 108 removes authentication data from URIs, where they are not ideally 109 placed. 111 In terms of security for HTTP applications, it appears beneficial to 112 have very good authentication capabilities in the layers below the 113 application; this is specifically true for applications developed in 114 HTML and JavaScript, which tend to load code from various places, 115 including code that is not always in the end user's interest; since 116 it already is a concern what identity information passes through 117 these applications, it is not advisable to use credentials in those 118 places. The HTTP layer is in a better position to take control over 119 these assets, at the protocol levels of HTTP and TLS, and conceal 120 credentials and possibly also identity from applications running on 121 top. Inasfar as tokens are needed, they can be derived from session 122 keys using generally accepted key derivation schemes, but the session 123 keys can be isolated from dynamic layers above HTTP. 125 2. Embedding SASL in HTTP 127 This specification integrates the SASL framework [RFC4422] into 128 mainstream HTTP [RFC7231], [RFC7232]. The SASL Authentication scheme 129 follows the general structure for HTTP Authentication [RFC7235]. It 130 uses the WWW-Authenticate and Proxy-Authenticate headers in responses 131 from web servers and web proxies, respectively, and correspondingly 132 the Authorization and Proxy-Authorization request header to answer to 133 requests. 135 The SASL service name for the following embedding of SASL is HTTP; 136 contrary to most other service names, it is spelled in uppercase, in 137 line with what has become general practice in Kerberos and GSSAPI. 139 Since SASL prescribes channel binding to occur relative to TLS 140 instead of to the application protocol, we can add that when the 141 HTTPS transport is used. Whether channel binding is used SHOULD 142 remain a configuration choice in HTTP software, as it might interfere 143 with intentional HTTPS proxying. Unintended proxying on the other 144 hand, might lead to tapping of credentials under certain SASL 145 mechanisms, and it may be considered helpful to prevent such 146 situations by relying on channel binding for at least those 147 mechanisms. 149 2.1. HTTP Request and Response Messages 151 This section defines a few names for HTTP request and response 152 messages, to be used in the remainder of this specification. 154 Initial Responses are HTTP responses that normally set a status code 155 401 or 407, and that are sent when the HTTP server decides to 156 initiate an authentication exchange. In addition, the server MAY 157 send Initial Responses in other responses, to indicate to the client 158 that it MAY try again to achieve better results [Section 4.1 of 159 [RFC7235]]. 161 Initial Requests are those HTTP requests that a client sends to 162 initiate a fresh SASL authentication. The identity SHOULD be 163 selected by the user independently from the URI; prior settings MAY 164 however be remembered by a client for the combination of resource 165 authority (scheme, host and possibly a separately communicated 166 resource user name) with the server-sent realm string. The server 167 can support a mixture of client identities for various roles or 168 access levels through variation of realm strings. There is no 169 current practice of server-side resource names in HTTP, but the 170 generic URI schema presents this logic and it is easy to imagine an 171 HTTP User header that a client could support. 173 Intermediate Responses are HTTP responses to SASL authentication, 174 with a status code set to 401 or 407. Intermediate Requests are 175 those HTTP requests that a client sends to continue a SASL 176 authentication after an Intermediate Response. 178 Positive Responses set a 200 status code to depict success. 179 Information in this response is provided in an Authentication-Info or 180 Proxy-Authentication-Info header [RFC7615] instead of the headers 181 used in Initial Responses and Intermediate Responses [RFC7235]. 182 Proper interpretation of a Positive Response requires client state 183 indicating that SASL authentication was used, or else the optional 184 fields are not completely reliable information sources; cryptographic 185 markers in the c2c field MAY be used to overcome this in a manner 186 that defies abuse by rogue servers. 188 Negative Responses also set a 401 or 407 status code and will often 189 return the client to an earlier state that it recognises as one it 190 has tried before. These responses should therefore offer 191 authentication to start again. In contrast to the Initial Response, 192 there is now a c2c field that helps the client evaluate the request. 194 The following fields, defined in upcoming sections, MUST and MAY be 195 present in HTTP authentication exchanges for SASL: 197 Request or Response | MUST have fields | MAY have fields 198 ----------------------+---------------------+---------------------- 199 Initial Response | s2s,mech | realm 200 Initial Request | c2c,s2s,mech | c2s,realm 201 Intermediate Response | c2c,s2s | s2c 202 Intermediate Request | c2c,s2s | c2s 203 Positive Response | c2c | s2s 204 Negative Response | c2c,s2s,mech | realm 206 2.2. Authentication Field Definitions 208 Data for SASL is transported in the following fields: 210 c2s holds SASL token data from client to server. This field is 211 transmitted with base64 encoding. The field is absent when the 212 SASL client sends no token. 214 s2c holds SASL token data from server to client. This field is 215 transmitted with base64 encoding. The field is absent when the 216 SASL server sends no token. 218 s2s holds opaque server data which the client MUST reflect in 219 Intermediate Requests. This is a necessity for a stateless 220 HTTP Authentication framework [Section 5.1.2 of [RFC7235]]. It 221 MAY be used in a Positive Response to pass a cacheable 222 Section 2.3 authentication token. 224 c2c holds opaque client data which the server MUST reflect in 225 Intermediate, Positive and Negative Responses. This can help 226 to also make the client stateless. 228 The following fields support SASL within the HTTP Authentication 229 Framework: 231 realm optionally names a scope of authorisation under the combination 232 of scheme, server host name and possibly a HTTP user to 233 implement the semantics of the generic URI username for 234 resource selection. The realm does not necessarily match a 235 domain name, which is used elsewhere as a realm notation. 237 mech In an Initial Response, the field is filled with a space- 238 separated list of SASL mechanism names; In an Initial Request, 239 the client chooses one SASL mechanism name. 241 2.3. Caching Authentication Results 243 When an HTTP server sends a Positive Response, it MAY include an 244 "s2s" field. If it does this, then it should be prepared to accept 245 the field value for authentication in an Initial Request. However, 246 credentials can expire or fall in disgrace for other reasons, so the 247 server MAY still choose to reject the provided field. 249 When an HTTP client receives a Positive Response with an "s2s" field, 250 it MAY memorise the fields for future reuse in an Initial Request, 251 either with or without preceding Initial Response from the server. 252 The HTTP client MUST use the realm as part of the decision which 253 cached result to use, but it MAY extrapolate the results from one 254 resource retrieval in an attempt to authenticate another. 256 When cached fields result in a Negative Response then the HTTP client 257 SHOULD remove the failing cache entry, and it SHOULD try again by 258 going through a full SASL authentication cycle. The stateless nature 259 of HTTP authentication is helpful in the sense that a new Initial 260 Request can be sent to an older Initial Response. 262 3. Server-Side User Name 264 HTTP does not define a mechanism to specifically select the user as 265 an authoritative resource name space on the server. Local syntax 266 conventions exist, but lack universally reliable semantics. Basic 267 authentication has been used to this effect, but this conflates the 268 client identity with the server-side name space, which is not 269 necessarily the same. 271 To allow HTTP servers to zoom in on user-specific information, the 272 User header is hereby introduced. Its syntax matches the userinfo 273 part of a URI, up to but excluding any colons in it: 275 User = *( unreserved / pct-encoded / sub-delims ) 277 The value of the header MUST be percent-decoded before the server can 278 use it to identify a local user. 280 The User header MAY be sent by clients, and HTTP servers MAY ignore 281 it for any reason, including local user identities that do not comply 282 to a more restrictive local user name syntax. 284 When an HTTP server makes use of the User header, it MUST include a 285 Vary header in its response, with either a single "*" in it or the 286 name "User". This informs caches that the response must be 287 considered specific to the User header value in the matching request. 289 The User header may be used with or without any form of 290 authentication. When used with authentication, the value of the 291 percent-decoded header is considered part of the authority component 292 of the resource, and therefore of the naming scope for the realm. 293 Clients can use this refined notion of realm to select an 294 authentication identity; when the value is known early enough, this 295 may even help to select an X.509 client certificate. Note that the 296 User header might be used together with the aforementioned practice 297 of Basic authentication, but it can also replace it with an even 298 simpler mechanism to free up the authentication exchange for HTTP 299 SASL. 301 The distinction of a client-side user from a server-side user can 302 benefit the use of credential schemes that are not tied to the HTTP 303 server. A specific example of this is the current work on realm 304 crossover with GS2-SXOVER-PLUS. The use of such a mechanism may 305 offload security concerns from the application layer. 307 4. Authentication Session Example 309 This section is non-normative. 311 When an HTTP server receives a request for a protected page, it will 312 send an Initial Response to ask for authentication with a special 313 status code 401; for proxy access that would be 407, and header names 314 change accordingly. Stripped down to the bare essentials, the server 315 sends (this section adds whitespace for clarity) 317 HTTP/1.1 401 Unauthorized 318 WWW-Authenticate: SASL 319 realm="members only" 320 mech="SCRAM-SHA-256 SCRAM-SHA-256-PLUS 321 SCRAM-SHA-1 SCRAM-SHA-1-PLUS 322 GS2-KRB5-PLUS GS2-KRB5", 323 s2s=[xxxxx] 325 The server offers SCRAM-* and GS2-KRB5 mechanisms. The variants with 326 -PLUS provide additional channel binding, to ensure that 327 authentication is specific to the current HTTPS connection, thus 328 avoiding replay of the session across connections. Clients aware of 329 HTTP connections may use connection-specific channel binding (tls- 330 unique) while those that abstract from the connections must resort to 331 weaker name-based channel binding (tls-server-end-point). 333 The server might have additionally offered the ANONYMOUS mechanism to 334 allow the client to select "guest mode" access; the interaction would 335 continue as authenticated, but presumably with limited access to HTTP 336 resources and continued WWW-Authenticate headers to continue to offer 337 authentication to improve resource information content. The server 338 might have offered EXTERNAL to allow the client to incorporate a TLS 339 credential for authentication and possibly change to an authorization 340 identity. The server might have offered GS2-SXOVER-PLUS if it is 341 willing to connect to the client's home realm over Diameter, and 342 thereby support realm crossover of SASL credentials. 344 The client initiates the SCRAM-SHA-256-PLUS mechanism, and to that 345 end sends an Initial Request (this section shows square brackets 346 instead of base64-encoding) 348 Authorization: SASL 349 realm="members only" 350 mech="SCRAM-SHA-256-PLUS", 351 c2s=[n,,n=user,r=rOprNGfwEbeRWgbNEkqO], 352 s2s=[xxxxx], 353 c2c=[qqqqq] 355 This mechanism is initiated by the client, hence the inclusion of the 356 c2s token in the Initial Request. The contents of this field are 357 specific to the selected mechanism, so SCRAM-SHA-256-PLUS in this 358 case. 360 The SCRAM mechanism implementation is now initiated with the c2s 361 token, and the server produces a followup challenge in a s2c token. 362 To be able to validate future client messages against server-side 363 state, it includes such state in an s2s token. This token is 364 presumably protected from abuse with a signature and/or encryption, 365 and it would likely identify the selected mechanism to validate 366 during later rounds. The server packs all this in an Intermediate 367 Response 369 HTTP/1.1 401 Unauthorized 370 WWW-Authentication: SASL 371 s2c=[r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxF 372 Ilj)hNlF$k0,s=W22ZaJ0SNY7soEsUEjb6gQ==, 373 i=4096] 374 s2s=[yyyyy], 375 c2c=[qqqqq] 377 Given that all server state is contained in this message, the client 378 is free at any time to give up authentication and perhaps try another 379 method. Normally however, it would proceed with the ongoing 380 transaction. The client bounces state through the server in the c2c 381 token, though it could be empty if a client manages state locally. 382 Complex services however, would prefer the added signing and/or 383 encryption of c2c in return for the benefit of decoupling the 384 request/response state from the network connection. 386 The SCRAM mechanism continues with another round. The client engages 387 in the prescribed cryptographic computations and packs an 388 Intermediate Request along with updated state in the new c2c token 390 Authorization: SASL 391 c2s=[c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hN 392 lF$k0,p=dHzbZapWIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=] 393 s2s=[yyyyy], 394 c2c=[rrrrr] 396 When the client has performed authentication properly, as determined 397 by a server-side check of the c2s response token with the prior state 398 in the s2s token, it can send a Positive Response along with the 399 requested resource 401 HTTP/1.1 200 OK 402 WWW-Authentication: SASL 403 s2c=[v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=] 404 s2s=[zzzzz], 405 c2c=[rrrrr] 407 The s2s token in a Positive Response is an optional extension. It is 408 presented by the server to allow the client to speed up 409 authentication in future requests. The client may send it whenever 410 the server asks for the same realm string under the same scheme and 411 authority; the client may make proactive assumpions about the realm 412 string for new requests. Authentication must never be reused in 413 another context than bound by channel binding. When used, the client 414 immediate sends an Intermediate Response holding 416 Authorization: SASL 417 realm="members only" 418 s2s=[zzzzz], 419 c2c=[sssss] 421 The server always has an option to refuse repeated authentication and 422 forcing the client into a new authentication round. One reason for 423 this could be that a session timed out. Another might be that the 424 client is trying to use a credential outside a scope set by channel 425 binding. 427 5. Security Considerations 429 It is not generally safe for SASL mechanisms to exchange c2s and s2c 430 messages over unprotected transports. Furthermore, the SASL exchange 431 may be at risk of tampering when the sequence of HTTP messages is not 432 secured to form one stream. This means that a secure transport layer 433 must be used, like TLS. The termination of such a secure layer MUST 434 also terminate any ongoing SASL handshakes. 436 The c2c and s2s fields MUST be protected against tampering by rogue 437 peers, and such protection also protects against tampering by rogue 438 intermediates when using an unprotected transport. In addition, but 439 dependent on the mechanism used, the c2c and s2s fields may also need 440 encryption to conceal their data from peers and intermediates. 442 SASL EXTERNAL can be a very efficient mechanism to combine with a 443 secure transport layer if that includes authentication. This may be 444 the case for TLS, especially when client-side authentication is 445 deployed. Mechanisms other than EXTERNAL should take into account 446 that a relation may exist between identities negotiated in the 447 protective layer and the SASL exchange over HTTP. For example, a 448 login account may be exchanged for an alias or group identity. 450 Channel binding is available in some SASL mechanisms. When used with 451 HTTP SASL over TLS, it binds to the TLS channel, by default using the 452 type tls-unique [Section 3 of [RFC5929]]. When doing so, it is vital 453 that either there be no renegotiation of the TLS handshake, or both 454 secure renegotiation [RFC5746] and the extended master secret 455 [RFC7627] are used. 457 The User header field as defined herein is orthogonal to issues of 458 authentication and authorisation, and adds no security concerns. 460 6. IANA Considerations 462 This specification extends the "Hypertext Transfer Protocol (HTTP) 463 Authentication Scheme Registry" with an "Authentication Scheme Name" 464 SASL, referencing this specification. 466 This specification defines an additional entry in the registry 467 "Generic Security Service Application Program Interface 468 (GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL) 469 Service Names" namely: 471 Service Name: HTTP 472 Usage: Web authentication using the SASL framework 473 Reference: TBD:this specification 475 The capitalisation of the service name has historic origins and is 476 now the preferred spelling for reasons of compatibility. 478 Please add the following entry to the Message Headers registry: 480 Header Field Name Template Protocol Status Reference 481 ------------------ --------- --------- ------- ---------- 482 User http TBD TBD:THIS_SPEC 484 7. References 486 7.1. Normative References 488 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 489 Resource Identifier (URI): Generic Syntax", STD 66, 490 RFC 3986, DOI 10.17487/RFC3986, January 2005, 491 . 493 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 494 Kerberos Network Authentication Service (V5)", RFC 4120, 495 DOI 10.17487/RFC4120, July 2005, 496 . 498 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 499 Authentication and Security Layer (SASL)", RFC 4422, 500 DOI 10.17487/RFC4422, June 2006, 501 . 503 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 504 Kerberos and NTLM HTTP Authentication in Microsoft 505 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 506 . 508 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 509 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 510 . 512 [RFC5554] Williams, N., "Clarifications and Extensions to the 513 Generic Security Service Application Program Interface 514 (GSS-API) for the Use of Channel Bindings", RFC 5554, 515 DOI 10.17487/RFC5554, May 2009, 516 . 518 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 519 "Transport Layer Security (TLS) Renegotiation Indication 520 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 521 . 523 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 524 Service Application Program Interface (GSS-API) Mechanisms 525 in Simple Authentication and Security Layer (SASL): The 526 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 527 July 2010, . 529 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 530 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 531 . 533 [RFC6595] Wierenga, K., Lear, E., and S. Josefsson, "A Simple 534 Authentication and Security Layer (SASL) and GSS-API 535 Mechanism for the Security Assertion Markup Language 536 (SAML)", RFC 6595, DOI 10.17487/RFC6595, April 2012, 537 . 539 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 540 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 541 DOI 10.17487/RFC7231, June 2014, 542 . 544 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 545 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 546 DOI 10.17487/RFC7232, June 2014, 547 . 549 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 550 Protocol (HTTP/1.1): Authentication", RFC 7235, 551 DOI 10.17487/RFC7235, June 2014, 552 . 554 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 555 Authentication-Info Response Header Fields", RFC 7615, 556 DOI 10.17487/RFC7615, September 2015, 557 . 559 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 560 Langley, A., and M. Ray, "Transport Layer Security (TLS) 561 Session Hash and Extended Master Secret Extension", 562 RFC 7627, DOI 10.17487/RFC7627, September 2015, 563 . 565 7.2. Informative References 567 [I-D.vanrein-dnstxt-krb1] 568 Rein, R., "Declaring Kerberos Realm Names in DNS 569 (_kerberos TXT)", draft-vanrein-dnstxt-krb1-09 (work in 570 progress), October 2016. 572 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 573 Leach, P., Luotonen, A., and L. Stewart, "HTTP 574 Authentication: Basic and Digest Access Authentication", 575 RFC 2617, DOI 10.17487/RFC2617, June 1999, 576 . 578 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 579 Security Layer (SASL) Mechanism", RFC 4505, 580 DOI 10.17487/RFC4505, June 2006, 581 . 583 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 584 "Salted Challenge Response Authentication Mechanism 585 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 586 DOI 10.17487/RFC5802, July 2010, 587 . 589 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 590 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 591 March 2016, . 593 Appendix A. HTTP Server Environment Variables 595 We define a number of variables that SHOULD be passed from an HTTP 596 SASL stack (and from User header processing) to applications run on 597 top of it. The intention of defining these is to obtain maximum 598 interoperability between these layers of software. 600 The following variables MUST NOT be available until SASL 601 authentication is successful; it would be available when the server 602 could send a 200 OK response: 604 SASL_SECURE is only "yes" (without the quotes) when a client is 605 authenticated to the current resource. It never has another 606 value; it is simply undefined when not secured by SASL. 608 SASL_REALM is the realm for which the secure exchange succeeded. A 609 realm is not always used, because sites only need it when there 610 are more than one in the same name space. When undefined in 611 the SASL flow, this variable will not be set. 613 REMOTE_USER is the client identity as confirmed through SASL 614 authentication. Its content is formatted like an email 615 address, and includes a domain name. That domain need not be 616 related to the web server; it is possible for a web server to 617 welcome foreign clients. 619 SASL_MECH indicates the mechanism used, and is one of the 620 standardised SASL mechanism names. It may be used to detect 621 the level of security. 623 SASL_S2S holds the accepted s2s field, and could be used as a random 624 session identifier. It would normally be encrypted 625 information. 627 SASL_S2S_ is a prefix for extra information that the server may 628 extract from the s2s field in the HTTP SASL protocol flow. 629 This depends on the authentication stack used in the web 630 server. 632 The following variable SHOULD be available while processing a request 633 with a User header with locally acceptable syntax: 635 LOCAL_USER gives the HTTP User header value after syntax checking 636 and percent-decoding. If used at all, it MUST be treated as a 637 resource name space selector. This header does not describe 638 the authenticated client identity, which is usually passed in a 639 variable REMOTE_USER. 641 Appendix B. Acknowledgements 643 Thanks to Henri Manson for making the first implementation of this 644 specification and for feedback on the header formats. The 645 specification also benefited from input by Daniel Stenberg. 647 Author's Address 649 Rick van Rein 650 ARPA2.net 651 Haarlebrink 5 652 Enschede, Overijssel 7544 WP 653 The Netherlands 655 Email: rick@openfortress.nl