idnits 2.17.00 (12 Aug 2021) /tmp/idnits25302/draft-vanrein-httpauth-sasl-06.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 140: '...Whether channel binding is used SHOULD...' RFC 2119 keyword, line 149: '... RECOMMENDED. Specific HTTP clients...' RFC 2119 keyword, line 151: '...ection 3 of [RFC5929]] is RECOMMENDED....' RFC 2119 keyword, line 152: '...eric web servers SHOULD support both f...' RFC 2119 keyword, line 161: '...exchange. In addition, the server MAY...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 234 has weird spacing: '... realm optio...' -- The document date (3 February 2022) is 102 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: 'I-D.vanrein-dnstxt-krb1' is defined on line 564, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4559 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 3 February 2022 5 Expires: 7 August 2022 7 HTTP Authentication with SASL 8 draft-vanrein-httpauth-sasl-06 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 7 August 2022. 35 Copyright Notice 37 Copyright (c) 2022 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 (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Embedding SASL in HTTP . . . . . . . . . . . . . . . . . . . 3 53 2.1. HTTP Request and Response Messages . . . . . . . . . . . 4 54 2.2. Authentication Field Definitions . . . . . . . . . . . . 5 55 2.3. Caching Authentication Results . . . . . . . . . . . . . 6 56 3. Server-Side User Name . . . . . . . . . . . . . . . . . . . . 6 57 4. Authentication Session Example . . . . . . . . . . . . . . . 7 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 62 7.2. Informative References . . . . . . . . . . . . . . . . . 12 63 Appendix A. HTTP Server Environment Variables . . . . . . . . . 13 64 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 67 1. Introduction 69 HTTP has historically followed its own path for client 70 authentication, while many other end-user protocols standardised on 71 SASL; examples of SASL protocols include SMTP, IMAP, POP, XMPP, LDAP, 72 AMQP and MQTT. This specification introduces SASL to HTTP, so it may 73 share in past and future work done for SASL in general. 75 Among the work that could be shared is backend authentication 76 integration, which is possible due to protocol-independent SASL 77 exchanges for any given method, making it easy to take them out of 78 one protocol and inserting them into another. Although HTTP has 79 adopted several SASL-compatible authentication methods, it uses 80 various notations and so it still needs method-specific support at 81 the HTTP level to translate them to a SASL backend. 83 In front-ends, a similar situation has arisen. The varying syntaxes 84 for authentication methods have made it difficult to rely on support 85 in most or all HTTP clients. When such clients could externalise 86 their SASL handling to generic software such as a SASL library, then 87 any extension to a library automatically spills over into the HTTP 88 sphere. It is common for developers of web clients to also produce 89 email clients, so a shared code base (and credential store) is not 90 difficult to imagine. 92 Sharing of authentication mechanisms is beneficial in both 93 directions. HTTP benefits by being able to use anything from strong 94 password mechanisms [RFC5802] without explicit support [RFC7804] in 95 applications, up to GS2 mechanisms [RFC5801] with channel binding 96 [RFC5056] [RFC5554] to TLS [RFC5929] based on pinning either the 97 certificate for the TLS server or even a unique part of the 98 individual TLS connection; for instance Kerberos5 [RFC4120] currently 99 uses Negotiate authentication [RFC4559] which is not as secure as 100 GS2-KRB5-PLUS over SASL. 102 SASL also benefits; had it been the norm for HTTP, then the work to 103 pass SAML over it [RFC6595] would probably have been done 104 immediately. In fact, HTTP can still benefit from receiving 105 standardised SAML20 inquiries over SASL, because it resolves the need 106 for configuration of initiation paths and practices. Also, it 107 removes authentication data from URIs, where they are not ideally 108 placed. 110 In terms of security for HTTP applications, it appears beneficial to 111 have very good authentication capabilities in the layers below the 112 application; this is specifically true for applications developed in 113 HTML and JavaScript, which tend to load code from various places, 114 including code that is not always in the end user's interest; since 115 it already is a concern what identity information passes through 116 these applications, it is not advisable to use credentials in those 117 places. The HTTP layer is in a better position to take control over 118 these assets, at the protocol levels of HTTP and TLS, and conceal 119 credentials and possibly also identity from applications running on 120 top. Inasfar as tokens are needed, they can be derived from session 121 keys using generally accepted key derivation schemes, but the session 122 keys can be isolated from dynamic layers above HTTP. 124 2. Embedding SASL in HTTP 126 This specification integrates the SASL framework [RFC4422] into 127 mainstream HTTP [RFC7231], [RFC7232]. The SASL Authentication scheme 128 follows the general structure for HTTP Authentication [RFC7235]. It 129 uses the WWW-Authenticate and Proxy-Authenticate headers in responses 130 from web servers and web proxies, respectively, and correspondingly 131 the Authorization and Proxy-Authorization request header to answer to 132 requests. 134 The SASL service name for the following embedding of SASL is HTTP; 135 contrary to most other service names, it is spelled in uppercase, in 136 line with what has become general practice in Kerberos and GSSAPI. 138 Since SASL prescribes channel binding to occur relative to TLS 139 instead of to the application protocol, we can add that when the 140 HTTPS transport is used. Whether channel binding is used SHOULD 141 remain a configuration choice in HTTP software, as it might interfere 142 with intentional HTTPS proxying. Unintended proxying on the other 143 hand, might lead to tapping of credentials under certain SASL 144 mechanisms, and it may be considered helpful to prevent such 145 situations by requiring channel binding for those situations. HTTP 146 in general allows a user session to hop between connections, and 147 browsers are likely to do this; to support this, the support of tls- 148 server-end-point channel binding [Section 4 of [RFC5929]] is 149 RECOMMENDED. Specific HTTP clients may exercise more control over 150 connections to achieve stronger security; for those use cases, tls- 151 unique channel binding [Section 3 of [RFC5929]] is RECOMMENDED. 152 Generic web servers SHOULD support both forms of channel binding. 154 2.1. HTTP Request and Response Messages 156 This section defines a few names for HTTP request and response 157 messages, to be used in the remainder of this specification. 159 Initial Responses are HTTP responses that normally set a status code 160 401 or 407, and that are sent when the HTTP server decides to 161 initiate an authentication exchange. In addition, the server MAY 162 send Initial Responses in other responses, to indicate to the client 163 that it MAY try again to achieve better results [Section 4.1 of 164 [RFC7235]]. 166 Initial Requests are those HTTP requests that a client sends to 167 initiate a fresh SASL authentication. The identity SHOULD be 168 selected by the user independently from the URI; prior settings MAY 169 however be remembered by a client for the combination of resource 170 authority (scheme, host and possibly a separately communicated 171 resource user name) with the server-sent realm string. The server 172 can support a mixture of client identities for various roles or 173 access levels through variation of realm strings. There is no 174 current practice of server-side resource names in HTTP, but the 175 generic URI schema presents this logic and it is easy to imagine an 176 HTTP User header that a client could support. 178 Intermediate Responses are HTTP responses to SASL authentication, 179 with a status code set to 401 or 407. Intermediate Requests are 180 those HTTP requests that a client sends to continue a SASL 181 authentication after an Intermediate Response. 183 Positive Responses set a 200 status code to depict success. 184 Information in this response is provided in an Authentication-Info or 185 Proxy-Authentication-Info header [RFC7615] instead of the headers 186 used in Initial Responses and Intermediate Responses [RFC7235]. 187 Proper interpretation of a Positive Response requires client state 188 indicating that SASL authentication was used, or else the optional 189 fields are not completely reliable information sources; cryptographic 190 markers in the c2c field MAY be used to overcome this in a manner 191 that defies abuse by rogue servers. 193 Negative Responses also set a 401 or 407 status code and will often 194 return the client to an earlier state that it recognises as one it 195 has tried before. These responses should therefore offer 196 authentication to start again. In contrast to the Initial Response, 197 there is now a c2c field that helps the client evaluate the request. 199 The following fields, defined in upcoming sections, MUST and MAY be 200 present in HTTP authentication exchanges for SASL: 202 Request or Response | MUST have fields | MAY have fields 203 ----------------------+------------------+----------------- 204 Initial Response | s2s,mech | realm 205 Initial Request | mech | c2s,realm,s2s 206 Intermediate Response | s2s | s2c 207 Intermediate Request | s2s | c2s 208 Positive Response | | s2s 209 Negative Response | s2s,mech | realm 211 2.2. Authentication Field Definitions 213 Data for SASL is transported in the following fields: 215 c2s holds SASL token data from client to server. This field is 216 transmitted with base64 encoding. The field is absent when the 217 SASL client sends no token. 219 s2c holds SASL token data from server to client. This field is 220 transmitted with base64 encoding. The field is absent when the 221 SASL server sends no token. 223 s2s holds opaque server data which the client MUST reflect in 224 Intermediate Requests and, when responding to an Initial 225 Response, in the Initial Request. This is a necessity for a 226 stateless HTTP Authentication framework [Section 5.1.2 of 227 [RFC7235]]. It MAY be used in a Positive Response to pass a 228 cacheable Section 2.3 authentication token in a future Initial 229 Request. 231 The following fields support SASL within the HTTP Authentication 232 Framework: 234 realm optionally names a scope of authorisation under the 235 combination of scheme, server host name and possibly a HTTP 236 user to implement the semantics of the generic URI username for 237 resource selection. The realm does not necessarily match a 238 domain name, which is used elsewhere as a realm notation. 240 mech In an Initial Response, the field is filled with a space- 241 separated list of SASL mechanism names; In an Initial Request, 242 the client chooses one SASL mechanism name. 244 2.3. Caching Authentication Results 246 When an HTTP server sends a Positive Response, it MAY include an 247 "s2s" field. If it does this, then it should be prepared to accept 248 the field value for authentication in an Initial Request. However, 249 credentials can expire or fall in disgrace for other reasons, so the 250 server MAY still choose to reject the provided field. 252 When an HTTP client receives a Positive Response with an "s2s" field, 253 it MAY memorise the fields for future reuse in an Initial Request, 254 either with or without preceding Initial Response from the server. 255 The HTTP client MUST use the realm as part of the decision which 256 cached result to use, but it MAY extrapolate the results from one 257 resource retrieval in an attempt to authenticate another. 259 When cached fields result in a Negative Response then the HTTP client 260 SHOULD remove the failing cache entry, and it SHOULD try again by 261 going through a full SASL authentication cycle. The stateless nature 262 of HTTP authentication is helpful in the sense that a new Initial 263 Request can be sent to an older Initial Response. 265 3. Server-Side User Name 267 HTTP does not define a mechanism to specifically select the user as 268 an authoritative resource name space on the server. Local syntax 269 conventions exist, but lack universally reliable semantics. Basic 270 authentication has been used to this effect, but this conflates the 271 client identity with the server-side name space, which is not 272 necessarily the same. 274 To allow HTTP servers to zoom in on user-specific information, the 275 User header is hereby introduced. Its syntax matches the userinfo 276 part of a URI, up to but excluding any colons in it: 278 User = *( unreserved / pct-encoded / sub-delims ) 280 The value of the header MUST be percent-decoded before the server can 281 use it to identify a local user. 283 The User header MAY be sent by clients, and HTTP servers MAY ignore 284 it for any reason, including local user identities that do not comply 285 to a more restrictive local user name syntax. 287 When an HTTP server makes use of the User header, it MUST include a 288 Vary header in its response, with either a single "*" in it or the 289 name "User". This informs caches that the response must be 290 considered specific to the User header value in the matching request. 292 The User header may be used with or without any form of 293 authentication. When used with authentication, the value of the 294 percent-decoded header is considered part of the authority component 295 of the resource, and therefore of the naming scope for the realm. 296 Clients can use this refined notion of realm to select an 297 authentication identity; when the value is known early enough, this 298 may even help to select an X.509 client certificate. Note that the 299 User header might be used together with the aforementioned practice 300 of Basic authentication, but it can also replace it with an even 301 simpler mechanism to free up the authentication exchange for HTTP 302 SASL. 304 The distinction of a client-side user from a server-side user can 305 benefit the use of credential schemes that are not tied to the HTTP 306 server. A specific example of this is the current work on realm 307 crossover with GS2-SXOVER-PLUS. The use of such a mechanism may 308 offload security concerns from the application layer. 310 4. Authentication Session Example 312 This section is non-normative. 314 When an HTTP server receives a request for a protected page, it will 315 send an Initial Response to ask for authentication with a special 316 status code 401; for proxy access that would be 407, and header names 317 change accordingly. Stripped down to the bare essentials, the server 318 sends (this section adds whitespace for clarity) 320 HTTP/1.1 401 Unauthorized 321 WWW-Authenticate: SASL 322 realm="members only" 323 mech="SCRAM-SHA-256 SCRAM-SHA-256-PLUS 324 SCRAM-SHA-1 SCRAM-SHA-1-PLUS 325 GS2-KRB5-PLUS GS2-KRB5", 326 s2s="[xxxxx]" 328 The server offers SCRAM-* and GS2-KRB5 mechanisms. The variants with 329 -PLUS provide additional channel binding, to ensure that 330 authentication is specific to the current HTTPS connection, thus 331 avoiding replay of the session across connections. Clients aware of 332 HTTP connections may use connection-specific channel binding (tls- 333 unique) while those that abstract from the connections must resort to 334 weaker name-based channel binding (tls-server-end-point). 336 The server might have additionally offered the ANONYMOUS mechanism to 337 allow the client to select "guest mode" access; the interaction would 338 continue as authenticated, but presumably with limited access to HTTP 339 resources and continued WWW-Authenticate headers to continue to offer 340 authentication to improve resource information content. The server 341 might have offered EXTERNAL to allow the client to incorporate a TLS 342 credential for authentication and possibly change to an authorization 343 identity. The server might have offered GS2-SXOVER-PLUS if it is 344 willing to connect to the client's home realm over Diameter, and 345 thereby support realm crossover of SASL credentials. 347 The client initiates the SCRAM-SHA-256-PLUS mechanism, and to that 348 end sends an Initial Request (this section shows square brackets 349 around text that is transmitted with base64-encoding) 351 Authorization: SASL 352 realm="members only" 353 mech="SCRAM-SHA-256-PLUS", 354 c2s="[n,,n=user,r=rOprNGfwEbeRWgbNEkqO]", 355 s2s="[xxxxx]" 357 This mechanism is initiated by the client, hence the inclusion of the 358 c2s token in the Initial Request. The contents of this field are 359 specific to the selected mechanism, so SCRAM-SHA-256-PLUS in this 360 case. 362 The SCRAM mechanism implementation is now initiated with the c2s 363 token, and the server produces a followup challenge in a s2c token. 364 To be able to validate future client messages against server-side 365 state, it includes such state in an s2s token. This token is 366 presumably protected from abuse with a signature and/or encryption, 367 and it would likely identify the selected mechanism to validate 368 during later rounds. The server packs all this in an Intermediate 369 Response 371 HTTP/1.1 401 Unauthorized 372 WWW-Authentication: SASL 373 s2c="[r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxF 374 Ilj)hNlF$k0,s=W22ZaJ0SNY7soEsUEjb6gQ==, 375 i=4096]" 376 s2s="[yyyyy]" 378 Given that all server state is contained in this message, the client 379 is free at any time to give up authentication and perhaps try another 380 method. Normally however, it would proceed with the ongoing 381 transaction. 383 The SCRAM mechanism continues with another round. The client engages 384 in the prescribed cryptographic computations and packs an 385 Intermediate Request along with updated state in the new c2s token 387 Authorization: SASL 388 c2s="[c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hN 389 lF$k0,p=dHzbZapWIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=]" 390 s2s="[yyyyy]" 392 When the client has performed authentication properly, as determined 393 by a server-side check of the c2s response token with the prior state 394 in the s2s token, it can send a Positive Response along with the 395 requested resource 397 HTTP/1.1 200 OK 398 WWW-Authentication: SASL 399 s2c="[v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=]" 400 s2s="[zzzzz]" 402 The s2s token in a Positive Response is an optional extension. It is 403 presented by the server to allow the client to speed up 404 authentication in future requests. The client may send it whenever 405 the server asks for the same realm string under the same scheme and 406 authority; the client may make proactive assumpions about the realm 407 string for new requests. Authentication must never be reused in 408 another context than bound by channel binding. When used, the client 409 immediate sends an Intermediate Response holding 411 Authorization: SASL 412 realm="members only" 413 s2s="[zzzzz]" 415 The server always has an option to refuse repeated authentication and 416 forcing the client into a new authentication round. One reason for 417 this could be that a session timed out. Another might be that the 418 client is trying to use a credential outside a scope set by channel 419 binding. 421 5. Security Considerations 423 It is not generally safe for SASL mechanisms to exchange c2s and s2c 424 messages over unprotected transports. Furthermore, the SASL exchange 425 may be at risk of tampering when the sequence of HTTP messages is not 426 secured to form one stream. This means that a secure transport layer 427 must be used, like TLS. The termination of such a secure layer MUST 428 also terminate any ongoing SASL handshakes. 430 The s2s field MUST be protected against tampering by rogue peers, and 431 such protection also protects against tampering by rogue 432 intermediates when using an unprotected transport. In addition, but 433 dependent on the mechanism used, the s2s field may also need 434 encryption to conceal their data from peers and intermediates. 436 SASL EXTERNAL can be a very efficient mechanism to combine with a 437 secure transport layer if that includes authentication. This may be 438 the case for TLS, especially when client-side authentication is 439 deployed. Mechanisms other than EXTERNAL should take into account 440 that a relation may exist between identities negotiated in the 441 protective layer and the SASL exchange over HTTP. For example, a 442 login account may be exchanged for an alias or group identity. 444 Channel binding is available in some SASL mechanisms. When used with 445 HTTP SASL over TLS, it binds to the TLS channel. When doing so, it 446 is vital that either there be no renegotiation of the TLS handshake, 447 or both secure renegotiation [RFC5746] and the extended master secret 448 [RFC7627] are used. 450 The User header field as defined herein is orthogonal to issues of 451 authentication and authorisation, and adds no security concerns. 453 6. IANA Considerations 455 This specification extends the "Hypertext Transfer Protocol (HTTP) 456 Authentication Scheme Registry" with an "Authentication Scheme Name" 457 SASL, referencing this specification. 459 This specification defines an additional entry in the registry 460 "Generic Security Service Application Program Interface 461 (GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL) 462 Service Names" namely: 464 Service Name: HTTP 465 Usage: Web authentication using the SASL framework 466 Reference: TBD:this specification 468 The capitalisation of the service name has historic origins and is 469 now the preferred spelling for reasons of compatibility. 471 Please add the following entry to the Message Headers registry: 473 Header Field Name Template Protocol Status Reference 474 ------------------ --------- --------- ------- ---------- 475 User http TBD TBD:THIS_SPEC 477 7. References 478 7.1. Normative References 480 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 481 Kerberos Network Authentication Service (V5)", RFC 4120, 482 DOI 10.17487/RFC4120, July 2005, 483 . 485 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 486 Kerberos and NTLM HTTP Authentication in Microsoft 487 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 488 . 490 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 491 Authentication and Security Layer (SASL)", RFC 4422, 492 DOI 10.17487/RFC4422, June 2006, 493 . 495 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 496 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 497 . 499 [RFC5554] Williams, N., "Clarifications and Extensions to the 500 Generic Security Service Application Program Interface 501 (GSS-API) for the Use of Channel Bindings", RFC 5554, 502 DOI 10.17487/RFC5554, May 2009, 503 . 505 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 506 "Transport Layer Security (TLS) Renegotiation Indication 507 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 508 . 510 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 511 Service Application Program Interface (GSS-API) Mechanisms 512 in Simple Authentication and Security Layer (SASL): The 513 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 514 July 2010, . 516 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 517 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 518 . 520 [RFC6595] Wierenga, K., Lear, E., and S. Josefsson, "A Simple 521 Authentication and Security Layer (SASL) and GSS-API 522 Mechanism for the Security Assertion Markup Language 523 (SAML)", RFC 6595, DOI 10.17487/RFC6595, April 2012, 524 . 526 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 527 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 528 DOI 10.17487/RFC7231, June 2014, 529 . 531 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 532 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 533 DOI 10.17487/RFC7232, June 2014, 534 . 536 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 537 Protocol (HTTP/1.1): Authentication", RFC 7235, 538 DOI 10.17487/RFC7235, June 2014, 539 . 541 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 542 Authentication-Info Response Header Fields", RFC 7615, 543 DOI 10.17487/RFC7615, September 2015, 544 . 546 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 547 Langley, A., and M. Ray, "Transport Layer Security (TLS) 548 Session Hash and Extended Master Secret Extension", 549 RFC 7627, DOI 10.17487/RFC7627, September 2015, 550 . 552 7.2. Informative References 554 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 555 "Salted Challenge Response Authentication Mechanism 556 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 557 DOI 10.17487/RFC5802, July 2010, 558 . 560 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 561 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 562 March 2016, . 564 [I-D.vanrein-dnstxt-krb1] 565 Rein, R., "Declaring Kerberos Realm Names in DNS 566 (_kerberos TXT)", Work in Progress, Internet-Draft, draft- 567 vanrein-dnstxt-krb1-09, 24 October 2016, 568 . 571 Appendix A. HTTP Server Environment Variables 573 We define a number of variables that SHOULD be passed from an HTTP 574 SASL stack (and from User header processing) to applications run on 575 top of it. The intention of defining these is to obtain maximum 576 interoperability between these layers of software. 578 The following variables MUST NOT be available until SASL 579 authentication is successful; it would be available when the server 580 could send a 200 OK response: 582 SASL_SECURE is only "yes" (without the quotes) when a client is 583 authenticated to the current resource. It never has another 584 value; it is simply undefined when not secured by SASL. 586 SASL_REALM is the realm for which the secure exchange succeeded. A 587 realm is not always used, because sites only need it when there 588 are more than one in the same name space. When undefined in 589 the SASL flow, this variable will not be set. 591 REMOTE_USER is the client identity as confirmed through SASL 592 authentication. Its content is formatted like an email 593 address, and includes a domain name. That domain need not be 594 related to the web server; it is possible for a web server to 595 welcome foreign clients. 597 SASL_MECH indicates the mechanism used, and is one of the 598 standardised SASL mechanism names. It may be used to detect 599 the level of security. 601 SASL_S2S holds the accepted s2s field, and could be used as a random 602 session identifier. It would normally be encrypted 603 information. 605 SASL_S2S_ is a prefix for extra information that the server may 606 extract from the s2s field in the HTTP SASL protocol flow. 607 This depends on the authentication stack used in the web 608 server. 610 The following variable SHOULD be available while processing a request 611 with a User header with locally acceptable syntax: 613 LOCAL_USER gives the HTTP User header value after syntax checking 614 and percent-decoding. If used at all, it MUST be treated as a 615 resource name space selector. This header does not describe 616 the authenticated client identity, which is usually passed in a 617 variable REMOTE_USER. 619 Appendix B. Acknowledgements 621 Thanks to Henri Manson for making the first implementation of this 622 specification and for feedback on the header formats. The 623 specification also benefited from input by Daniel Stenberg. 625 This work was supported with an open source development fund from 626 NLNet. 628 Author's Address 630 Rick van Rein 631 ARPA2.net 632 Haarlebrink 5 633 Enschede 635 Email: rick@openfortress.nl