Internet DRAFT - draft-williams-http-accept-auth-and-redirect
draft-williams-http-accept-auth-and-redirect
Internet Engineering Task Force N. Williams, Ed.
Internet-Draft Cryptonector, LLC
Intended status: Standards Track April 8, 2020
Expires: October 10, 2020
Accept-Auth HTTP Header for 3xx/401 Negotiation, and Redirect
Authentication Scheme
draft-williams-http-accept-auth-and-redirect-02
Abstract
The Hyper-Text Transport Protocol (HTTP) offers several
authentication schemes, 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 new HTTP request headers by which many
applications can improve interoperability even without changing their
HTTP implementations. These new headers allow user-agents to
advertise authentication- and redirect-related capbilities that
servers can use to better make authentication and/or redirect
decisions.
Also specified is a new HTTP authentication scheme named "Redirect"
that enables communication between redirecting and redirected
authorities via preservation of "Authorization" headers across
redirections. This enables arbitrary authentication and
authorization protocols to work without requiring user-agent support
for them and without having to (ab)use URI query parameters.
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."
Williams Expires October 10, 2020 [Page 1]
Internet-Draft Accept-Auth & Redirect April 2020
This Internet-Draft will expire on October 10, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Accept-Redirect and Accept-Redirect-Auth . . . . . . . 3
3. Accept-Auth . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. The Redirect Authentication Scheme . . . . . . . . . . . . . 4
4.1. Redirect Examples . . . . . . . . . . . . . . . . . . . . . 7
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Applicability of Accept-* Headers . . . . . . . . . . . . . 8
5.2. Applicability of Redirect Auth Scheme . . . . . . . . . . . 8
6. Mixing Redirection and Authentication Requests . . . . . . . 9
6.1. 3xx Responses with WWW-Authenticate . . . . . . . . . . . . 9
6.2. 401 Responses with Location . . . . . . . . . . . . . . . . 10
7. Auth-params for Selected Authentication Mechanisms . . . . . 10
8. Server-Side Selection of Authentication Schemes . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11.1. Security Considerations for the Redirect Auth Scheme . . . 11
11.2. Multi-Level Negotiation . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 14
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
Williams Expires October 10, 2020 [Page 2]
Internet-Draft Accept-Auth & Redirect April 2020
1. Introduction
The Hyper-Text Transport Protocol (HTTP) RFC7230 [RFC7230] provides
several schemes for user authentication. There also are popular ways
of authenticating users based 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].
We address this problem by adding new request headers, "Accept-
Auth:", "Accept-Redirect-Auth:", and "Accept-Redirect:" 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-Redirect and Accept-Redirect-Auth
The Accept-Redirect request header has two possible values: "yes" and
"no". If "yes", this means the user-agent will follow redirections,
and the user-agent may or may not be willing to authenticate at the
redirected origin depending on local policy.
The Accept-Redirect-Auth request header exists to indicate which
authorities the user-agent is willing to redirect to and authenticate
at. Its value is a whitespace-separate list of domainnames. If
empty or has just the value ".", then the service can conclude only
that the user-agent has a whitelist, but is not disclosing it.
3. 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.
Williams Expires October 10, 2020 [Page 3]
Internet-Draft Accept-Auth & Redirect April 2020
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]:
; 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 ) ]
auth-scheme = 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
4. The Redirect Authentication Scheme
Many sites use redirect-based protocols for authentication. Such
protocols exchange cryptographic messages between a relying party
origin and an authenticator origin. Some such protocols use URI
query parameters to carry cryptographic messages. Others depend on
the browser HTML and ECMAScript ecosystem, using a script to run HTTP
requests from the authenticator to the relying party with a token in
Authorization request header. In the latter case, the server
exchanges the token for a cookie, and a script on the authenticator
page then effects a redirect by changing the window location.
Such redirect-based protocols do not work for non-browser user-
agents.
[[COMMENT_CB0: It might be good to also specify request headers for
redirected requests that user-agents can use for passing channel
binding information to auth services. E.g., Authorization-Channel-
Binding: <type> <cb-data>. This would allow Authorization tokens to
be channel-bound. Of course, there are difficulties here that would
require additional thinking. For example, using unique CB would
require that the user-agent keep a connection open to the redirecting
Williams Expires October 10, 2020 [Page 4]
Internet-Draft Accept-Auth & Redirect April 2020
origin. While end-point CB would fail if multiple servers serve the
same origin using different server certificates for the same names.
Binding to the dNSName and the issuer, however, would work, but that
would be a new CB type and would require registration in the IANA CB
type registry. CB support could always be added later. --NW]]
[[COMMENT_CB1: Possible new CB types include: dNSName+hash(issuer-
cert/SPKI), some sort of TLS session ID possibly constructed using
the TLS key material exporter but derived in such a way that it
identifies a set of connections resumed from the same original
handshake. The latter would be prone to failure on resumption if the
resumption ticket is rejected for any reason, but otherwise would
work really well for tokbind-style token protocols, especially for
user-agents that can retry. --NW]]
User-agents normally do not copy response headers from redirect
responses redirected requests. One common non-browser user-agent,
the PowerShell command-line user-agent [1], has an option,
"-PreserveAuthorizationOnRedirect" that causes it to copy
Authorization headers from redirect responses to redirected requests.
This enables some 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. This
scheme lets arbitrary authentication (and authorization) protocols
exchange cryptographic messages between the relying party origin and
the authenticator origin over headers rather than URI parameters.
This is done by copying ("preserving") any "Authorization" headers in
a redirect response to the redirected request.
For our purposes, a "redirect response" is either a 3xx redirect
response with a Location header, or a 401 response with a WWW-
Authenticate header naming the Redirect authentication scheme and a
Location header.
o User-agents that support the Redirect HTTP authentication scheme
MUST recognize a 401 Redirect challenge as a redirect response.
[[COMMENT_0: QUESTION: What, if anything, should we say about
the method used by the user-agent when chasing a redirection?
--NW]]
[[COMMENT_1: One possibility is to let the redirecting origin
specify the method and state some constraints (e.g., if the
original method cannot have a request body, then the next
method must be GET, else ???). --NW]]
Williams Expires October 10, 2020 [Page 5]
Internet-Draft Accept-Auth & Redirect April 2020
[[COMMENT_2: Since the intent is to authenticate the user, a
GET should always be good enough. In particular, the
authenticator origin may not need to see the original request
body at all, though it may need to know the original method,
and it can get that from the relying party (e.g., via the
Redirect header preservation mechanism). --NW]]
o User-agents SHOULD also consider challenges for other
authentication schemes offered by the server. E.g., if the server
offers a Negotiate [RFC4559] challenge and a Redirect challenge,
the user-agent may choose either (or neither) of the two.
o Unless rejected by local policy (or the user), user-agents that
support the Redirect HTTP authentication scheme MUST copy any
Authorization headers in redirect responses to the redirected
request.
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 and 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. Servers MAY use a 3xx response instead.
o Servers that have been redirected to MUST apply local policy to
decide:
* whether to accept redirections from the redirecting origin
(identified by the Referer header or by a cryptographic token
in the preserved Authorization header);
* whether to further redirect the request (as usual) and whether
to set an Authorization header in the redirect response;
* whether to authenticate the user (as usual);
* whether to redirect back to the redirecting origin, and whether
to set an Authorization header in the redirect response.
o User-agents may consult the user (if interactive), and/or a local
policy (e.g., a white-list of acceptable origins for
redirections), in order to decide whether to follow the
redirection.
o Note that the redirected-to service should always have enough
information to decide whether to accept or reject a redirection
Williams Expires October 10, 2020 [Page 6]
Internet-Draft Accept-Auth & Redirect April 2020
(e.g., via the Referer header), and MUST have and apply local
policy of its own.
Note that nothing in this document alters or obviates Cross-Origin
Resource Sharing policy and considerations.
4.1. Redirect Examples
Consider a URL https://janedoe.catvidhub.com.example/v0.mpg which
permanently redirects to https://janedoe.catvidhub.io.example/v0.mpg,
and suppose the latter also wants to authenticate users via
redirection to an authenticator at
https://auth.catvidhub.nu.example/. Let us label these A, B, and C
respectively.
The first redirection in this example is not involved in
authentication, and is included only to show that a redirection chain
where only parts of it are involved in authentication is possible.
In this example we should see a normal redirect from A to B, and at B
we should see a redirect to C, and then finally a redirect back from
C to B, and then B should serve the desired resource ("/v0.mpg") if C
provided the user-agent with a suitable token. Using the Redirect
auth scheme we should see:
o Server A would respond with a normal 3xx redirect to B, not a 401
authenticate-with-Redirect, and no Authorization headers in the
redirect response.
o Server B would respond with a 401 authenticate-with-Redirect
response and (possibly) a Authorization header in the response by
which it might send a signed request for authorization to the
"/v0.mpg" resource.
o Server C would check any Authorization headers in the request and
possibly authenticate the user-agent somehow (e.g., using any
cookies sent by the user-agent, using client certificates in TLS,
by responding with a 401 for the user-agent to authenticate using
some HTTP scheme, a further Redirect or plain redirection, or by
interacting with the user if the user-agent is a browser).
o Once the user is authenticated, server C would check the user's
authorization to access the resource ("/v0.mpg"), and if
permitted, would respond with a 3xx response with an Authorization
header bearing a cryptographic token for B attesting to the user's
authorization.
Williams Expires October 10, 2020 [Page 7]
Internet-Draft Accept-Auth & Redirect April 2020
o Finally, on the redirect back to B, the user-agent would preserve
the Authorization header from the response from C, which means
server B would see it, verify its integrity, decode it, and -if
the token grants access- then serve the resource.
5. Applicability
Two different and only somewhat related features are specified here.
One is intended to help interoperability in heterogeneous
environments with minimal or no changes to existing HTTP
implementations, just changes to applications. The other is intended
to perfect existing redirect-based authentication and authorization
protocols.
5.1. Applicability of Accept-* Headers
The purpose of the Accept-Auth Section 3, Accept-Redirect Section 2,
and Accept-Redirect-Auth Section 2 request headers is to improve
interoperability in heterogeneous environments with minimal or no
changes to HTTP implementations.
For example, an application could set these request headers on
requests without changes to the user-agent. That's because setting
arbitrary request headers is a common feature of HTTP user-agent
implementations.
It is also common for HTTP server implementations to allow
applications to inspect request headers produce 3xx redirect or 401
responses.
Thus one can modify client applications to set these headers, and
server applications to check them and choose between 3xx redirect and
401 authenticate options, as well as between authentication schemes,
based on the presence of those headers. All without changes to HTTP
implementations.
HTTP implementors will probably want to add support for these headers
directly, but that isn't necessary in order to improve
interoperability.
5.2. Applicability of Redirect Auth Scheme
The new HTTP auth scheme, Redirect Section 4 also can be implemented
without changes to HTTP implementations, but will be much more useful
if implemented at least by user-agents.
In the short-term, the HTTP auth scheme, Redirect, is not applicable
to any existing protocols or applications. However, existing
Williams Expires October 10, 2020 [Page 8]
Internet-Draft Accept-Auth & Redirect April 2020
authentication and authorization systems, such as various Security
Assertion Markup Language (SAML) profiles, as well as OpenID Connect
(OIDC) and OAuth 2.0 [RFC6749] mechanisms in general, such as JWT
[RFC7519], can be adapted to use Redirect. [[COMMENT_REFS_NEEDED0:
Need to add references for SAML. Bibxml does not have any entries
for OASIS specs! --NW]]
Specifically, it is better to use headers for communication between
relying parties and auth services than it is to use URI query
parameters, as the latter imposes on application designers. Besides
this, the Redirect auth scheme can greatly simplify adding support
for, e.g., JWT, even for non-browser applications.
Thus the Redirect HTTP auth scheme is more likely to be useful in the
future. Note though that given user-agent support for Redirect, it's
fairly easy to adapt SAML/OIDC/JWT identity providers to use it.
6. Mixing Redirection and Authentication Requests
Making use of the new Accept-Auth, Accept-Redirect, and Accept-
Redirect-Auth request headers will often require no changes to
existing HTTP user-agents and servers. This is because the
application usually gets to set and inspect arbitrary headers. On
the server side it may be difficult for an application to add support
for the Redirect authentication scheme without modifying the HTTP
server. Therefore it may be difficult for an application to issue a
401 Redirect, and it may have to use a 3xx redirect instead.
Therefore, user-agents MUST treat 3xx and 401 Redirect responses
similarly, applying the same local policy in either case.
6.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
the new Location SHALL be as specified for the status code used by
the server.
Note that many user-agents will not understand that such responses
represent an option to authenticate with some authentication scheme.
Williams Expires October 10, 2020 [Page 9]
Internet-Draft Accept-Auth & Redirect April 2020
6.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.
Note that many user-agents will not understand that such responses
represent an option to chase a redirection.
7. 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.
8. 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 October 10, 2020 [Page 10]
Internet-Draft Accept-Auth & Redirect April 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 indicated support for redirects via the Accept-Redirect header
or by advertising support for the Redirect HTTP authentication
scheme.
9. Acknowledgements
Ben Kaduk, Simo Sorce, Viktor Dukhovni, Bill Bernsen, Andrew Brown,
and Geoffrey Thomas provided feedback and some review.
10. IANA Considerations
IANA is requested to assign an expert to run the Expert Review for
the registration of the Accept-Auth, Accept-Redirect, and Accept-
Redirect-Auth headers in the message header registry.
Upon completion of IETF Review, IANA is directed to add the Redirect
authentication scheme to 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.
11. 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 11.2,
as well as a privacy concern: that the Accept-Auth header may help
fingerprint user-agents.
Privacy-conscious user-agents SHOULD have local policy about which
authorities to use the new Accept-Auth, Accept-Redirect, and Accept-
Redirect-Auth headers.
11.1. Security Considerations for the Redirect Auth Scheme
The Authorization header preservation behavior allows attackers to
convey malformed tokens to victim servers, allowing them to probe for
parsing bugs. However, this is already true for the URI itself,
therefore this is not a new issue.
Williams Expires October 10, 2020 [Page 11]
Internet-Draft Accept-Auth & Redirect April 2020
Open redirectors allow malicious redirects to sites that could set an
Authorization header on a redirect back to the site with the open
redirector. This would allow an attacker to make a user thing they
are logged in as themselves when they are instead logged in as the
attacker, and then the victim user might get fooled into sending the
attacker sensitive information. This is not a new problem, as it is
already a problem for auth systems, such as OIDC, that use URI query
parameters to convey cryptographic tokens ("codes" in OIDC parlance).
Open redirectors are a security vulnerability in general. Servers
MUST NOT implement open redirects.
Adding support for channel / token binding to the Redirect HTTP auth
scheme may well be possible and desirable. This would consist of
request headers set by the user-agent on redirected requests that
would carry channel binding (CB) data for one or more CB types
corresponding to the original origin (and/or previous hop).
One concern is that servers could cause user-agents to engage in
authentication schemes they shouldn't want to -- that is a
possibility regardless of whether the user-agent advertises support
for an authentication scheme or not. As usual, local policy is
relevant. For example, the "curl" user-agent by default will not
chase redirections, and if enabled, it will by default not
authenticate at any redirected authority (this can be further
enabled). User-agents SHOULD have local policy about which
redirections they will accept, whether to authenticate to redirected
authorities, and with what methods. For example, a user-agent may be
willing to use the Negotiate [RFC4559] authentication scheme at some
or any redirected authorities if it is happy to let Kerberos
[RFC4121] implementations, including Key Distribution Centers (KDCs),
apply policy on the user-agent's behalf, but may not be willing to
perform Basic [RFC2617], Digest [RFC2617], or SCRAM [RFC7804]
authentication to any redirected authorities not on a local
whitelist.
11.2. 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 October 10, 2020 [Page 12]
Internet-Draft Accept-Auth & Redirect April 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
selection.
12. References
12.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>.
Williams Expires October 10, 2020 [Page 13]
Internet-Draft Accept-Auth & Redirect April 2020
[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>.
12.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>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[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>.
[RFC7804] Melnikov, A., "Salted Challenge Response HTTP
Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804,
March 2016, <https://www.rfc-editor.org/info/rfc7804>.
12.3. URIs
[1] https://docs.microsoft.com/en-
us/powershell/module/microsoft.powershell.utility/invoke-
webrequest?view=powershell-7
Author's Address
Williams Expires October 10, 2020 [Page 14]
Internet-Draft Accept-Auth & Redirect April 2020
Nico Williams (editor)
Cryptonector, LLC
Austin, TX
USA
Email: nico@cryptonector.com
Williams Expires October 10, 2020 [Page 15]
