Accept-Auth HTTP Header for 3xx/401 Negotiation, and Redirect Authentication Scheme
draft-williams-http-accept-auth-and-redirect-01

Internet Engineering Task Force                         N. Williams, Ed.
Internet-Draft                                         Cryptonector, LLC
Intended status: Standards Track                          March 31, 2020
Expires: October 2, 2020

     Accept-Auth HTTP Header for 3xx/401 Negotiation, and Redirect
                         Authentication Scheme
            draft-williams-http-accept-auth-and-redirect-01

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" and "Authorization-
   Request" headers across redirections.  This enables arbitrary
   authentication and authorization protocols to work without requiring
   user-agent support for them.

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 2, 2020                [Page 1]
Internet-Draft           Accept-Auth & Redirect               March 2020

   This Internet-Draft will expire on October 2, 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Accept-Redirect and       Accept-Redirect-Auth  . . . . . . .   3
   3.  Accept-Auth . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  The Redirect Authentication Scheme  . . . . . . . . . . . . .   4
   5.  Mixing Redirection and Authentication Requests  . . . . . . .   6
     5.1.  3xx Responses with WWW-Authenticate . . . . . . . . . . .   7
     5.2.  401 Responses with Location . . . . . . . . . . . . . . .   7
   6.  Auth-params for Selected Authentication Mechanisms  . . . . .   7
   7.  Server-Side Selection of Authentication Schemes . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
     10.1.  Multi-Level Negotiation  . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
     11.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

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

Williams                 Expires October 2, 2020                [Page 2]
Internet-Draft           Accept-Auth & Redirect               March 2020

   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.

   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 October 2, 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 ) ]
   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.

   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

Williams                 Expires October 2, 2020                [Page 4]
Internet-Draft           Accept-Auth & Redirect               March 2020

   exchange cryptographic messages between the relying party origin and
   the authenticator origin over headers rather than URI parameters.
   This is done by preserving a new header, "Authorization-Request"
   across redirects, and the existing "Authorization" header across
   redirects back to previous origins in the redirect chain.

   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]]

         [[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.  --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  User-agents that support the Redirect HTTP authentication scheme
      MUST copy any Authorization-Request headers in redirect responses
      to the redirected request.

   o  User-agents that support the Redirect HTTP authentication scheme
      MUST copy any Authorization headers in redirect responses to the
      redirected request when the redirect is to an origin seen earlier
      in the same redirect chain.

   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-Request header in the response that the user-agent

Williams                 Expires October 2, 2020                [Page 5]
Internet-Draft           Accept-Auth & Redirect               March 2020

      then MUST copy to the redirected request if it chooses to follow
      the redirection.

   o  Servers that have been redirected to MUST apply local policy to
      decide:

      *  whether to accept redirections from the redirecting origin;

      *  whether to further redirect the request (as usual) and whether
         to set an Authorization-Request 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
      (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.

5.  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.

Williams                 Expires October 2, 2020                [Page 6]
Internet-Draft           Accept-Auth & Redirect               March 2020

5.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.

5.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.

6.  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.

Williams                 Expires October 2, 2020                [Page 7]
Internet-Draft           Accept-Auth & Redirect               March 2020

   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.

7.  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
   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.

8.  Acknowledgements

   Ben Kaduk, Simo Sorce, Viktor Dukhovni, Bill Bernsen, Andrew Brown,
   and Geoffrey Thomas provided feedback and some review.

9.  IANA Considerations

   IANA is requested to assign an expert to run the Expert Review for
   the registration of the Accept-Auth, Accept-Redirect, Accept-
   Redirect-Auth, and Authorization-Request 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.

10.  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 10.1,
   as well as a privacy concern: that the Accept-Auth header may help
   fingerprint user-agents.

Williams                 Expires October 2, 2020                [Page 8]
Internet-Draft           Accept-Auth & Redirect               March 2020

   Privacy-conscious user-agents MAY have local policy about which
   authorities to use the new Accept-Auth, Accept-Redirect, and Accept-
   Redirect-Auth headers.

   Also, the Authorization-Request and Authorization header preservation
   behavior allows attackers to convey malformed tokens to victim
   servers, allowing them to probe for parsing bugs.  However, this is
   essentially already true for the URI itself, therefore this is not a
   new issue.  Note that Authorization headers are not to be preserved
   in all redirects, just those that backtrack in the redirect chain.
   That means that there can be no confusion as to whether a given
   Authorization header was added by the user-agent or a redirecting
   origin: it will be either, but never both, and the relying party
   origins don't care which it is.

   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 authentication scheme at some or any
   redirected authorities if it is happy to let Kerberos
   implementations, including Key Distribution Centers (KDCs), apply
   policy on the user-agent's behalf, but may not be willing to perform
   Basic, Digest, or SCRAM authentication to any redirected authorities
   not on a local whitelist.

10.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
   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.

Williams                 Expires October 2, 2020                [Page 9]
Internet-Draft           Accept-Auth & Redirect               March 2020

   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.

11.  References

11.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 October 2, 2020               [Page 10]
Internet-Draft           Accept-Auth & Redirect               March 2020

11.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>.

11.3.  URIs

   [1] https://docs.microsoft.com/en-
       us/powershell/module/microsoft.powershell.utility/invoke-
       webrequest?view=powershell-7

Author's Address

   Nico Williams (editor)
   Cryptonector, LLC
   Austin, TX
   USA

   Email: nico@cryptonector.com

Williams                 Expires October 2, 2020               [Page 11]