Internet Engineering Task Force N. Williams, Ed.
Internet-Draft Cryptonector, LLC
Intended status: Standards Track March 28, 2020
Expires: September 29, 2020
Accept-Auth HTTP Header for 3xx/401 Negotiation, and Redirect
Authentication Scheme
draft-williams-http-accept-auth-and-redirect-00
Abstract
The Hyper-Text Transport Protocol (HTTP) offers several
authentication chemes, but many sites use redirection-based protocols
to authenticate users. Some servers are faced with a connundrum,
having to choose between two mutually-exclusive options: redirect
responses or 401 (authentication required) responses without knowing
which the user-agent is most likely to support.
This document specifies a new HTTP request header, "Accept-Auth",
that user-agents may use to indicate their authentication
capabilities, including support (or not) for chasing redirects. Also
specified is a new HTTP authentication scheme named Redirect,
operating via 3xx or 401 responses at the server's choice.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Williams Expires September 29, 2020 [Page 1]
Internet-Draft Accept-Auth & Redirect March 2020
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Accept-Auth . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Redirect Authentication Scheme . . . . . . . . . . . . . 4
4. Mixing Redirection and Authentication Requests . . . . . . . 5
4.1. 3xx Responses with WWW-Authenticate . . . . . . . . . . . 5
4.2. 401 Responses with Location . . . . . . . . . . . . . . . 6
5. Auth-params for Selected Authentication Mechanisms . . . . . 6
6. Server-Side Selection of Authentication Schemes . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9.1. Multi-Level Negotiation . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The Hyper-Text Transport Protocol (HTTP) RFC7230 [RFC7230] provides
several schemes for user authentication. There also are popular ways
of authenticating users base on redirection rather than standard HTTP
authentication schemes. Heretofore, HTTP has provided no standard
way for servers to know which authentication schemes, including
redirect-based methods, a given user-agent supports, but servers must
choose between either redirection, or HTTP authentication, and these
two are mutually exclusive.
This situation arises especially in corporate networks where JSON Web
Tokens (JWT) [RFC7519] and Negotiate [RFC4559] are both used, the
latter usually with the Kerberos [RFC4120] GSS-API [RFC2743]
mechanism [RFC4121].
Williams Expires September 29, 2020 [Page 2]
Internet-Draft Accept-Auth & Redirect March 2020
We address this problem by adding a new request header, "Accept-
Auth:", by which a user-agent can indicate which HTTP authentication
schemes, if any, it supports, including redirection.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Accept-Auth
The Accept-Auth request header may have multiple values, or be
present multiple times, as with most HTTP headers. Each value names
one authentication schemes, and optionally may indicate schemes-
specific metadata.
One special value, a single asterisk, indicates that the user-agent
is unwilling to list the authentication schemes it supports, but if
sent, the server MAY assume that the user-agent supports redirection.
Another special value, "None", indicates that the user-agent has no
credentials and does not support even redirection. User-agents
SHOULD send no more than one special value, and SHOULD NOT send other
values if they send one of those special values.
Accept-Auth values are similar to WWW-Authenticate values [RFC7235],
but they do not have quite the same form, and they are not
challenges. Using ABNF [RFC5234]:"
Williams Expires September 29, 2020 [Page 3]
Internet-Draft Accept-Auth & Redirect March 2020
; Can we use the RFC7230 #rule ABNF extension here?
Accept-Auth-values = Accept-Auth-value *( OWS ","
OWS Accept-Auth-value )
Accept-Auth-value = auth-scheme [1*SP
( auth-param *( "+" auth-param ) ]
; The * auth-scheme indicates that the user-agent supports at least
; the use of redirection, and may support other schemes but does not
; wish to indicate which. The None auth-scheme indicates that the
; user-agent does not wish to authenticate in any way.
auth-scheme = "*" / "None" / token
auth-param = token BWS "=" BWS ( token / quoted-string )
token = 1*tchar
tchar = "!" / "'" / "*" / "-" / "." / "^"
/ "_" / "`" / "|" / "~" / DIGIT / ALPHA
; any VCHAR, except delimiters; here we use "+"
; as a delimiter, so our token definition is
; different from RFC7230's.
BWS = <BWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
Accept-Auth value ABNF.
Figure 1
3. The Redirect Authentication Scheme
Many sites use redirect-based protocols. Often such sites depend on
user-agents being interactive browsers with JavaScript enabled so
that when authentication is completed at some remote authenticator
service, it can redirect the user-agent by changing the window
location using JavaScript after having performed an XmlHttpRequest
back to the origin with an Authorization header to obtain a cookie.
Such redirect-based protocols do not work for non-browser user-
agents.
Normally, user-agents do not copy response headers from redirect
responses redirected requests. One common non-browser user-agent,
the PowerShell command-line user-agent, has an option that causes it
to copy Authorization headers from redirect responses to redirected
requests, which enables redirect-based workflows to work even though
that user-agent is not a browser, lacks interaction capabilities,
HTML rendering, or JavaScript support.
Here we define the "Redirect" HTTP authentication scheme, consisting
of these behaviors:
Williams Expires September 29, 2020 [Page 4]
Internet-Draft Accept-Auth & Redirect March 2020
o Servers needing to authenticate the user when the user-agent has
advertised support for the Redirect authentication scheme SHOULD
respond with a 401 with a "challenge" for the Redirect
authentication scheme, in which case servers MUST include a
Location header, and MAY include an Authorization header in the
response that the user-agent then MUST copy to the redirected
request if it chooses to follow the redirection.
o User-agents MUST recognize a 401 Redirect challenge as a form of
redirection.
o User-agents SHOULD also consider challenges for other
authentication schemes offered by the server.
o User-agents MAY consult the user, or a white-list of acceptable
origins for redirections, in order to decide whether to follow the
redirection.
o Because the intent of a Redirect challenge is to authenticate, if
the user-agent decides to follow the redirection, then the user-
agent SHOULD use switch to the GET method for the redirected
request, and upon being redirected back to the original server,
the user-agent MUST switch back to the original method.
4. Mixing Redirection and Authentication Requests
In HTTP, servers can either respond with a 3xx redirect, or a 401,
but not both at once. Besides the status codes, there is also
response header content that is relevant to effecting a redirect or
requesting authentication -- these two can be combined even if the
status codes cannot. Existing user-agents wouldn't respond in the
obvious way because their response is generally keyed off of the
server's response status code.
User-agents that conform to this specification MUST support the
Redirect authentication scheme as described in Section 3.
Additionally, user-agents conforming to this specification MUST
support the two cases described below as a degenerate form of the
Redirect authentication scheme.
4.1. 3xx Responses with WWW-Authenticate
If a server responds with a 3xx and includes not only a Location
header but also a WWW-Authenticate header, then the redirect denotes
intent to authenticate the user. In this case, the user-agent SHALL
consider the response to be either a redirect or a request to
authenticate, at the user-agent's choice. The HTTP method to use at
Williams Expires September 29, 2020 [Page 5]
Internet-Draft Accept-Auth & Redirect March 2020
the new Location SHALL be as specified for the status code used by
the server.
4.2. 401 Responses with Location
If a server responds with a 401 and includes not just a WWW-
Authenticate header but also a Location header, then the Location
header's presence denotes the intent to authenticate the user either
via the server's authentication scheme offerings, or redirection. In
this case, a user-agent conforming to this specification SHALL
consider the response to be either a redirect or a request to
authenticate, at the user-agent's choice, and SHOULD pick and execute
one of those two options. The user-agent SHOULD use the GET method
at the new Location, with the expectation of eventually being
redirected back to the original URI authority, at which point the
user-agent, if it chooses to retry the original request, SHOULD use
the original method.
5. Auth-params for Selected Authentication Mechanisms
We specify here a few OPTIONAL parameters for existing HTTP
authentication schemes that user-agents may use to convey relevant
information to a server.
o For the Basic [RFC2617] authentication mechanism, user-agents MAY
include a "realm" parameter.
o For the Digest [RFC2617] authentication mechanism, user-agents MAY
include "realm", "domain", "algorithm", and "qop-options"
parameters.
o For the Negotiate [RFC4559] authentication mechanism, user-agents
MAY include a "mechs" auth-param whose value is a whitespace-
separate list of Object IDentifiers (OIDs) in dotted number
notation.
o For the Redirect authentication mechanism defined here, we define
an auth-param, "auth-svcs" whose value is a list of whitespace-
separated domainnames that the user-agent will follow redirections
to.
6. Server-Side Selection of Authentication Schemes
Servers that support only one authentication scheme have no
difficulty choosing which scheme to use. For other servers, when the
user-agent does not include the Accept-Auth header in its request, we
have no advice. When a server supports multiple authentication
schemes and the user-agent does include the Accept-Auth header in its
Williams Expires September 29, 2020 [Page 6]
Internet-Draft Accept-Auth & Redirect March 2020
request, then the server SHOULD select at least one scheme for a 401
response's WWW-Authenticate header that the user-agent also supports,
but the server MAY respond with a 3xx redirect response if the user-
agent advertised support for the Redirect scheme, or advertised the
"*" special scheme name.
7. Acknowledgements
Viktor Dukhovni, Bill Bernsen, and Geoffrey Thomas, provided feedback
and some review.
8. IANA Considerations
IANA is directed to register the Accept-Auth header in the message
header registry, as well as the Redirect authentication scheme in the
HTTP Authentication Scheme registry.
There is no registry for auth-params for HTTP authentication schemes,
nor do we request the creation of such a registry. The auth-params
used here bear some relation to those of the authentication schemes
they are used with, but they are essentially a distinct namespace.
Future additions of auth-params for use in the Accept-Auth header
will have to update this document.
9. Security Considerations
The Accept-Auth header is security-relevant as it helps negotiate
authentication, which is a positive consideration. Negative security
considerations include multi-level negotiation issues Section 9.1, as
well as a privacy concern: that the Accept-Auth header may help
fingerprint user-agents.
The special Accept-Auth value '*' can be used to reduce the user-
agent's fingerprint, at the cost of limiting the server's knowledge
of what authentication schemes the user-agent supports.
9.1. Multi-Level Negotiation
One important security consideration of the Accept-Auth header is
that it may lead to multiple levels of negotiation (e.g., via the
Negotiate [RFC4559] authentication method). Multi-level negotiations
can fail to select to select a workable option, or may select a sub-
optimal (e.g., less secure) option.
For example, a user-agent might be able to use Digest authentication
and Negotiate with some GSS-API [RFC2743] mechanism X, while the
server might be able to use Digest and Negotiate with some GSS-API
mechanism Y, and the server might prefer Y. If the server knows only
Williams Expires September 29, 2020 [Page 7]
Internet-Draft Accept-Auth & Redirect March 2020
that the user-agent supports Digest and Negotiate, but not that the
user-agent does not support GSS-API mechanism Y, then the server may
send a challenge to use Negotiate and then the whole negotiation will
fail.
In the above example the user-agent could recover by retrying without
advertising Negotiate in its Accept-Auth header, but the user-agent
is not likely to do this on account of that being too complex.
Neither the user-agent nor the server are likely to detect and
recover from sub-optimal selections.
To avoid this failure more, user-agents SHOULD use auth-params to
convey information that the server might need to make an appropriate.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999,
<https://www.rfc-editor.org/info/rfc2617>.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<https://www.rfc-editor.org/info/rfc4559>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
Williams Expires September 29, 2020 [Page 8]
Internet-Draft Accept-Auth & Redirect March 2020
10.2. Informative References
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743,
DOI 10.17487/RFC2743, January 2000,
<https://www.rfc-editor.org/info/rfc2743>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005,
<https://www.rfc-editor.org/info/rfc4120>.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
DOI 10.17487/RFC4121, July 2005,
<https://www.rfc-editor.org/info/rfc4121>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
Author's Address
Nico Williams (editor)
Cryptonector, LLC
Austin, TX
USA
Email: nico@cryptonector.com
Williams Expires September 29, 2020 [Page 9]