idnits 2.17.1 draft-vanrein-httpauth-sasl-01.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 175: '...in the c2c field MAY be used to overco...' RFC 2119 keyword, line 179: '... in upcoming sections, MUST and MAY be...' RFC 2119 keyword, line 182: '... or Response | MUST have fields |...' RFC 2119 keyword, line 203: '... data which the client MUST reflect in...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 212 has weird spacing: '... encalg ident...' == Line 217 has weird spacing: '... enckey is an...' == Line 243 has weird spacing: '...serview selec...' == Line 252 has weird spacing: '... mech selec...' == Line 259 has weird spacing: '...visitor is a ...' == (2 more instances...) -- The document date (November 8, 2018) is 1997 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 478, but no explicit reference was found in the text == Unused Reference: 'RFC5056' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC4505' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC5785' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC5802' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC7804' is defined on line 577, 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) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 3 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 November 8, 2018 5 Expires: May 12, 2019 7 HTTP Authentication with SASL 8 draft-vanrein-httpauth-sasl-01 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 May 12, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 . . . . . . . . . . . 8 58 3.2. Viewing Users on HTTP Services . . . . . . . . . . . . . 9 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 63 6.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 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 GS2 mechanisms [RFC5801] with channel binding [RFC5554] 95 to TLS [RFC5929] based on pinning either the certificate for the TLS 96 server or even a unique part of the individual TLS connection; for 97 instance Kerberos5 [RFC4120] currently uses Negotiate authentication 98 [RFC4559] which is not as secure as GS2-KRB5-PLUS over SASL. 100 SASL also benefits; had it been the norm for HTTP, then the work to 101 pass SAML over it [RFC6595] would probably have been done 102 immediately. In fact, HTTP can still benefit from receiving 103 standardised SAML20 inquiries over SASL, becuase it resolves the need 104 for configuration of initiation paths and practices. Also, it 105 removes authentication data from URIs, where they are not ideally 106 placed. 108 TODO: Does this do justice to current SAML over HTTP? 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 certainly not advisable to use credentials 117 in those places. Browsers are in a better position to take control 118 over these assets, at the protocol levels of HTTP and TLS, and 119 conceal credentials and possibly also identity from applications 120 running on top. Inasfar as tokens are needed, they can be derived 121 from session keys using generally accepted key derivation schemes, 122 but the session 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 [RFC2616]. The SASL Authentication scheme follows 128 the general structure for HTTP Authentication [RFC7235]. It uses the 129 WWW-Authenticate and Proxy-Authenticate headers in responses from web 130 servers and web proxies, respectively, and correspondingly the 131 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 relying on channel binding for at least those 146 mechanisms. 148 2.1. HTTP Request and Response Messages 150 This section defines a few names for HTTP request and response 151 messages, to be used in the remainder of this specification. 153 Initial Responses are those HTTP responses that set a status code 401 154 or 407, and that are sent when the HTTP server decides to initiate an 155 authentication exchange. 157 Initial Requests are those HTTP requests that a client sends to 158 initiate a fresh SASL authentication. User-Aware Requests are a 159 variation defined further below, intended for attempts to address 160 public resources under a given user name. 162 Intermediate Responses are HTTP responses to SASL authentication, 163 with a status code set to 401 or 407. Intermediate Requests are 164 those HTTP requests that a client sends to continue a SASL 165 authentication after an Intermediate Response. 167 Final Responses either set a 200 or 403 status code, the first 168 depicting success and the second depicting failure. Information in a 169 Final 200 Response is provided in an Authentication-Info or Proxy- 170 Authentication-Info header [RFC7615] instead of the headers used in 171 Initial Responses and Intermediate Responses [RFC7235]. Note that 172 proper interpretation of the Final 200 Response requires client state 173 indicating that SASL authentication was used, or else the optional 174 fields are not completely reliable information sources; cryptographic 175 markers in the c2c field MAY be used to overcome this in a manner 176 that defies abuse by rogue servers. The Final 403 Response never 177 contains authentication-related headers. 179 The following fields, defined in upcoming sections, MUST and MAY be 180 present in HTTP authentication exchanges for SASL: 182 Request or Response | MUST have fields | MAY have fields 183 ----------------------+---------------------+-------------------- 184 Unauth Request | | userview,visitor 185 Initial Response | mech,s2s,realm | encalg,enckid,text 186 Initial Request | mech,s2s,c2c,realm | encalg,enckid,c2s, 187 | | userview,visitor 188 Intermediate Response | mech,c2c,s2c,s2s | text 189 Intermediate Request | mech,c2c,c2s,s2s | userview,visitor 190 Final 200 Response | mech,c2c,name,realm | s2s 191 Final 403 Response | | 193 2.2. Authentication Field Definitions 195 Data for SASL is transported in the following fields: 197 c2s holds SASL mechanism-specific data from client to server, 198 usually encrypted during realm crossover. 200 s2c holds SASL mechanism-specific data from server to client, 201 usually encrypted during realm crossover. 203 s2s holds opaque server data which the client MUST reflect in 204 Intermediate Requests, to implement stateless SASL handling in 205 the server. This is a requirement for the HTTP Authentication 206 framework [Section 5.1.2 of [RFC7235]]. 208 c2c holds opaque client data which the server MUST reflect in 209 Intermediate Responses and Final 200 Responses. This can help 210 to also make the client stateless. 212 encalg identifies an encryption algorithm to protect the c2s and s2c 213 fields, especially during realm crossover. When this field is 214 absent, the c2s and s2c fields are not encrypted but literally 215 follow the SASL mechanism exchange. 217 enckey is an identity of the encryption key used under encalg. The 218 fields enckey and encalg MUST always be paired; either both are 219 present, or both are absent. 221 As in other protocols, it is not safe for all SASL mechanisms to 222 exchange c2s and s2c messages over unprotected transports. The c2c 223 and s2s fields MUST be protected against tampering by rogue peers, 224 and such protection also protects against tampering by rogue 225 intermediates when using an unprotected transport. In addition, c2c 226 and s2s fields may also need to be concealed from peers and 227 intermediates. 229 Whether s2c is supplied in a Final 200 Response depends on the SASL 230 mechanism, which may or may not have additional data to provide in 231 this phase. Note that SASL requires empty s2c messages to be 232 distinguished from absence thereof. When the server provides c2s 233 and/or s2s data in a Final 200 Response, then it indicates that the 234 supplied fields MAY provide one-step re-authentication with an empty 235 s2c string, but the server MAY revoke this privilege at any time and 236 for any reason; it would respond with an Initial Response in case of 237 such revocation, but with a quick Final 200 Response if the one-step 238 re-authentication is still acceptable. 240 The following fields support SASL within the HTTP Authentication 241 Framework: 243 userview selects a user view on the resources accessible over HTTP. 244 This data selection purpose is unrelated to authentication. As 245 a general principle, the userview MAY lead to changes in 246 authentication triggers for URI paths, but MUST NOT change 247 authentication triggers for the underlying resources. 249 realm optionally names a scope of authorisation under the combination 250 of scheme, server host name and userview. 252 mech selects the SASL mechanism to use. It MUST be reflected from 253 the preceding message, except: In an Initial Response, the 254 field is filled with a space-separated list of SASL mechanism 255 names; In an Initial Request, the client chooses one SASL 256 mechanism name; In a User-Aware Request, the field is fixated 257 to ANONYMOUS. 259 visitor is a hint that suggests an unauthenticated client identity. 260 It cannot be used as a basis of security, other than to point 261 at a SASL backend to use for authentication under realm 262 crossover. 264 name is the authorised user@domain.name or domain.name identity. 266 text is a user-oriented text explaining what information is needed. 268 3. Support for Realm Crossover 270 HTTP services tend to define users as part of their own secure realm. 271 This culminates in competitions over user names in the most popular 272 services. It also leads to variations in user names across services, 273 difficult to both users and their contacts. More seriously, it leads 274 to uncertainty about the same-ness of users at different services. 275 Anyone can claim to be your bank, but there is no basis of trusting 276 such names. 278 A more flexible model allows the client to determine their names, and 279 locate them under their own domain. Provided that services use 280 domain-specific methods for identity assurance, the client can be 281 represented by their complete form, and no concern of same-ness of 282 users names across such services need exist. As a pleasant side- 283 effect, the competition over user names has become a local matter, to 284 be resolved by the client. 286 HTTP SASL supports this model with a number of choices. First, the 287 format of a user identity is formalised to be a Network Access 288 Identifier [RFC7542] of the form 290 nai_clientid ::= utf8-username "@" utf8-realm 292 Second, there is an option to claim a client identity at all times, 293 without authentication, in any of the forms of a Network Access 294 Identifier, 296 nai_visitor ::= nai 298 In both cases, the right-hand-side symbols refer to the quoted 299 specification for a NAI. 301 The nai_clientid is reported back from SASL to the HTTP service. 302 When it is provided, it has been validated. See Appendix A for the 303 mechanism of passing such information from an HTTP server to an 304 application service. 306 The nai_visitor is used as a field to the SASL Authorization header, 307 and can be provided at any point. The form might be sent on its own, 308 as in 310 Authorization: SASL visitor=john@example.com 312 This identity is also passed from HTTP server to application server, 313 but it comes straight from this header. This means that it is just a 314 hint at an identity, without any formal status. Services seem to 315 enjoy such hints, and receiving it in a standardised manner can be 316 beneficial for support in development environments, and it allows 317 more client control. 319 It is anticipated that local information is subject to access control 320 rules that determine specific client identities, probably a mixture 321 of individuals and entire domains, who can exercise a variety of 322 rights to the resource offering over HTTP. This model can be 323 supportive of local users as well as foreign ones. 325 The nai_visitor MAY be used as a hint towards a SASL realm to 326 address, especially during the Initial Request generation. When no 327 nai_visitor is available at that time, local policy dictates what 328 SASL realm to use. This is important because the SASL realm 329 determines which mechanisms can be offered. 331 It could happen that an Intial Response comes back with a different 332 SASL realm in the nai_visitor than assumed during the generation of 333 the Initial Request. In such cases, the requested SASL realm is 334 approached. When its offering of mechanisms does not contain the 335 choice made by the client, a new Initial Request SHOULD be generated, 336 to support the client in their change of mind. There does not seem 337 to be a reason to grant such changes to occur more than once. 339 3.1. Encrypting SASL for Realm Crossover 341 Most SASL methods are unsafe to use over plaintext channels; it is a 342 common and good practice to run it over a secure channel such as TLS. 343 This is precisely the condition of HTTP SASL with server-based 344 accounts. But TLS only protects the direct link between a client and 345 a server; during realm crossover the server might effectively be a 346 man-in-the-middle. This is especially true when a SASL backend in 347 the client's domain is asked to perform the authentication for the 348 HTTP server. 350 The solution is to encrypt the SASL traffic while in transit. Since 351 the client and backend authentication service know each other, they 352 can resort to simple mechanisms such as symmetric encryption and 353 integrity checking. This means that the client and backend need to 354 share a random key and an algorithm. Random keys can for example be 355 bootstrapped through an ECDHE exchange, or as by-product [RFC5705] of 356 a TLS session. 358 Encryption is determined by an algorithm name, a key identifier and 359 the HTTP server name as it occurs in the Server Name Indication in 360 TLS. The algorithm name is captured in an enc field and the key 361 identifier in a enckid field to the SASL Authorization header: 363 Authorization: SASL encalg="aes128-cts-hmac-sha256-128" enckid="1783" 365 Key and algorithm naming can be defined locally. HTTP SASL passes 366 them through verbatim. SASL end points interpret them, and to 367 improve interoperability the algorithm names SHOULD be the names or 368 numbers of Kerberos encryption types. This is a practical choice, 369 because most SASL end points have access to suitable code for 370 handling such forms. 372 Encryption MAY be requested during the Initial Request, which itself 373 is not yet a sensitive message. When its use is desired by a client, 374 it MUST be included in the Initial Response, and will then be used 375 for the c2s and s2c fields in that message and any following. 376 Encryption SHOULD be used if an AT character U+0040 is sent as part 377 of a visitor field. 379 A separate specification will introduce a mapping of SASL into 380 Diameter messages, including support for the enc and key fields. 382 3.2. Viewing Users on HTTP Services 384 The initial authentication mechanisms for HTTP were Basic and Digest 385 [RFC2617] but these are no longer considered secure. These forms 386 used the username in the URI together with a password, a combination 387 that is now officially deprecated [Section 3.2.1 of [RFC3986]]. 389 The use of a user name in a URI has not been deprecated, but has been 390 withdrawn from HTTP because it was not included in the core HTTP 391 specification [RFC2616]. With client identities that support realm 392 crossover, it is possible to add this to SASL Authorization headers, 393 through a new siteuser field, to be used like this: 395 GET / HTTP/1.1 396 Host: www.example.net 397 Authorization: SASL userview=snowboarders 399 There is a clear need for users in HTTP URIs, as can be seen from a 400 wild variation of mappings into paths are sub-domains. The actual 401 use of the username part of the URI is however preferrable, and the 402 URI format defines it in the authority part [Section 3.2 of 403 [RFC3986]] which seems to match with the intended uses. A URI-based 404 user name will probaly still be mapped to a path on a server, but 405 need not be shown in the path in the URI. Better standardisation of 406 user names is supportive of better integration with tools on both the 407 client and server side. 409 We emphasise that the userview and client identity are orthogonal 410 concepts, except for the special case where the client is viewing his 411 own resources. This implies that it can be used with or without 412 authentication. The userview field indicates the name space of 413 resources beig addressed, while the client identity is involved in 414 access rights. 416 The reason to integrate the userview with SASL is one of identity 417 control; when the userview changes, one is visiting another part of a 418 HTTP resource space, and it may then be proper to switch to another 419 identity. This is in line with the scoping of protection spaces 420 [Section 2.2 of [RFC7235]] to combinations of URI scheme, URI 421 authority section and a server-defined realm string, where the URI 422 authority section includes the user name in the URI. 424 Browsers currently show varying behaviours when supplied with a user 425 name. This is mostly due to the deprecation [Section 3.2.1 of 426 [RFC3986]] of userparts with a password embedded. Unfortunately, 427 this also means that user names in HTTP URIs are sometimes suppressed 428 or warned about. The userview field is intended to present a 429 constructive alternative, where user names may once more be used to 430 scope the resource name space to that of a user, without saying 431 anything about authentication at all. 433 4. Security Considerations 435 The SASL exchange may be at risk of tampering when the sequence of 436 HTTP messages is not secured to form one stream. The termination of 437 such a secure layer MUST also terminate an ongoing SASL handshake. 439 SASL EXTERNAL can be a very efficient mechanism to combine with a 440 secure transport layer if that includes authentication. This may be 441 the case for TLS, especially when client-side authentication is 442 deployed. Mechanisms other than EXTERNAL should take into account 443 that a relation may exist between identities negotiated in the 444 protective layer and the SASL exchange over HTTP. 446 Channel binding is available in some SASL mechanisms. When used with 447 HTTP SASL over TLS, it binds to the TLS channel, by default using the 448 type tls-unique [Section 3 of [RFC5929]]. When doing so, it is vital 449 that either there be no renegotiation of the TLS handshake, or both 450 secure renegotiation [RFC5746] and the extended master secret 451 [RFC7627] are used. 453 5. 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 6. References 470 6.1. Normative References 472 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 473 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 474 Transfer Protocol -- HTTP/1.1", RFC 2616, 475 DOI 10.17487/RFC2616, June 1999, 476 . 478 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 479 Resource Identifier (URI): Generic Syntax", STD 66, 480 RFC 3986, DOI 10.17487/RFC3986, January 2005, 481 . 483 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 484 Kerberos Network Authentication Service (V5)", RFC 4120, 485 DOI 10.17487/RFC4120, July 2005, 486 . 488 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 489 Authentication and Security Layer (SASL)", RFC 4422, 490 DOI 10.17487/RFC4422, June 2006, 491 . 493 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 494 Kerberos and NTLM HTTP Authentication in Microsoft 495 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 496 . 498 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 499 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 500 . 502 [RFC5554] Williams, N., "Clarifications and Extensions to the 503 Generic Security Service Application Program Interface 504 (GSS-API) for the Use of Channel Bindings", RFC 5554, 505 DOI 10.17487/RFC5554, May 2009, 506 . 508 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 509 "Transport Layer Security (TLS) Renegotiation Indication 510 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 511 . 513 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 514 Service Application Program Interface (GSS-API) Mechanisms 515 in Simple Authentication and Security Layer (SASL): The 516 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 517 July 2010, . 519 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 520 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 521 . 523 [RFC6595] Wierenga, K., Lear, E., and S. Josefsson, "A Simple 524 Authentication and Security Layer (SASL) and GSS-API 525 Mechanism for the Security Assertion Markup Language 526 (SAML)", RFC 6595, DOI 10.17487/RFC6595, April 2012, 527 . 529 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 530 Protocol (HTTP/1.1): Authentication", RFC 7235, 531 DOI 10.17487/RFC7235, June 2014, 532 . 534 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 535 DOI 10.17487/RFC7542, May 2015, 536 . 538 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 539 Authentication-Info Response Header Fields", RFC 7615, 540 DOI 10.17487/RFC7615, September 2015, 541 . 543 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 544 Langley, A., and M. Ray, "Transport Layer Security (TLS) 545 Session Hash and Extended Master Secret Extension", 546 RFC 7627, DOI 10.17487/RFC7627, September 2015, 547 . 549 6.2. Informative References 551 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 552 Leach, P., Luotonen, A., and L. Stewart, "HTTP 553 Authentication: Basic and Digest Access Authentication", 554 RFC 2617, DOI 10.17487/RFC2617, June 1999, 555 . 557 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 558 Security Layer (SASL) Mechanism", RFC 4505, 559 DOI 10.17487/RFC4505, June 2006, 560 . 562 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 563 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 564 March 2010, . 566 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 567 Uniform Resource Identifiers (URIs)", RFC 5785, 568 DOI 10.17487/RFC5785, April 2010, 569 . 571 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 572 "Salted Challenge Response Authentication Mechanism 573 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 574 DOI 10.17487/RFC5802, July 2010, 575 . 577 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 578 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 579 March 2016, . 581 Appendix A. HTTP Server Environment Variables 583 We define a number of variables that SHOULD be passed from an HTTP 584 SASL stack to applications run on top of it. The intention of 585 defining these is to obtain maximum interoperability between these 586 layers of software. 588 A common practice is to set environment variables with a given name 589 to values that may be meaningful to applications. Those applications 590 should be mindful about the possible meaning of absent variables. 592 The following variables MAY be available in both the SASL 593 authenticated and unauthenticated state: 595 SASL_SITEVIEW refers to the user name in the URI and SHOULD NOT be 596 used with a password. It refines the view on resources held by 597 the web server, usually from a general site to one that is 598 user-specific. The URI user is considered local to the web 599 server (and, as a result of that, often its domain or security 600 realm). This variable is only set when it is provided through 601 the siteview field in the SASL exchange. 603 SASL_VISITOR refers to self-identification of the client independent 604 of authentication. Its general form is that of an email 605 address, but its local part MAY be empty. This variable may be 606 used to determine the domain against which the client intends 607 to authenticate and, from that, the SASL mechanisms that can be 608 offered. 610 The following variables MUST NOT be available until SASL 611 authentication is successful; it would be available when the server 612 could send a 200 OK response: 614 SASL_SECURE is only "yes" (without the quotes) when a client is 615 authenticated to the current resource. It never has another 616 value; it is simply undefined when not secured by SASL. 618 SASL_REALM is the realm for which the secure exchange succeeded. A 619 realm is not always used, because sites only need it when there 620 are more than one in the same name space. When undefined in 621 the SASL flow, this variable will not be set. 623 SASL_CLIENTID is the identity as confirmed through SASL 624 authentication. Its content is formatted like an email 625 address, and includes a domain name. That domain need not be 626 related to the web server; it is possible for a web server to 627 welcome foreign clients. 629 SASL_MECH indicates the mechanism used, and is one of the 630 standardised SASL mechanism names. It may be used to detect 631 the level of security. 633 SASL_S2S holds the accepted s2s field, and could be used as a random 634 session identifier. It would normally be encrypted 635 information. 637 SASL_S2S_ is a prefix for extra information that the server may 638 extract from the s2s field in the HTTP SASL protocol flow. 639 This depends on the authentication stack used in the web 640 server. 642 Appendix B. Acknowledgements 644 Thanks to Henri Manson for making the first implementation of this 645 specification and for feedback on the header formats. 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