idnits 2.17.1 draft-vanrein-httpauth-sasl-02.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 142: '...Whether channel binding is used SHOULD...' RFC 2119 keyword, line 177: '...in the c2c field MAY be used to overco...' RFC 2119 keyword, line 181: '... in upcoming sections, MUST and MAY be...' RFC 2119 keyword, line 184: '... or Response | MUST have fields |...' RFC 2119 keyword, line 204: '... data which the client MUST reflect in...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 235 has weird spacing: '...serview selec...' == Line 245 has weird spacing: '... mech selec...' == Line 252 has weird spacing: '... name is th...' == Line 254 has weird spacing: '... text is a ...' -- The document date (April 10, 2019) is 1843 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 422, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 4559 ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7615 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 5 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 April 10, 2019 5 Expires: October 12, 2019 7 HTTP Authentication with SASL 8 draft-vanrein-httpauth-sasl-02 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 October 12, 2019. 35 Copyright Notice 37 Copyright (c) 2019 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 3. Support for Realm Crossover . . . . . . . . . . . . . . . . . 6 57 3.1. Encrypting SASL for Realm Crossover . . . . . . . . . . . 7 58 3.2. Viewing Users on HTTP Services . . . . . . . . . . . . . 7 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 63 6.2. Informative References . . . . . . . . . . . . . . . . . 11 64 Appendix A. HTTP Server Environment Variables . . . . . . . . . 11 65 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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 and AMQP. 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 has 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 is beneficial in both directions. HTTP benefits by being 94 able to use anything from strong password mechanisms [RFC5802] 95 without explicit support [RFC7804] in applications, up to GS2 96 mechanisms [RFC5801] with channel binding [RFC5056] [RFC5554] to TLS 97 [RFC5929] based on pinning either the certificate for the TLS server 98 or even a unique part of the individual TLS connection; for instance 99 Kerberos5 [RFC4120] currently uses Negotiate authentication [RFC4559] 100 which is not as secure as 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, becuase 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 TODO: Does this do justice to current SAML over HTTP? 112 In terms of security for HTTP applications, it appears beneficial to 113 have very good authentication capabilities in the layers below the 114 application; this is specifically true for applications developed in 115 HTML and JavaScript, which tend to load code from various places, 116 including code that is not always in the end user's interest; since 117 it already is a concern what identity information passes through 118 these applications, it is certainly not advisable to use credentials 119 in those places. Browsers are in a better position to take control 120 over these assets, at the protocol levels of HTTP and TLS, and 121 conceal credentials and possibly also identity from applications 122 running on top. Inasfar as tokens are needed, they can be derived 123 from session keys using generally accepted key derivation schemes, 124 but the session keys can be isolated from dynamic layers above HTTP. 126 2. Embedding SASL in HTTP 128 This specification integrates the SASL framework [RFC4422] into 129 mainstream HTTP [RFC2616]. The SASL Authentication scheme follows 130 the general structure for HTTP Authentication [RFC7235]. It uses the 131 WWW-Authenticate and Proxy-Authenticate headers in responses from web 132 servers and web proxies, respectively, and correspondingly the 133 Authorization and Proxy-Authorization request header to answer to 134 requests. 136 The SASL service name for the following embedding of SASL is HTTP; 137 contrary to most other service names, it is spelled in uppercase, in 138 line with what has become general practice in Kerberos and GSSAPI. 140 Since SASL prescribes channel binding to occur relative to TLS 141 instead of to the application protocol, we can add that when the 142 HTTPS transport is used. Whether channel binding is used SHOULD 143 remain a configuration choice in HTTP software, as it might interfere 144 with intentional HTTPS proxying. Unintended proxying on the other 145 hand, might lead to tapping of credentials under certain SASL 146 mechanisms, and it may be considered helpful to prevent such 147 situations by relying on channel binding for at least those 148 mechanisms. 150 2.1. HTTP Request and Response Messages 152 This section defines a few names for HTTP request and response 153 messages, to be used in the remainder of this specification. 155 Initial Responses are those HTTP responses that set a status code 401 156 or 407, and that are sent when the HTTP server decides to initiate an 157 authentication exchange. 159 Initial Requests are those HTTP requests that a client sends to 160 initiate a fresh SASL authentication. User-Aware Requests are a 161 variation defined further below, intended for attempts to address 162 public resources under a given user name. 164 Intermediate Responses are HTTP responses to SASL authentication, 165 with a status code set to 401 or 407. Intermediate Requests are 166 those HTTP requests that a client sends to continue a SASL 167 authentication after an Intermediate Response. 169 Final Responses either set a 200 or 403 status code, the first 170 depicting success and the second depicting failure. Information in a 171 Final 200 Response is provided in an Authentication-Info or Proxy- 172 Authentication-Info header [RFC7615] instead of the headers used in 173 Initial Responses and Intermediate Responses [RFC7235]. Note that 174 proper interpretation of the Final 200 Response requires client state 175 indicating that SASL authentication was used, or else the optional 176 fields are not completely reliable information sources; cryptographic 177 markers in the c2c field MAY be used to overcome this in a manner 178 that defies abuse by rogue servers. The Final 403 Response never 179 contains authentication-related headers. 181 The following fields, defined in upcoming sections, MUST and MAY be 182 present in HTTP authentication exchanges for SASL: 184 Request or Response | MUST have fields | MAY have fields 185 ----------------------+---------------------+---------------------- 186 Unauth Request | | userview 187 Initial Response | mech,s2s,realm | text 188 Initial Request | mech,s2s,c2c,realm | c2s,userview 189 Intermediate Response | mech,c2c,s2c,s2s | text 190 Intermediate Request | mech,c2c,c2s,s2s | userview 191 Final 200 Response | mech,c2c,name,realm | s2s 192 Final 403 Response | | 194 2.2. Authentication Field Definitions 196 Data for SASL is transported in the following fields: 198 c2s holds SASL mechanism-specific data from client to server, 199 usually encrypted during realm crossover. 201 s2c holds SASL mechanism-specific data from server to client, 202 usually encrypted during realm crossover. 204 s2s holds opaque server data which the client MUST reflect in 205 Intermediate Requests, to implement stateless SASL handling in 206 the server. This is a requirement for the HTTP Authentication 207 framework [Section 5.1.2 of [RFC7235]]. 209 c2c holds opaque client data which the server MUST reflect in 210 Intermediate Responses and Final 200 Responses. This can help 211 to also make the client stateless. 213 As in other protocols, it is not safe for all SASL mechanisms to 214 exchange c2s and s2c messages over unprotected transports. The c2c 215 and s2s fields MUST be protected against tampering by rogue peers, 216 and such protection also protects against tampering by rogue 217 intermediates when using an unprotected transport. In addition, c2c 218 and s2s fields may also need to be concealed from peers and 219 intermediates. 221 Whether s2c is supplied in a Final 200 Response depends on the SASL 222 mechanism, which may or may not have additional data to provide in 223 this phase. Note that SASL requires empty s2c messages to be 224 distinguished from absence thereof. When the server provides c2s 225 and/or s2s data in a Final 200 Response, then it indicates that the 226 supplied fields MAY provide one-step re-authentication with an empty 227 s2c string, but the server MAY revoke this privilege at any time and 228 for any reason; it would respond with an Initial Response in case of 229 such revocation, but with a quick Final 200 Response if the one-step 230 re-authentication is still acceptable. 232 The following fields support SASL within the HTTP Authentication 233 Framework: 235 userview selects a user view on the resources accessible over HTTP. 236 This data selection purpose is unrelated to authentication. As 237 a general principle, the userview MAY lead to changes in 238 authentication triggers for URI paths, but MUST NOT change 239 authentication triggers for the underlying resources. 241 realm optionally names a scope of authorisation under the combination 242 of scheme, server host name and userview. This does not 243 signify a realm in the sense of realm crossover. 245 mech selects the SASL mechanism to use. It MUST be reflected from 246 the preceding message, except: In an Initial Response, the 247 field is filled with a space-separated list of SASL mechanism 248 names; In an Initial Request, the client chooses one SASL 249 mechanism name; In a User-Aware Request, the field is fixated 250 to ANONYMOUS [RFC4505]. 252 name is the authorised user@domain.name or domain.name identity. 254 text is a user-oriented text explaining what information is needed. 256 3. Support for Realm Crossover 258 HTTP services tend to define users as part of their own secure realm. 259 This culminates in competitions over user names in the most popular 260 services. It also leads to variations in user names across services, 261 difficult to both users and their contacts. More seriously, it leads 262 to uncertainty about the same-ness of users at different services. 263 Anyone can claim the name of your bank, lacking a trust basis for 264 such names. 266 A more flexible model allows the client to determine their names, and 267 locate them under their own domain. Provided that services use 268 domain-specific methods for identity assurance, the client can be 269 represented by their complete form, and no concern of same-ness of 270 users names across such services need exist. As a pleasant side- 271 effect, the competition over user names has become a local matter, to 272 be resolved by the client. 274 HTTP SASL supports this model. The format of a user identity is 275 formalised to be a Network Access Identifier [RFC7542] of the form 277 nai_clientid ::= utf8-username "@" utf8-realm 279 The nai_clientid is reported back from SASL to the HTTP service. In 280 the case of realm crossover, it may be provided from a Diameter 281 backend from the client's home realm. When it is provided, it has 282 been validated, but the HTTP server should check the realm to match 283 the expected domain name. See Appendix A for the mechanism of 284 dissiminating such information from an HTTP server to an application 285 service. 287 It is anticipated that HTTP resources will be subjected to access 288 control rules that applied to client identities inclusive of their 289 realm. This model can be supportive of local users as well as 290 foreign ones. 292 3.1. Encrypting SASL for Realm Crossover 294 Most SASL methods are unsafe to use over plaintext channels; it is a 295 common and good practice to run it over a secure channel such as TLS. 296 This is precisely the condition of HTTP SASL with server-based 297 accounts. But TLS only protects the direct link between a client and 298 a server; during realm crossover the server might effectively be a 299 man-in-the-middle. This is especially true when a SASL backend in 300 the client's domain is asked to perform the authentication for the 301 HTTP server. 303 The solution for realm crossover is to encrypt the SASL traffic 304 between the client and its backend authentication service in the home 305 realm. Since the client and backend authentication service know each 306 other, they can resort to simple mechanisms such as symmetric 307 encryption and integrity checking. The SASL mechanism SXOVER has 308 been designed with that idea in mind, and it can be passed on to the 309 backend via Diameter, which can also carry along channel binding 310 information and which will report back to the relying service. 312 Encryption MAY be requested by selecting SXOVER as the SASL mechanism 313 during the Initial Request, which itself is not yet a sensitive 314 message. SXOVER starts by naming the home domain for the client, 315 readable to the HTTP server to help it find a backend. The first 316 SXOVER message also establishes a cloak, under which a second SASL 317 handshake will be made, invisible to the HTTP process except as a 318 sequence of messages to pass. Encryption SHOULD be used if an AT 319 character U+0040 is sent as part of a client identity. 321 A separate specification [TODO:REF:draft-vanrein-diameter-sasl] 322 introduces a mapping of SASL into Diameter messages, forming a cloak 323 under which the actual SASL authentication method is offered, 324 selected and executed. 326 3.2. Viewing Users on HTTP Services 328 The initial authentication mechanisms for HTTP were Basic and Digest 329 [RFC2617] but these are no longer considered secure. These forms 330 used the username in the URI together with a password, a combination 331 that is now officially deprecated [Section 3.2.1 of [RFC3986]]. 333 The use of a user name in a URI has not been deprecated, but has been 334 withdrawn from HTTP because it was not included in the core HTTP 335 specification [RFC2616]. With client identities that support realm 336 crossover, it is possible to add this to SASL Authorization headers, 337 through a new siteuser field, to be used like this: 339 GET / HTTP/1.1 340 Host: www.example.net 341 Authorization: SASL userview=snowboarders 343 There is a clear need for users in HTTP URIs, as can be seen from a 344 wild variation of mappings into paths are sub-domains. The actual 345 use of the username part of the URI is however preferrable, and the 346 URI format defines it in the authority part [Section 3.2 of 347 [RFC3986]] which seems to match with the intended uses. A URI-based 348 user name will probaly still be mapped to a path on a server, but 349 need not be shown in the path in the URI. Better standardisation of 350 user names is supportive of better integration with tools on both the 351 client and server side. 353 We emphasise that the userview and client identity are orthogonal 354 concepts, except for the special case where the client is viewing his 355 own resources. This implies that it can be used with or without 356 authentication. The userview field indicates the name space of 357 resources beig addressed, while the client identity is involved in 358 access rights. 360 The reason to integrate the userview with SASL is one of identity 361 control; when the userview changes, one is visiting another part of a 362 HTTP resource space, and it may then be proper to switch to another 363 identity. This is in line with the scoping of protection spaces 364 [Section 2.2 of [RFC7235]] to combinations of URI scheme, URI 365 authority section and a server-defined realm string, where the URI 366 authority section includes the user name in the URI. 368 Browsers currently show varying behaviours when supplied with a user 369 name. This is mostly due to the deprecation [Section 3.2.1 of 370 [RFC3986]] of userparts with a password embedded. Unfortunately, 371 this also means that user names in HTTP URIs are sometimes suppressed 372 or warned about. The userview field is intended to present a 373 constructive alternative, where user names may once more be used to 374 scope the resource name space to that of a user, without saying 375 anything about authentication at all. 377 4. Security Considerations 379 The SASL exchange may be at risk of tampering when the sequence of 380 HTTP messages is not secured to form one stream. The termination of 381 such a secure layer MUST also terminate an ongoing SASL handshake. 383 SASL EXTERNAL can be a very efficient mechanism to combine with a 384 secure transport layer if that includes authentication. This may be 385 the case for TLS, especially when client-side authentication is 386 deployed. Mechanisms other than EXTERNAL should take into account 387 that a relation may exist between identities negotiated in the 388 protective layer and the SASL exchange over HTTP. 390 Channel binding is available in some SASL mechanisms. When used with 391 HTTP SASL over TLS, it binds to the TLS channel, by default using the 392 type tls-unique [Section 3 of [RFC5929]]. When doing so, it is vital 393 that either there be no renegotiation of the TLS handshake, or both 394 secure renegotiation [RFC5746] and the extended master secret 395 [RFC7627] are used. 397 5. IANA Considerations 399 This specification extends the "Hypertext Transfer Protocol (HTTP) 400 Authentication Scheme Registry" with an "Authentication Scheme Name" 401 SASL, referencing this specification. 403 This specification defines an additional entry in the registry 404 "Generic Security Service Application Program Interface 405 (GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL) 406 Service Names" namely: 408 Service Name: HTTP 409 Usage: Web authentication using the SASL framework 410 Reference: TBD:this specification 412 6. References 414 6.1. Normative References 416 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 417 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 418 Transfer Protocol -- HTTP/1.1", RFC 2616, 419 DOI 10.17487/RFC2616, June 1999, 420 . 422 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 423 Resource Identifier (URI): Generic Syntax", STD 66, 424 RFC 3986, DOI 10.17487/RFC3986, January 2005, 425 . 427 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 428 Kerberos Network Authentication Service (V5)", RFC 4120, 429 DOI 10.17487/RFC4120, July 2005, 430 . 432 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 433 Authentication and Security Layer (SASL)", RFC 4422, 434 DOI 10.17487/RFC4422, June 2006, 435 . 437 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 438 Kerberos and NTLM HTTP Authentication in Microsoft 439 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 440 . 442 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 443 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 444 . 446 [RFC5554] Williams, N., "Clarifications and Extensions to the 447 Generic Security Service Application Program Interface 448 (GSS-API) for the Use of Channel Bindings", RFC 5554, 449 DOI 10.17487/RFC5554, May 2009, 450 . 452 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 453 "Transport Layer Security (TLS) Renegotiation Indication 454 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 455 . 457 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 458 Service Application Program Interface (GSS-API) Mechanisms 459 in Simple Authentication and Security Layer (SASL): The 460 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 461 July 2010, . 463 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 464 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 465 . 467 [RFC6595] Wierenga, K., Lear, E., and S. Josefsson, "A Simple 468 Authentication and Security Layer (SASL) and GSS-API 469 Mechanism for the Security Assertion Markup Language 470 (SAML)", RFC 6595, DOI 10.17487/RFC6595, April 2012, 471 . 473 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 474 Protocol (HTTP/1.1): Authentication", RFC 7235, 475 DOI 10.17487/RFC7235, June 2014, 476 . 478 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 479 DOI 10.17487/RFC7542, May 2015, 480 . 482 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 483 Authentication-Info Response Header Fields", RFC 7615, 484 DOI 10.17487/RFC7615, September 2015, 485 . 487 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 488 Langley, A., and M. Ray, "Transport Layer Security (TLS) 489 Session Hash and Extended Master Secret Extension", 490 RFC 7627, DOI 10.17487/RFC7627, September 2015, 491 . 493 6.2. Informative References 495 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 496 Leach, P., Luotonen, A., and L. Stewart, "HTTP 497 Authentication: Basic and Digest Access Authentication", 498 RFC 2617, DOI 10.17487/RFC2617, June 1999, 499 . 501 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 502 Security Layer (SASL) Mechanism", RFC 4505, 503 DOI 10.17487/RFC4505, June 2006, 504 . 506 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 507 "Salted Challenge Response Authentication Mechanism 508 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 509 DOI 10.17487/RFC5802, July 2010, 510 . 512 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 513 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 514 March 2016, . 516 Appendix A. HTTP Server Environment Variables 518 We define a number of variables that SHOULD be passed from an HTTP 519 SASL stack to applications run on top of it. The intention of 520 defining these is to obtain maximum interoperability between these 521 layers of software. 523 A common practice is to set environment variables with a given name 524 to values that may be meaningful to applications. Those applications 525 should be mindful about the possible meaning of absent variables. 527 The following variables MAY be available in both the SASL 528 authenticated and unauthenticated state: 530 SASL_SITEVIEW refers to the user name in the URI and SHOULD NOT be 531 used with a password. It refines the view on resources held by 532 the web server, usually from a general site to one that is 533 user-specific. The URI user is considered local to the web 534 server (and, as a result of that, often its domain or security 535 realm). This variable is only set when it is provided through 536 the siteview field in the SASL exchange. 538 SASL_VISITOR refers to self-identification of the client independent 539 of authentication. Its general form is that of an email 540 address, but its local part MAY be empty. This variable may be 541 used to determine the domain against which the client intends 542 to authenticate and, from that, the SASL mechanisms that can be 543 offered. 545 The following variables MUST NOT be available until SASL 546 authentication is successful; it would be available when the server 547 could send a 200 OK response: 549 SASL_SECURE is only "yes" (without the quotes) when a client is 550 authenticated to the current resource. It never has another 551 value; it is simply undefined when not secured by SASL. 553 SASL_REALM is the realm for which the secure exchange succeeded. A 554 realm is not always used, because sites only need it when there 555 are more than one in the same name space. When undefined in 556 the SASL flow, this variable will not be set. 558 SASL_CLIENTID is the identity as confirmed through SASL 559 authentication. Its content is formatted like an email 560 address, and includes a domain name. That domain need not be 561 related to the web server; it is possible for a web server to 562 welcome foreign clients. 564 SASL_MECH indicates the mechanism used, and is one of the 565 standardised SASL mechanism names. It may be used to detect 566 the level of security. 568 SASL_S2S holds the accepted s2s field, and could be used as a random 569 session identifier. It would normally be encrypted 570 information. 572 SASL_S2S_ is a prefix for extra information that the server may 573 extract from the s2s field in the HTTP SASL protocol flow. 575 This depends on the authentication stack used in the web 576 server. 578 Appendix B. Acknowledgements 580 Thanks to Henri Manson for making the first implementation of this 581 specification and for feedback on the header formats. 583 Author's Address 585 Rick van Rein 586 ARPA2.net 587 Haarlebrink 5 588 Enschede, Overijssel 7544 WP 589 The Netherlands 591 Email: rick@openfortress.nl