idnits 2.17.1 draft-vanrein-httpauth-sasl-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '... binding is used SHOULD remain a confi...' 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 200: '... data which the client MUST reflect in...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 231 has weird spacing: '...serview selec...' == Line 247 has weird spacing: '... text is a ...' -- The document date (January 20, 2020) is 1557 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 367, 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 (~~), 4 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 January 20, 2020 5 Expires: July 23, 2020 7 HTTP Authentication with SASL 8 draft-vanrein-httpauth-sasl-03 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 July 23, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Embedding SASL in HTTP . . . . . . . . . . . . . . . . . . . 3 54 2.1. HTTP Request and Response Messages . . . . . . . . . . . 4 55 2.2. Authentication Field Definitions . . . . . . . . . . . . 5 56 2.3. Caching Authentication Results . . . . . . . . . . . . . 6 57 3. Viewing Users on HTTP Services . . . . . . . . . . . . . . . 6 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 6.2. Informative References . . . . . . . . . . . . . . . . . 10 63 Appendix A. HTTP Server Environment Variables . . . . . . . . . 10 64 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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 and AMQP. 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 is beneficial in both directions. HTTP benefits by being 93 able to use anything from strong password mechanisms [RFC5802] 94 without explicit support [RFC7804] in applications, up to GS2 95 mechanisms [RFC5801] with channel binding [RFC5056] [RFC5554] to TLS 96 [RFC5929] based on pinning either the certificate for the TLS server 97 or even a unique part of the individual TLS connection; for instance 98 Kerberos5 [RFC4120] currently uses Negotiate authentication [RFC4559] 99 which is not as secure as GS2-KRB5-PLUS over SASL. 101 SASL also benefits; had it been the norm for HTTP, then the work to 102 pass SAML over it [RFC6595] would probably have been done 103 immediately. In fact, HTTP can still benefit from receiving 104 standardised SAML20 inquiries over SASL, becuase it resolves the need 105 for configuration of initiation paths and practices. Also, it 106 removes authentication data from URIs, where they are not ideally 107 placed. 109 In terms of security for HTTP applications, it appears beneficial to 110 have very good authentication capabilities in the layers below the 111 application; this is specifically true for applications developed in 112 HTML and JavaScript, which tend to load code from various places, 113 including code that is not always in the end user's interest; since 114 it already is a concern what identity information passes through 115 these applications, it is certainly not advisable to use credentials 116 in those places. Browsers are in a better position to take control 117 over these assets, at the protocol levels of HTTP and TLS, and 118 conceal credentials and possibly also identity from applications 119 running on top. Inasfar as tokens are needed, they can be derived 120 from session keys using generally accepted key derivation schemes, 121 but the session keys can be isolated from dynamic layers above HTTP. 123 2. Embedding SASL in HTTP 125 This specification integrates the SASL framework [RFC4422] into 126 mainstream HTTP [RFC2616]. The SASL Authentication scheme follows 127 the general structure for HTTP Authentication [RFC7235]. It uses the 128 WWW-Authenticate and Proxy-Authenticate headers in responses from web 129 servers and web proxies, respectively, and correspondingly the 130 Authorization and Proxy-Authorization request header to answer to 131 requests. 133 The SASL service name for the following embedding of SASL is HTTP; 134 contrary to most other service names, it is spelled in uppercase, in 135 line with what has become general practice in Kerberos and GSSAPI. 137 Since SASL prescribes channel binding to occur relative to TLS 138 instead of to the application protocol, we can add that when the 139 HTTPS transport is used. 141 Whether channel binding is used SHOULD remain a configuration choice 142 in HTTP software, as it might interfere with intentional HTTPS 143 proxying. Unintended proxying on the other hand, might lead to 144 tapping of credentials under certain SASL mechanisms, and it may be 145 considered helpful to prevent such situations by relying on channel 146 binding for at least those 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 User Viewing Request | userview | mech 185 Initial Response | mech,s2s,realm | text 186 Initial Request | mech,s2s,c2c,realm | c2s,userview 187 Intermediate Response | c2c,s2c,s2s | text 188 Intermediate Request | c2c,c2s,s2s | userview 189 Final 200 Response | c2c | s2s 190 Final 403 Response | c2c | 192 2.2. Authentication Field Definitions 194 Data for SASL is transported in the following fields: 196 c2s holds SASL mechanism-specific data from client to server. 198 s2c holds SASL mechanism-specific data from server to client. 200 s2s holds opaque server data which the client MUST reflect in 201 Intermediate Requests, to implement stateless SASL handling in 202 the server. This is a requirement for the HTTP Authentication 203 framework [Section 5.1.2 of [RFC7235]]. It MAY also be used to 204 pass cached Section 2.3 authentication results. 206 c2c holds opaque client data which the server MUST reflect in 207 Intermediate Responses and Final 200/403 Responses. This can 208 help to also make the client stateless. 210 It is not generally safe for SASL mechanisms to exchange c2s and s2c 211 messages over unprotected transports. The c2c and s2s fields MUST be 212 protected against tampering by rogue peers, and such protection also 213 protects against tampering by rogue intermediates when using an 214 unprotected transport. In addition, c2c and s2s fields may also need 215 to be concealed from peers and intermediates. 217 Whether s2c is supplied in a Final 200 Response depends on the SASL 218 mechanism, which may or may not have additional data to provide in 219 this phase. Note that SASL requires empty s2c messages to be 220 distinguished from absence thereof. When the server provides c2s 221 and/or s2s data in a Final 200 Response, then it indicates that the 222 supplied fields MAY provide one-step re-authentication with an empty 223 s2c string, but the server MAY revoke this privilege at any time and 224 for any reason; it would respond with an Initial Response in case of 225 such revocation, but with a quick Final 200 Response if the one-step 226 re-authentication is still acceptable. 228 The following fields support SASL within the HTTP Authentication 229 Framework: 231 userview selects a user view on the resources accessible over HTTP. 232 This data selection purpose is unrelated to authentication. As 233 a general principle, the userview MAY lead to changes in 234 authentication triggers for URI paths, but MUST NOT change 235 authentication triggers for the underlying resources. 237 realm optionally names a scope of authorisation under the combination 238 of scheme, server host name and userview. This does not 239 signify a realm in the sense of realm crossover. 241 mech In an Initial Response, the field is filled with a space- 242 separated list of SASL mechanism names; In an Initial Request, 243 the client chooses one SASL mechanism name; In a User Viewing 244 Request, the field is fixated to ANONYMOUS [RFC4505] if it is 245 provided. 247 text is a user-oriented text explaining what information is needed. 249 2.3. Caching Authentication Results 251 When an HTTP server sends a Final 200 Response, it MAY include an 252 "s2s" field. If it does this, then it SHOULD prepare to accept the 253 field value for authentication in an Initial Request. However, 254 credentials can expire or fall in disgrace for other reasons, so the 255 server MAY still choose to reject the provided field. 257 When an HTTP client receives a Final 200 Response with an "s2s" 258 field, it MAY memorise the fields for future reuse in an Initial 259 Request, either with or without preceding Initial Response from the 260 server. The HTTP client MUST use the realm as part of the decision 261 which cached result to use, but it MAY extrapolate the results from 262 one resource retrieval in an attempt to authenticate another. 264 When cached field result in a Final 407 Response then the HTTP client 265 SHOULD remove the failing cache entry, and it SHOULD try again by 266 going through a full SASL authentication cycle. The stateless nature 267 of HTTP authentication is helpful in the sense that a new Initial 268 Request can be sent to an older Initial Response. 270 3. Viewing Users on HTTP Services 272 The initial authentication mechanisms for HTTP were Basic and Digest 273 [RFC2617] but these are no longer considered secure. These forms 274 used the username in the URI together with a password, a combination 275 that is now officially deprecated [Section 3.2.1 of [RFC3986]]. 277 The use of a user name in a URI has not been deprecated, but has been 278 withdrawn from HTTP because it was not included in the core HTTP 279 specification [RFC2616]. With client identities that support realm 280 crossover, it is possible to add this to SASL Authorization headers, 281 through a new userview field, to be used like this: 283 GET / HTTP/1.1 284 Host: www.example.net 285 Authorization: SASL userview=snowboarders 287 There is a clear need for users in HTTP URIs, as can be seen from a 288 wild variation of mappings into paths and sub-domains. The actual 289 use of the username part of the URI is however preferrable, and the 290 URI format defines it in the authority part [Section 3.2 of 291 [RFC3986]] which seems to match with the intended uses. A URI-based 292 user name will probaly still be mapped to a path on a server, but 293 need not be shown in the path in the URI. Better standardisation of 294 user names is supportive of better integration with tools on both the 295 client and server side. 297 We emphasise that the userview and client identity are orthogonal 298 concepts, except for the special case where the client is viewing his 299 own resources. This implies that it can be used with or without 300 authentication. The userview field indicates the name space of 301 resources beig addressed, while the client identity is involved in 302 access rights. 304 The reason to integrate the userview with SASL is one of identity 305 control; when the userview changes, one is visiting another part of a 306 HTTP resource space, and it may then be proper to switch to another 307 identity. This is in line with the scoping of protection spaces 308 [Section 2.2 of [RFC7235]] to combinations of URI scheme, URI 309 authority section and a server-defined realm string, where the URI 310 authority section includes the user name in the URI. 312 Browsers currently show varying behaviours when supplied with a user 313 name. This is mostly due to the deprecation [Section 3.2.1 of 314 [RFC3986]] of userparts with a password embedded. This has created 315 uncertainty and variation in handling of HTTP URIs with user names 316 but no password. The userview field is intended to present a 317 constructive alternative, where user names may once more be used to 318 scope the resource name space to that of a user, without saying 319 anything about authentication. 321 4. Security Considerations 323 The SASL exchange may be at risk of tampering when the sequence of 324 HTTP messages is not secured to form one stream. The termination of 325 such a secure layer MUST also terminate an ongoing SASL handshake. 327 SASL EXTERNAL can be a very efficient mechanism to combine with a 328 secure transport layer if that includes authentication. This may be 329 the case for TLS, especially when client-side authentication is 330 deployed. Mechanisms other than EXTERNAL should take into account 331 that a relation may exist between identities negotiated in the 332 protective layer and the SASL exchange over HTTP. For example, a 333 login account may be exchanged for an alias or group identity. 335 Channel binding is available in some SASL mechanisms. When used with 336 HTTP SASL over TLS, it binds to the TLS channel, by default using the 337 type tls-unique [Section 3 of [RFC5929]]. When doing so, it is vital 338 that either there be no renegotiation of the TLS handshake, or both 339 secure renegotiation [RFC5746] and the extended master secret 340 [RFC7627] are used. 342 5. IANA Considerations 344 This specification extends the "Hypertext Transfer Protocol (HTTP) 345 Authentication Scheme Registry" with an "Authentication Scheme Name" 346 SASL, referencing this specification. 348 This specification defines an additional entry in the registry 349 "Generic Security Service Application Program Interface 350 (GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL) 351 Service Names" namely: 353 Service Name: HTTP 354 Usage: Web authentication using the SASL framework 355 Reference: TBD:this specification 357 6. References 359 6.1. Normative References 361 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 362 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 363 Transfer Protocol -- HTTP/1.1", RFC 2616, 364 DOI 10.17487/RFC2616, June 1999, 365 . 367 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 368 Resource Identifier (URI): Generic Syntax", STD 66, 369 RFC 3986, DOI 10.17487/RFC3986, January 2005, 370 . 372 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 373 Kerberos Network Authentication Service (V5)", RFC 4120, 374 DOI 10.17487/RFC4120, July 2005, 375 . 377 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 378 Authentication and Security Layer (SASL)", RFC 4422, 379 DOI 10.17487/RFC4422, June 2006, 380 . 382 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 383 Kerberos and NTLM HTTP Authentication in Microsoft 384 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 385 . 387 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 388 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 389 . 391 [RFC5554] Williams, N., "Clarifications and Extensions to the 392 Generic Security Service Application Program Interface 393 (GSS-API) for the Use of Channel Bindings", RFC 5554, 394 DOI 10.17487/RFC5554, May 2009, 395 . 397 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 398 "Transport Layer Security (TLS) Renegotiation Indication 399 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 400 . 402 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 403 Service Application Program Interface (GSS-API) Mechanisms 404 in Simple Authentication and Security Layer (SASL): The 405 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 406 July 2010, . 408 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 409 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 410 . 412 [RFC6595] Wierenga, K., Lear, E., and S. Josefsson, "A Simple 413 Authentication and Security Layer (SASL) and GSS-API 414 Mechanism for the Security Assertion Markup Language 415 (SAML)", RFC 6595, DOI 10.17487/RFC6595, April 2012, 416 . 418 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 419 Protocol (HTTP/1.1): Authentication", RFC 7235, 420 DOI 10.17487/RFC7235, June 2014, 421 . 423 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 424 Authentication-Info Response Header Fields", RFC 7615, 425 DOI 10.17487/RFC7615, September 2015, 426 . 428 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 429 Langley, A., and M. Ray, "Transport Layer Security (TLS) 430 Session Hash and Extended Master Secret Extension", 431 RFC 7627, DOI 10.17487/RFC7627, September 2015, 432 . 434 6.2. Informative References 436 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 437 Leach, P., Luotonen, A., and L. Stewart, "HTTP 438 Authentication: Basic and Digest Access Authentication", 439 RFC 2617, DOI 10.17487/RFC2617, June 1999, 440 . 442 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 443 Security Layer (SASL) Mechanism", RFC 4505, 444 DOI 10.17487/RFC4505, June 2006, 445 . 447 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 448 "Salted Challenge Response Authentication Mechanism 449 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 450 DOI 10.17487/RFC5802, July 2010, 451 . 453 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 454 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 455 March 2016, . 457 Appendix A. HTTP Server Environment Variables 459 We define a number of variables that SHOULD be passed from an HTTP 460 SASL stack to applications run on top of it. The intention of 461 defining these is to obtain maximum interoperability between these 462 layers of software. 464 A common practice is to set environment variables with a given name 465 to values that may be meaningful to applications. Those applications 466 should be mindful about the possible meaning of absent variables. 468 The following variable MAY be available in both the SASL 469 authenticated and unauthenticated state: 471 SASL_USERVIEW refers to the user name in the URI 473 SASL_USERVIEW that MUST NOT be accompanied by a password. It 474 refines the view on resources held by the web server, usually 475 from a general site to one that is user-specific. The URI user 476 is considered local to the web server (and, as a result of 477 that, often its domain or security realm). This variable is 478 only set when it is provided through the siteview field in the 479 SASL exchange. 481 The following variables MUST NOT be available until SASL 482 authentication is successful; it would be available when the server 483 could send a 200 OK response: 485 SASL_SECURE is only "yes" (without the quotes) when a client is 486 authenticated to the current resource. It never has another 487 value; it is simply undefined when not secured by SASL. 489 SASL_REALM is the realm for which the secure exchange succeeded. A 490 realm is not always used, because sites only need it when there 491 are more than one in the same name space. When undefined in 492 the SASL flow, this variable will not be set. 494 SASL_CLIENTID is the identity as confirmed through SASL 495 authentication. Its content is formatted like an email 496 address, and includes a domain name. That domain need not be 497 related to the web server; it is possible for a web server to 498 welcome foreign clients. 500 SASL_MECH indicates the mechanism used, and is one of the 501 standardised SASL mechanism names. It may be used to detect 502 the level of security. 504 SASL_S2S holds the accepted s2s field, and could be used as a random 505 session identifier. It would normally be encrypted 506 information. 508 SASL_S2S_ is a prefix for extra information that the server may 509 extract from the s2s field in the HTTP SASL protocol flow. 510 This depends on the authentication stack used in the web 511 server. 513 Appendix B. Acknowledgements 515 Thanks to Henri Manson for making the first implementation of this 516 specification and for feedback on the header formats. 518 Author's Address 519 Rick van Rein 520 ARPA2.net 521 Haarlebrink 5 522 Enschede, Overijssel 7544 WP 523 The Netherlands 525 Email: rick@openfortress.nl