idnits 2.17.1 draft-vanrein-httpauth-sasl-00.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 172: '...in the c2c field MAY be used to overco...' RFC 2119 keyword, line 176: '... in upcoming sections, MUST and MAY be...' RFC 2119 keyword, line 179: '... or Response | MUST have fields ...' RFC 2119 keyword, line 193: '...client to server, that the server MUST...' RFC 2119 keyword, line 197: '...server to client, that the client MUST...' (23 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: '... mech selec...' == Line 238 has weird spacing: '... name is th...' == Line 240 has weird spacing: '... text is a ...' -- The document date (August 14, 2017) is 2440 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) ** 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 5785 (Obsoleted by RFC 8615) 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 August 14, 2017 5 Expires: February 15, 2018 7 HTTP Authentication with SASL 8 draft-vanrein-httpauth-sasl-00 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 http://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 February 15, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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 (http://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. Standardising User-Aware HTTP . . . . . . . . . . . . . . . . 6 57 3.1. User-Aware HTTP Servers . . . . . . . . . . . . . . . . . 6 58 3.2. User-Aware HTTP Clients . . . . . . . . . . . . . . . . . 7 59 3.3. User-Aware HTTP Proxies . . . . . . . . . . . . . . . . . 7 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 6.2. Informative References . . . . . . . . . . . . . . . . . 10 65 Appendix A. SASL Authentication Examples . . . . . . . . . . . . 11 66 A.1. Mechanism Inquiry . . . . . . . . . . . . . . . . . . . . 11 67 A.2. SASL EXTERNAL . . . . . . . . . . . . . . . . . . . . . . 11 68 A.3. SASL ANONYMOUS . . . . . . . . . . . . . . . . . . . . . 12 69 A.4. SASL SCRAM-SHA-1 . . . . . . . . . . . . . . . . . . . . 12 70 A.5. GS2 Kerberos5 with TLS Channel Binding . . . . . . . . . 13 71 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 HTTP has historically followed its own path for client 77 authentication, while many other end-user protocols standardised on 78 SASL; examples of SASL protocols include SMTP, IMAP, POP, XMPP, LDAP 79 and AMQP. This specification introduces SASL to HTTP, so it may 80 share in past and future work done for SASL in general. 82 Among the work that could be shared is backend authentication 83 integration, which is possible due to protocol-independent SASL 84 exchanges for any given method, making it easy to take them out of 85 one protocol and inserting them into another. Although HTTP has 86 adopted several SASL-compatible authentication methods, it has uses 87 various notations and so it still needs method-specific support at 88 the HTTP level to translate them to a SASL backend. 90 In front-ends, a similar situation has arisen. The varying syntaxes 91 for authentication methods have made it difficult to rely on support 92 in most or all HTTP clients. When such clients could externalise 93 their SASL handling to generic software such as a SASL library, then 94 any extension to a library automatically spills over into the HTTP 95 sphere. It is common for developers of web clients to also produce 96 email clients, so a shared code base (and credential store) is not 97 difficult to imagine. 99 Sharing is beneficial in both directions. HTTP benefits by being 100 able to use GS2 mechanisms [RFC5801] with channel binding to TLS; for 101 instance Kerberos5 currently uses Negotiate authentication [RFC4559] 102 which is not as secure as GS2-KRB5-PLUS over SASL. 104 SASL also benefits; had it been the norm for HTTP, then the work to 105 pass SAML over it [RFC6595] would probably have been done 106 immediately. In fact, HTTP can still benefit from receiving 107 standardised SAML20 inquiries over SASL, becuase it resolves the need 108 for configuration of initiation paths and practices. Also, it 109 removes authentication data from URIs, where they are not ideally 110 placed. 112 TODO: Does this do justice to current SAML over HTTP? 114 In terms of security for HTTP applications, it appears beneficial to 115 have very good authentication capabilities in the layers below the 116 application; this is specifically true for applications developed in 117 HTML and JavaScript, which tend to load code from various places, 118 including code that is not always in the end user's interest; since 119 it already is a concern what identity information passes through 120 these applications, it is certainly not advisable to use credentials 121 in those places. Browsers are in a better position to take control 122 over these assets, at the protocol levels of HTTP and TLS, and 123 conceal credentials and possibly also identity from applications 124 running on top. 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. According to SASL, at least tls-unique 143 [Section 3 of [RFC5929]] must be supported. 145 2.1. HTTP Request and Response Messages 147 This section defines a few names for HTTP request and response 148 messages, to be used in the remainder of this specification. 150 Initial Responses are those HTTP responses that set a status code 401 151 or 407, and that are sent when the HTTP server decides to initiate an 152 authentication exchange. 154 Initial Requests are those HTTP requests that a client sends to 155 initiate a fresh SASL authentication. User-Aware Requests are a 156 variation defined further below, intended for attempts to address 157 public resources under a given user name. 159 Intermediate Responses are HTTP responses to SASL authentication, 160 with a status code set to 401 or 407. Intermediate Requests are 161 those HTTP requests that a client sends to continue a SASL 162 authentication after an Intermediate Response. 164 Final Responses either set a 200 or 403 status code, the first 165 depicting success and the second depicting failure. Information in a 166 Final 200 Response is provided in an Authentication-Info or Proxy- 167 Authentication-Info header [RFC7615] instead of the headers used in 168 Initial Responses and Intermediate Responses [RFC7235]. Note that 169 proper interpretation of the Final 200 Response requires client state 170 indicating that SASL authentication was used, or else the optional 171 fields are not completely reliable information sources; cryptographic 172 markers in the c2c field MAY be used to overcome this in a manner 173 that defies abuse by rogue servers. The Final 403 Response never 174 contains authentication-related headers. 176 The following fields, defined in upcoming sections, MUST and MAY be 177 present in HTTP authentication exchanges for SASL: 179 Request or Response | MUST have fields | MAY have fields 180 ----------------------+----------------------+---------------- 181 Initial Response | mech,s2s,realm | text 182 Initial Request | mech,s2s,c2c,realm | c2s 183 User-Aware Request | mech,c2s | 184 Intermediate Response | mech,c2c,c2s,s2c,s2s | text 185 Intermediate Request | mech,c2c,c2s,s2c,s2s | 186 Final 200 Response | mech,c2c,name,realm | s2c,c2s,s2s 187 Final 403 Response | | 189 2.2. Authentication Field Definitions 191 Data for SASL is transported in the following fields: 193 c2s SASL mechanism data from client to server, that the server MUST 194 reflect in an following Intermediate Response, or set to an 195 empty string when absent from an Initial Request. 197 s2c SASL mechanism data from server to client, that the client MUST 198 reflect in following Initial Requests or Intermediate Requests. 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]]. 205 c2c holds opaque client data which the server MUST reflect in 206 Intermediate Responses and Final 200 Responses. This helps to 207 also make the client stateless. 209 As in other protocols, it is not safe for all SASL mechanisms to 210 exchange c2s and s2c messages over unprotected transports. The c2c 211 and s2s fields MUST be protected against tampering by rogue peers, 212 and such protection also protects against tampering by rogue 213 intermediates when using an unprotected transport. In addition, c2c 214 and s2s fields may also need to be concealed from peers and 215 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 mech selects the SASL mechanism to use. It MUST be reflected from 232 the preceding message, except: In an Initial Response, the 233 field is filled with a space-separated list of SASL mechanism 234 names; In an Initial Request, the client chooses one SASL 235 mechanism name; In a User-Aware Request, the field is fixated 236 to ANONYMOUS. 238 name is the authorised user@domain.name or domain.name identity. 240 text is a user-oriented text explaining what information is needed. 242 realm indicates the scope of authorisation. 244 3. Standardising User-Aware HTTP 246 This section specifies an optional extension to HTTP SASL. HTTP 247 clients, servers and proxies that adopt it will be called User-Aware. 248 The purpose of User-Aware resources is to have standardised locations 249 for user pages, including personal well-known URIs [RFC5785]. 251 Most protocols attach a service to a domain name or host name, and 252 have a form like john@example.com to zoom in on a user of the 253 service. But although HTTP URIs can express user names, it lacks a 254 standard interpretation of their meaning. Ideally, access to user 255 resources should support a mixture of public and protected resources. 256 A possible approach is hereby proposed, using a User-Aware Request as 257 introduced in Section 2. 259 Whether or not content found with a user name is dynamic or static is 260 orthogonal to the additional resource location information. For 261 caches, it is therefore possible to cache such content as soon as 262 they recognise the lack of impact of SASL ANONYMOUS authentication on 263 the content and its secrecy. 265 3.1. User-Aware HTTP Servers 267 User-Aware HTTP servers MUST NOT assume successful authentication 268 when presented with a User-Aware Request. It MAY however treat the 269 c2s field as a modifier while locating public resources. What the 270 impact of this modifier is, if any, is an implementation matter of 271 the server. Intuitively, the c2s field can be made to feel like a 272 user name whose data is requested, or a view on data, or just a 273 sequence of requests that can easily be traced. HTTP servers MAY log 274 a trace message containing the c2s string. 276 When a User-Aware Request addresses a resource that is not public, 277 the server MAY send a Final 403 Response, or otherwise it MUST send 278 an Initial Response. The HTTP authentication exchange following the 279 latter should then complete before deciding on resource access. 281 An HTTP server may redirect a User-Aware Request with the HTTP 282 Location header. While constructing the new HTTP URI, the server MAY 283 include the user field from the User-Aware Request, but only when 284 redirecting to the same protocol, host name and port; configuration 285 directives often have a relative URI notation for this purpose. A 286 newly constructed HTTP URI with a different protocol, host name or 287 port MUST NOT copy the user name from the User-Aware Request. 289 3.2. User-Aware HTTP Clients 291 When an HTTP URI contains a user name, then User-Aware HTTP clients 292 MUST produce the User-Aware authentication header. The c2s string, 293 called a trace string in the SASL ANONYMOUS mechanism, is set to the 294 user name portion of the HTTP URI. 296 TODO: This assumes that all non-User-Aware HTTP Servers ignore the 297 User-Aware Request's extras. We tried Nginx, Apache and IIS, and 298 they agree. RFC 2616 also suggests that the client may choose to 299 authenticate. 301 At any time when provided with a User-Aware Request, the User-Aware 302 HTTP server may decide to request authentication through an Initial 303 Response. It now matters whether the HTTP URI also contains a 304 password. With a password available, the User-Aware client SHOULD 305 select a password-based SASL mechanism that it considers sufficiently 306 secure. Without a password available, the client is free to select 307 any of the mechanisms supplied. Even SASL ANONYMOUS may be chosen, 308 though it must then be sent as an Initial Request, rather than as a 309 User-Aware Request, so it can be distinguished as an explicit choice 310 to skip authentication. 312 HTTP clients may be referenced or redirected from one HTTP URI to 313 another. The client MUST NOT consider a reference with a username, 314 and possibly even a password, to be an attack; it may hold a tracing 315 identity, but so can paths and cookies; and the password can be 316 useful, especially when it is short-lived and personalised. When 317 processing a step to another HTTP URI through a notation for an 318 absolute URI, then a comparison is made of the protocol, user name, 319 host name and port. Only when all fields match and when no password 320 is specified SHOULD the User-Aware HTTP client insert a password from 321 the previous URI to the newly specified URI. In notations that may 322 hold a relative URI, such as in HTML references, the comparison is 323 more strict; for those, there MUST NOT be any mentioning of the 324 protocol, user name, password or host name if the user name and 325 password are to be taken along to the new URI. 327 3.3. User-Aware HTTP Proxies 329 User-Aware HTTP proxies MAY store responses to User-Aware Requests 330 when no other reasons disallow it, but they MUST use the c2s string 331 as an additional part of the resource identity. In other words, the 332 stored resource MUST NOT be returned for requests that are not User- 333 Aware Requests, or that carry a different c2s string. This only 334 concerns Authorization header fields, not those in a Proxy- 335 Authorization header. 337 TODO: Do we ever use Proxy-Authorization in User-Aware Requests? 339 4. Security Considerations 341 The SASL exchange may be at risk of tampering when the sequence of 342 HTTP messages is not secured to form one stream. The termination of 343 such a secure layer MUST also terminate an ongoing SASL handshake. 345 SASL EXTERNAL can be a very efficient mechanism to combine with a 346 secure transport layer if that includes authentication. This may be 347 the case for TLS, especially when client-side authentication is 348 deployed. Mechanisms other than EXTERNAL should take into account 349 that a relation may exist between identities negotiated in the 350 protective layer and the SASL exchange over HTTP. 352 Channel binding is available in some SASL mechanisms. When used with 353 HTTP SASL, it binds to the TLS channel, by default using the type 354 tls-unique [Section 3 of [RFC5929]]. When doing so, it is vital that 355 either there be no renegotiation of the TLS handshake, or both secure 356 renegotiation [RFC5746] and the extended master secret [RFC7627] are 357 used. 359 5. IANA Considerations 361 This specification extends the "Hypertext Transfer Protocol (HTTP) 362 Authentication Scheme Registry" with an "Authentication Scheme Name" 363 SASL, referencing this specification. 365 This specification defines an additional entry in the registry 366 "Generic Security Service Application Program Interface 367 (GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL) 368 Service Names" namely: 370 Service Name: HTTP 371 Usage: Web authentication using the SASL framework 372 Reference: TBD:this specification 374 6. References 376 6.1. Normative References 378 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 379 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 380 Transfer Protocol -- HTTP/1.1", RFC 2616, 381 DOI 10.17487/RFC2616, June 1999, 382 . 384 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 385 Kerberos Network Authentication Service (V5)", RFC 4120, 386 DOI 10.17487/RFC4120, July 2005, 387 . 389 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 390 Authentication and Security Layer (SASL)", RFC 4422, 391 DOI 10.17487/RFC4422, June 2006, 392 . 394 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 395 Kerberos and NTLM HTTP Authentication in Microsoft 396 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 397 . 399 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 400 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 401 . 403 [RFC5554] Williams, N., "Clarifications and Extensions to the 404 Generic Security Service Application Program Interface 405 (GSS-API) for the Use of Channel Bindings", RFC 5554, 406 DOI 10.17487/RFC5554, May 2009, 407 . 409 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 410 "Transport Layer Security (TLS) Renegotiation Indication 411 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 412 . 414 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 415 Service Application Program Interface (GSS-API) Mechanisms 416 in Simple Authentication and Security Layer (SASL): The 417 GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, 418 July 2010, . 420 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 421 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 422 . 424 [RFC6595] Wierenga, K., Lear, E., and S. Josefsson, "A Simple 425 Authentication and Security Layer (SASL) and GSS-API 426 Mechanism for the Security Assertion Markup Language 427 (SAML)", RFC 6595, DOI 10.17487/RFC6595, April 2012, 428 . 430 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 431 Protocol (HTTP/1.1): Authentication", RFC 7235, 432 DOI 10.17487/RFC7235, June 2014, 433 . 435 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 436 Authentication-Info Response Header Fields", RFC 7615, 437 DOI 10.17487/RFC7615, September 2015, 438 . 440 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 441 Langley, A., and M. Ray, "Transport Layer Security (TLS) 442 Session Hash and Extended Master Secret Extension", 443 RFC 7627, DOI 10.17487/RFC7627, September 2015, 444 . 446 6.2. Informative References 448 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 449 Security Layer (SASL) Mechanism", RFC 4505, 450 DOI 10.17487/RFC4505, June 2006, 451 . 453 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 454 Uniform Resource Identifiers (URIs)", RFC 5785, 455 DOI 10.17487/RFC5785, April 2010, 456 . 458 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 459 "Salted Challenge Response Authentication Mechanism 460 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 461 DOI 10.17487/RFC5802, July 2010, 462 . 464 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 465 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 466 March 2016, . 468 Appendix A. SASL Authentication Examples 470 This section is non-normative. It shows a number of examples of SASL 471 exchanges over HTTP. 473 A.1. Mechanism Inquiry 475 Normally, a client is not aware of the need to authenticate, and in 476 these cases it is sent an Initial Response. For example, the Initial 477 401 Response could be 479 WWW-Authenticate: SASL mech="EXTERNAL ANONYMOUS GS2-KRB5" 481 which indicates that this resource offers a choice, but nonetheless 482 offers the option of ANONYMOUS authentication (which implies guest 483 access only) and more uplifting options through EXTERNAL and GS2-KRB5 484 authentication. The client now chooses a SASL mechanism name for its 485 Initial Request and both client and server continue to reflect it 486 back and forth for the remainder of the authentication. 488 There is no explicit mechanism for asking the server about the 489 available SASL mechanisms, because this may depend on request aspects 490 like the location and method. To find out what the options are, it 491 is best to simply attempt the intended access. 493 A.2. SASL EXTERNAL 495 The SASL EXTERNAL mechanism refers the context in which HTTP is run, 496 such as its transport protocol, and attempts to infer client 497 authenticity from it. The normal context that can answer to this 498 desire is the TLS transport; the client identity can be provided in a 499 TLS handshake using an X.509 certificate, an OpenPGP key, a Kerberos 500 ticket or an SRP handshake. Each of these allow the derivation of a 501 user name and its realm. 503 The EXTERNAL mechanism [Appendix A of [RFC4422]] can simply be stated 504 by the client, either when the server requests authentication or when 505 the client wants to provide it, and should pass through without 506 further interaction. To authenticate as john@example.com, the 507 request should contain 509 Authorization: SASL mech="EXTERNAL",realm="example.com", 510 c2s="john",c2c=data0 512 which would immediately lead to a Final Response. Note that a Final 513 200 Response mentions the realm and name that were actually 514 authorized, and these may differ from the requested names. SASL 515 EXTERNAL is a very easy-to-use HTTP authentication method, and it is 516 arguably the most secure; given the dynamic nature and mixed origin 517 of HTTP resources, it can be helpful to rely on lower layers such as 518 the transport layer that is usually less involved in the dynamic 519 resource mix. 521 A.3. SASL ANONYMOUS 523 The ANONYMOUS mechanism is another simple method. It indicates a 524 lacking desire to authenticate as a particular user. This SASL 525 method defines the c2s data as trace information [RFC4505] so the 526 Initial Request 528 Authorization: SASL mech="ANONYMOUS",realm="example.com", 529 c2c=data0,c2s="knock, knock" 531 would probably log the "knock, knock" string but lead to guest-level 532 access rights. An important use of this SASL method is that it 533 reflects an explicit client choice to access a resource as a guest, 534 which brings it across the Initial Response that may be returned from 535 the HTTP server when a resource requires authentication. 537 Note the difference with a User-Aware SASL ANONYMOUS header 539 Authorization: SASL mech="ANONYMOUS",c2s="knocker" 541 which would not be considered an authentication attempt because the 542 s2s and c2c fields are missing. Instead, an attempt is made to serve 543 public data for user knocker for the requested resource location. 544 The server may decide to initiate an authentication exchange for the 545 resource location if it deems the contents to not be public. 547 A.4. SASL SCRAM-SHA-1 549 SCRAM-SHA-1 is available as a SASL mechanism [RFC5802] as well as an 550 HTTP mechanism [RFC7804] with identical data. This means that a 551 translation of the dedicated authentication mechanism onto a SASL 552 backend of the HTTP server would be possible. This helps to support 553 the original HTTP mechanism even when only a SASL authentication 554 backend is available. 556 SCRAM mechanisms start off with data from the client, so c2s is 557 already set in the Initial Request. To demonstrate an existing 558 example [Section 5 of [RFC5802]], we can set user name user with 559 password pencil, 561 Authorize: SASL mech="SCRAM-SHA-1",realm="example.com",c2c=data1, 562 c2s="n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL" 564 or alternatively, using base-64 encoding for the c2s field, 566 Authorize: SASL mech="SCRAM-SHA-1",realm="example.com",c2c=data1, 567 c2s=biwsbj11c2VyLHI9ZnlrbytkMmxiYkZnT05Sdjlxa3hkYXdM 569 to which the server would send Intermediate Response 571 WWW-Authenticate: SASL mech="SCRAM-SHA-1",c2c=data1,s2s=data2, 572 c2s="n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL", 573 s2c="r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 574 s=QSXCR+Q6sek8bf92,i=4096", 575 text="Password for user" 577 which causes the client to use the password for the Intermediate 578 Request 580 Authorize: SASL mech="SCRAM-SHA-1",c2c=data3,s2s=data2, 581 s2c="r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 582 s=QSXCR+Q6sek8bf92,i=4096" 583 c2s="c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 584 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=" 586 to which the server responds with a Final 200 Response and an 587 informative header 589 Authentication-Info: mech="SCRAM-SHA-1",c2c=data3, 590 s2c="v=rmF9pqV8S7suAoZWja4dJRkFsKQ=", 591 name="user@example.com",realm="example.com" 593 and in addition, the server will have performed the requested work. 595 As with the SASL EXTERNAL mechanism, it is arguably more secure when 596 the password is entered into a browser popup then in a dynamically 597 composed application that may not be under full control of the end 598 user. 600 A.5. GS2 Kerberos5 with TLS Channel Binding 602 When a client decides to perform Kerberos5 [RFC4120] authentication, 603 it should procure a service ticket for HTTP/ 604 www.example.com@EXAMPLE.COM when www.example.com is the web server 605 host name and EXAMPLE.COM is its realm. Clients usually derive the 606 host name from a URI, but then need to find the realm; Kerberos5 607 implementations and standards offer a few methods for that; clients 608 MUST NOT use insecure mechanisms to derive the realm from the host 609 name; clients MUST NOT accept realms from HTTP or even TLS for use 610 with Kerberos5. 612 The client now provides an Initial Request to the www.example.com 613 with the GS2 token in the c2s field, possibly with base-64 encoding 615 Authorize: SASL mech="GS2-KRB5-PLUS",realm="example.com", 616 c2c=data0,c2s=base64blob 618 where the SASL mechanism name indicates Kerberos5 over the GS2 bridge 619 [RFC5801], with channel binding [RFC5056] [RFC5554] [RFC5929], 620 presumably to a TLS wrapper. This usually suffices for the server to 621 produce a Final Response. 623 Appendix B. Acknowledgements 625 Author's Address 627 Rick van Rein 628 ARPA2.net 629 Haarlebrink 5 630 Enschede, Overijssel 7544 WP 631 The Netherlands 633 Email: rick@openfortress.nl