idnits 2.17.1 draft-williams-http-accept-auth-and-redirect-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 31, 2020) is 1485 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) -- Looks like a reference, but probably isn't: '1' on line 491 ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 4559 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Williams, Ed. 3 Internet-Draft Cryptonector, LLC 4 Intended status: Standards Track March 31, 2020 5 Expires: October 2, 2020 7 Accept-Auth HTTP Header for 3xx/401 Negotiation, and Redirect 8 Authentication Scheme 9 draft-williams-http-accept-auth-and-redirect-01 11 Abstract 13 The Hyper-Text Transport Protocol (HTTP) offers several 14 authentication schemes, but many sites use redirection-based 15 protocols to authenticate users. Some servers are faced with a 16 connundrum, having to choose between two mutually-exclusive options: 17 redirect responses or 401 (authentication required) responses without 18 knowing which the user-agent is most likely to support. 20 This document specifies new HTTP request headers by which many 21 applications can improve interoperability even without changing their 22 HTTP implementations. These new headers allow user-agents to 23 advertise authentication- and redirect-related capbilities that 24 servers can use to better make authentication and/or redirect 25 decisions. 27 Also specified is a new HTTP authentication scheme named "Redirect" 28 that enables communication between redirecting and redirected 29 authorities via preservation of "Authorization" and "Authorization- 30 Request" headers across redirections. This enables arbitrary 31 authentication and authorization protocols to work without requiring 32 user-agent support for them. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 2, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 2. Accept-Redirect and Accept-Redirect-Auth . . . . . . . 3 70 3. Accept-Auth . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. The Redirect Authentication Scheme . . . . . . . . . . . . . 4 72 5. Mixing Redirection and Authentication Requests . . . . . . . 6 73 5.1. 3xx Responses with WWW-Authenticate . . . . . . . . . . . 7 74 5.2. 401 Responses with Location . . . . . . . . . . . . . . . 7 75 6. Auth-params for Selected Authentication Mechanisms . . . . . 7 76 7. Server-Side Selection of Authentication Schemes . . . . . . . 8 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 10.1. Multi-Level Negotiation . . . . . . . . . . . . . . . . 9 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 11.2. Informative References . . . . . . . . . . . . . . . . . 11 84 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 The Hyper-Text Transport Protocol (HTTP) RFC7230 [RFC7230] provides 90 several schemes for user authentication. There also are popular ways 91 of authenticating users based on redirection rather than standard 92 HTTP authentication schemes. Heretofore, HTTP has provided no 93 standard way for servers to know which authentication schemes, 94 including redirect-based methods, a given user-agent supports, but 95 servers must choose between either redirection or HTTP 96 authentication, and these two are mutually exclusive. 98 This situation arises especially in corporate networks where JSON Web 99 Tokens (JWT) [RFC7519] and Negotiate [RFC4559] are both used, the 100 latter usually with the Kerberos [RFC4120] GSS-API [RFC2743] 101 mechanism [RFC4121]. 103 We address this problem by adding new request headers, "Accept- 104 Auth:", "Accept-Redirect-Auth:", and "Accept-Redirect:" by which a 105 user-agent can indicate which HTTP authentication schemes, if any, it 106 supports, including redirection. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Accept-Redirect and Accept-Redirect-Auth 116 The Accept-Redirect request header has two possible values: "yes" and 117 "no". If "yes", this means the user-agent will follow redirections, 118 and the user-agent may or may not be willing to authenticate at the 119 redirected origin depending on local policy. 121 The Accept-Redirect-Auth request header exists to indicate which 122 authorities the user-agent is willing to redirect to and authenticate 123 at. Its value is a whitespace-separate list of domainnames. If 124 empty or has just the value ".", then the service can conclude only 125 that the user-agent has a whitelist, but is not disclosing it. 127 3. Accept-Auth 129 The Accept-Auth request header may have multiple values, or be 130 present multiple times, as with most HTTP headers. Each value names 131 one authentication schemes, and optionally may indicate schemes- 132 specific metadata. 134 Accept-Auth values are similar to WWW-Authenticate values [RFC7235], 135 but they do not have quite the same form, and they are not 136 challenges. Using ABNF [RFC5234]:" 137 ; Can we use the RFC7230 #rule ABNF extension here? 138 Accept-Auth-values = Accept-Auth-value *( OWS "," 139 OWS Accept-Auth-value ) 140 Accept-Auth-value = auth-scheme [1*SP 141 ( auth-param *( "+" auth-param ) ] 142 auth-scheme = token 143 auth-param = token BWS "=" BWS ( token / quoted-string ) 144 token = 1*tchar 145 tchar = "!" / "'" / "*" / "-" / "." / "^" 146 / "_" / "`" / "|" / "~" / DIGIT / ALPHA 147 ; any VCHAR, except delimiters; here we use "+" 148 ; as a delimiter, so our token definition is 149 ; different from RFC7230's. 151 BWS = 152 OWS = 153 quoted-string = 155 Accept-Auth value ABNF. 157 Figure 1 159 4. The Redirect Authentication Scheme 161 Many sites use redirect-based protocols for authentication. such 162 protocols exchange cryptographic messages between a relying party 163 origin and an authenticator origin. Some such protocols use URI 164 query parameters to carry cryptographic messages. Others depend on 165 the browser HTML and ECMAScript ecosystem, using a script to run HTTP 166 requests from the authenticator to the relying party with a token in 167 Authorization request header. In the latter case, the server 168 exchanges the token for a cookie, and a script on the authenticator 169 page then effects a redirect by changing the window location. 171 Such redirect-based protocols do not work for non-browser user- 172 agents. 174 User-agents normally do not copy response headers from redirect 175 responses redirected requests. One common non-browser user-agent, 176 the PowerShell command-line user-agent [1], has an option, 177 "-PreserveAuthorizationOnRedirect" that causes it to copy 178 Authorization headers from redirect responses to redirected requests. 179 This enables some redirect-based workflows to work even though that 180 user-agent is not a browser, lacks interaction capabilities, HTML 181 rendering, or JavaScript support. 183 Here we define the "Redirect" HTTP authentication scheme. This 184 scheme lets arbitrary authentication (and authorization) protocols 185 exchange cryptographic messages between the relying party origin and 186 the authenticator origin over headers rather than URI parameters. 187 This is done by preserving a new header, "Authorization-Request" 188 across redirects, and the existing "Authorization" header across 189 redirects back to previous origins in the redirect chain. 191 For our purposes, a "redirect response" is either a 3xx redirect 192 response with a Location header, or a 401 response with a WWW- 193 Authenticate header naming the Redirect authentication scheme and a 194 Location header. 196 o User-agents that support the Redirect HTTP authentication scheme 197 MUST recognize a 401 Redirect challenge as a redirect response. 199 [[COMMENT_0: QUESTION: What, if anything, should we say about 200 the method used by the user-agent when chasing a redirection? 201 --NW]] 203 [[COMMENT_1: One possibility is to let the redirecting origin 204 specify the method and state some constraints (e.g., if the 205 original method cannot have a request body, then the next 206 method must be GET, else ???). --NW]] 208 [[COMMENT_2: Since the intent is to authenticate the user, a 209 GET should always be good enough. In particular, the 210 authenticator origin may not need to see the original request 211 body at all. --NW]] 213 o User-agents SHOULD also consider challenges for other 214 authentication schemes offered by the server. E.g., if the server 215 offers a Negotiate [RFC4559] challenge and a Redirect challenge, 216 the user-agent may choose either (or neither) of the two. 218 o User-agents that support the Redirect HTTP authentication scheme 219 MUST copy any Authorization-Request headers in redirect responses 220 to the redirected request. 222 o User-agents that support the Redirect HTTP authentication scheme 223 MUST copy any Authorization headers in redirect responses to the 224 redirected request when the redirect is to an origin seen earlier 225 in the same redirect chain. 227 o Servers needing to authenticate the user when the user-agent has 228 advertised support for the Redirect authentication scheme SHOULD 229 respond with a 401 with a "challenge" for the Redirect 230 authentication scheme and a Location header, and MAY include an 231 Authorization-Request header in the response that the user-agent 232 then MUST copy to the redirected request if it chooses to follow 233 the redirection. 235 o Servers that have been redirected to MUST apply local policy to 236 decide: 238 * whether to accept redirections from the redirecting origin; 240 * whether to further redirect the request (as usual) and whether 241 to set an Authorization-Request header in the redirect 242 response; 244 * whether to authenticate the user (as usual); 246 * whether to redirect back to the redirecting origin, and whether 247 to set an Authorization header in the redirect response. 249 o User-agents may consult the user (if interactive), and/or a local 250 policy (e.g., a white-list of acceptable origins for 251 redirections), in order to decide whether to follow the 252 redirection. 254 o Note that the redirected-to service should always have enough 255 information to decide whether to accept or reject a redirection 256 (e.g., via the Referer header), and MUST have and apply local 257 policy of its own. 259 Note that nothing in this document alters or obviates Cross-Origin 260 Resource Sharing policy and considerations. 262 5. Mixing Redirection and Authentication Requests 264 Making use of the new Accept-Auth, Accept-Redirect, and Accept- 265 Redirect-Auth request headers will often require no changes to 266 existing HTTP user-agents and servers. This is because the 267 application usually gets to set and inspect arbitrary headers. On 268 the server side it may be difficult for an application to add support 269 for the Redirect authentication scheme without modifying the HTTP 270 server. Therefore it may be difficult for an application to issue a 271 401 Redirect, and it may have to use a 3xx redirect instead. 273 Therefore, user-agents MUST treat 3xx and 401 Redirect responses 274 similarly, applying the same local policy in either case. 276 5.1. 3xx Responses with WWW-Authenticate 278 If a server responds with a 3xx and includes not only a Location 279 header but also a WWW-Authenticate header, then the redirect denotes 280 intent to authenticate the user. In this case, the user-agent SHALL 281 consider the response to be either a redirect or a request to 282 authenticate, at the user-agent's choice. The HTTP method to use at 283 the new Location SHALL be as specified for the status code used by 284 the server. 286 Note that many user-agents will not understand that such responses 287 represent an option to authenticate with some authentication scheme. 289 5.2. 401 Responses with Location 291 If a server responds with a 401 and includes not just a WWW- 292 Authenticate header but also a Location header, then the Location 293 header's presence denotes the intent to authenticate the user either 294 via the server's authentication scheme offerings, or redirection. In 295 this case, a user-agent conforming to this specification SHALL 296 consider the response to be either a redirect or a request to 297 authenticate, at the user-agent's choice, and SHOULD pick and execute 298 one of those two options. The user-agent SHOULD use the GET method 299 at the new Location, with the expectation of eventually being 300 redirected back to the original URI authority, at which point the 301 user-agent, if it chooses to retry the original request, SHOULD use 302 the original method. 304 Note that many user-agents will not understand that such responses 305 represent an option to chase a redirection. 307 6. Auth-params for Selected Authentication Mechanisms 309 We specify here a few OPTIONAL parameters for existing HTTP 310 authentication schemes that user-agents may use to convey relevant 311 information to a server. 313 o For the Basic [RFC2617] authentication mechanism, user-agents MAY 314 include a "realm" parameter. 316 o For the Digest [RFC2617] authentication mechanism, user-agents MAY 317 include "realm", "domain", "algorithm", and "qop-options" 318 parameters. 320 o For the Negotiate [RFC4559] authentication mechanism, user-agents 321 MAY include a "mechs" auth-param whose value is a whitespace- 322 separate list of Object IDentifiers (OIDs) in dotted number 323 notation. 325 o For the Redirect authentication mechanism defined here, we define 326 an auth-param, "auth-svcs" whose value is a list of whitespace- 327 separated domainnames that the user-agent will follow redirections 328 to. 330 7. Server-Side Selection of Authentication Schemes 332 Servers that support only one authentication scheme have no 333 difficulty choosing which scheme to use. For other servers, when the 334 user-agent does not include the Accept-Auth header in its request, we 335 have no advice. When a server supports multiple authentication 336 schemes and the user-agent does include the Accept-Auth header in its 337 request, then the server SHOULD select at least one scheme for a 401 338 response's WWW-Authenticate header that the user-agent also supports, 339 but the server MAY respond with a 3xx redirect response if the user- 340 agent indicated support for redirects via the Accept-Redirect header 341 or by advertising support for the Redirect HTTP authentication 342 scheme. 344 8. Acknowledgements 346 Ben Kaduk, Simo Sorce, Viktor Dukhovni, Bill Bernsen, Andrew Brown, 347 and Geoffrey Thomas provided feedback and some review. 349 9. IANA Considerations 351 IANA is requested to assign an expert to run the Expert Review for 352 the registration of the Accept-Auth, Accept-Redirect, Accept- 353 Redirect-Auth, and Authorization-Request headers in the message 354 header registry. 356 Upon completion of IETF Review, IANA is directed to add the Redirect 357 authentication scheme to the HTTP Authentication Scheme registry. 359 There is no registry for auth-params for HTTP authentication schemes, 360 nor do we request the creation of such a registry. The auth-params 361 used here bear some relation to those of the authentication schemes 362 they are used with, but they are essentially a distinct namespace. 363 Future additions of auth-params for use in the Accept-Auth header 364 will have to update this document. 366 10. Security Considerations 368 The Accept-Auth header is security-relevant as it helps negotiate 369 authentication, which is a positive consideration. Negative security 370 considerations include multi-level negotiation issues Section 10.1, 371 as well as a privacy concern: that the Accept-Auth header may help 372 fingerprint user-agents. 374 Privacy-conscious user-agents MAY have local policy about which 375 authorities to use the new Accept-Auth, Accept-Redirect, and Accept- 376 Redirect-Auth headers. 378 Also, the Authorization-Request and Authorization header preservation 379 behavior allows attackers to convey malformed tokens to victim 380 servers, allowing them to probe for parsing bugs. However, this is 381 essentially already true for the URI itself, therefore this is not a 382 new issue. Note that Authorization headers are not to be preserved 383 in all redirects, just those that backtrack in the redirect chain. 384 That means that there can be no confusion as to whether a given 385 Authorization header was added by the user-agent or a redirecting 386 origin: it will be either, but never both, and the relying party 387 origins don't care which it is. 389 One concern is that servers could cause user-agents to engage in 390 authentication schemes they shouldn't want to -- that is a 391 possibility regardless of whether the user-agent advertises support 392 for an authentication scheme or not. As usual, local policy is 393 relevant. For example, the "curl" user-agent by default will not 394 chase redirections, and if enabled, it will by default not 395 authenticate at any redirected authority (this can be further 396 enabled). User-agents SHOULD have local policy about which 397 redirections they will accept, whether to authenticate to redirected 398 authorities, and with what methods. For example, a user-agent may be 399 willing to use the Negotiate authentication scheme at some or any 400 redirected authorities if it is happy to let Kerberos 401 implementations, including Key Distribution Centers (KDCs), apply 402 policy on the user-agent's behalf, but may not be willing to perform 403 Basic, Digest, or SCRAM authentication to any redirected authorities 404 not on a local whitelist. 406 10.1. Multi-Level Negotiation 408 One important security consideration of the Accept-Auth header is 409 that it may lead to multiple levels of negotiation (e.g., via the 410 Negotiate [RFC4559] authentication method). Multi-level negotiations 411 can fail to select to select a workable option, or may select a sub- 412 optimal (e.g., less secure) option. 414 For example, a user-agent might be able to use Digest authentication 415 and Negotiate with some GSS-API [RFC2743] mechanism X, while the 416 server might be able to use Digest and Negotiate with some GSS-API 417 mechanism Y, and the server might prefer Y. If the server knows only 418 that the user-agent supports Digest and Negotiate, but not that the 419 user-agent does not support GSS-API mechanism Y, then the server may 420 send a challenge to use Negotiate and then the whole negotiation will 421 fail. 423 In the above example the user-agent could recover by retrying without 424 advertising Negotiate in its Accept-Auth header, but the user-agent 425 is not likely to do this on account of that being too complex. 426 Neither the user-agent nor the server are likely to detect and 427 recover from sub-optimal selections. 429 To avoid this failure more, user-agents SHOULD use auth-params to 430 convey information that the server might need to make an appropriate. 432 11. References 434 11.1. Normative References 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, 438 DOI 10.17487/RFC2119, March 1997, 439 . 441 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 442 Leach, P., Luotonen, A., and L. Stewart, "HTTP 443 Authentication: Basic and Digest Access Authentication", 444 RFC 2617, DOI 10.17487/RFC2617, June 1999, 445 . 447 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 448 Kerberos and NTLM HTTP Authentication in Microsoft 449 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, 450 . 452 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 453 Specifications: ABNF", STD 68, RFC 5234, 454 DOI 10.17487/RFC5234, January 2008, 455 . 457 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 458 Protocol (HTTP/1.1): Message Syntax and Routing", 459 RFC 7230, DOI 10.17487/RFC7230, June 2014, 460 . 462 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 463 Protocol (HTTP/1.1): Authentication", RFC 7235, 464 DOI 10.17487/RFC7235, June 2014, 465 . 467 11.2. Informative References 469 [RFC2743] Linn, J., "Generic Security Service Application Program 470 Interface Version 2, Update 1", RFC 2743, 471 DOI 10.17487/RFC2743, January 2000, 472 . 474 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 475 Kerberos Network Authentication Service (V5)", RFC 4120, 476 DOI 10.17487/RFC4120, July 2005, 477 . 479 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 480 Version 5 Generic Security Service Application Program 481 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 482 DOI 10.17487/RFC4121, July 2005, 483 . 485 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 486 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 487 . 489 11.3. URIs 491 [1] https://docs.microsoft.com/en- 492 us/powershell/module/microsoft.powershell.utility/invoke- 493 webrequest?view=powershell-7 495 Author's Address 497 Nico Williams (editor) 498 Cryptonector, LLC 499 Austin, TX 500 USA 502 Email: nico@cryptonector.com