draft-vanrein-httpauth-sasl-00.txt

Network Working Group                                        R. Van Rein
Internet-Draft                                                 ARPA2.net
Intended status: Standards Track                         August 14, 2017
Expires: February 15, 2018


                     HTTP Authentication with SASL
                     draft-vanrein-httpauth-sasl-00

Abstract

   Most application-level protocols standardise their authentication
   exchanges under the SASL framework.  HTTP has taken another course,
   and often ends up replicating the work to allow individual
   mechanisms.  This specification adopts full SASL authentication into
   HTTP.

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 http://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 February 15, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (http://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.



Van Rein                Expires February 15, 2018               [Page 1]

Internet-Draft                  HTTP SASL                    August 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Embedding SASL in HTTP  . . . . . . . . . . . . . . . . . . .   3
     2.1.  HTTP Request and Response Messages  . . . . . . . . . . .   4
     2.2.  Authentication Field Definitions  . . . . . . . . . . . .   5
   3.  Standardising User-Aware HTTP . . . . . . . . . . . . . . . .   6
     3.1.  User-Aware HTTP Servers . . . . . . . . . . . . . . . . .   6
     3.2.  User-Aware HTTP Clients . . . . . . . . . . . . . . . . .   7
     3.3.  User-Aware HTTP Proxies . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  SASL Authentication Examples . . . . . . . . . . . .  11
     A.1.  Mechanism Inquiry . . . . . . . . . . . . . . . . . . . .  11
     A.2.  SASL EXTERNAL . . . . . . . . . . . . . . . . . . . . . .  11
     A.3.  SASL ANONYMOUS  . . . . . . . . . . . . . . . . . . . . .  12
     A.4.  SASL SCRAM-SHA-1  . . . . . . . . . . . . . . . . . . . .  12
     A.5.  GS2 Kerberos5 with TLS Channel Binding  . . . . . . . . .  13
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   HTTP has historically followed its own path for client
   authentication, while many other end-user protocols standardised on
   SASL; examples of SASL protocols include SMTP, IMAP, POP, XMPP, LDAP
   and AMQP.  This specification introduces SASL to HTTP, so it may
   share in past and future work done for SASL in general.

   Among the work that could be shared is backend authentication
   integration, which is possible due to protocol-independent SASL
   exchanges for any given method, making it easy to take them out of
   one protocol and inserting them into another.  Although HTTP has
   adopted several SASL-compatible authentication methods, it has uses
   various notations and so it still needs method-specific support at
   the HTTP level to translate them to a SASL backend.

   In front-ends, a similar situation has arisen.  The varying syntaxes
   for authentication methods have made it difficult to rely on support
   in most or all HTTP clients.  When such clients could externalise
   their SASL handling to generic software such as a SASL library, then
   any extension to a library automatically spills over into the HTTP
   sphere.  It is common for developers of web clients to also produce
   email clients, so a shared code base (and credential store) is not
   difficult to imagine.



Van Rein                Expires February 15, 2018               [Page 2]

Internet-Draft                  HTTP SASL                    August 2017


   Sharing is beneficial in both directions.  HTTP benefits by being
   able to use GS2 mechanisms [RFC5801] with channel binding to TLS; for
   instance Kerberos5 currently uses Negotiate authentication [RFC4559]
   which is not as secure as GS2-KRB5-PLUS over SASL.

   SASL also benefits; had it been the norm for HTTP, then the work to
   pass SAML over it [RFC6595] would probably have been done
   immediately.  In fact, HTTP can still benefit from receiving
   standardised SAML20 inquiries over SASL, becuase it resolves the need
   for configuration of initiation paths and practices.  Also, it
   removes authentication data from URIs, where they are not ideally
   placed.

   TODO: Does this do justice to current SAML over HTTP?

   In terms of security for HTTP applications, it appears beneficial to
   have very good authentication capabilities in the layers below the
   application; this is specifically true for applications developed in
   HTML and JavaScript, which tend to load code from various places,
   including code that is not always in the end user's interest; since
   it already is a concern what identity information passes through
   these applications, it is certainly not advisable to use credentials
   in those places.  Browsers are in a better position to take control
   over these assets, at the protocol levels of HTTP and TLS, and
   conceal credentials and possibly also identity from applications
   running on top.

2.  Embedding SASL in HTTP

   This specification integrates the SASL framework [RFC4422] into
   mainstream HTTP [RFC2616].  The SASL Authentication scheme follows
   the general structure for HTTP Authentication [RFC7235].  It uses the
   WWW-Authenticate and Proxy-Authenticate headers in responses from web
   servers and web proxies, respectively, and correspondingly the
   Authorization and Proxy-Authorization request header to answer to
   requests.

   The SASL service name for the following embedding of SASL is HTTP;
   contrary to most other service names, it is spelled in uppercase, in
   line with what has become general practice in Kerberos and GSSAPI.

   Since SASL prescribes channel binding to occur relative to TLS
   instead of to the application protocol, we can add that when the
   HTTPS transport is used.  According to SASL, at least tls-unique
   [Section 3 of [RFC5929]] must be supported.






Van Rein                Expires February 15, 2018               [Page 3]

Internet-Draft                  HTTP SASL                    August 2017


2.1.  HTTP Request and Response Messages

   This section defines a few names for HTTP request and response
   messages, to be used in the remainder of this specification.

   Initial Responses are those HTTP responses that set a status code 401
   or 407, and that are sent when the HTTP server decides to initiate an
   authentication exchange.

   Initial Requests are those HTTP requests that a client sends to
   initiate a fresh SASL authentication.  User-Aware Requests are a
   variation defined further below, intended for attempts to address
   public resources under a given user name.

   Intermediate Responses are HTTP responses to SASL authentication,
   with a status code set to 401 or 407.  Intermediate Requests are
   those HTTP requests that a client sends to continue a SASL
   authentication after an Intermediate Response.

   Final Responses either set a 200 or 403 status code, the first
   depicting success and the second depicting failure.  Information in a
   Final 200 Response is provided in an Authentication-Info or Proxy-
   Authentication-Info header [RFC7615] instead of the headers used in
   Initial Responses and Intermediate Responses [RFC7235].  Note that
   proper interpretation of the Final 200 Response requires client state
   indicating that SASL authentication was used, or else the optional
   fields are not completely reliable information sources; cryptographic
   markers in the c2c field MAY be used to overcome this in a manner
   that defies abuse by rogue servers.  The Final 403 Response never
   contains authentication-related headers.

   The following fields, defined in upcoming sections, MUST and MAY be
   present in HTTP authentication exchanges for SASL:

   Request or Response   | MUST have fields     | MAY have fields
   ----------------------+----------------------+----------------
   Initial Response      | mech,s2s,realm       | text
   Initial Request       | mech,s2s,c2c,realm   | c2s
   User-Aware Request    | mech,c2s             |
   Intermediate Response | mech,c2c,c2s,s2c,s2s | text
   Intermediate Request  | mech,c2c,c2s,s2c,s2s |
   Final 200 Response    | mech,c2c,name,realm  | s2c,c2s,s2s
   Final 403 Response    |                      |








Van Rein                Expires February 15, 2018               [Page 4]

Internet-Draft                  HTTP SASL                    August 2017


2.2.  Authentication Field Definitions

   Data for SASL is transported in the following fields:

   c2s   SASL mechanism data from client to server, that the server MUST
         reflect in an following Intermediate Response, or set to an
         empty string when absent from an Initial Request.

   s2c   SASL mechanism data from server to client, that the client MUST
         reflect in following Initial Requests or Intermediate Requests.

   s2s   holds opaque server data which the client MUST reflect in
         Intermediate Requests, to implement stateless SASL handling in
         the server.  This is a requirement for the HTTP Authentication
         framework [Section 5.1.2 of [RFC7235]].

   c2c   holds opaque client data which the server MUST reflect in
         Intermediate Responses and Final 200 Responses.  This helps to
         also make the client stateless.

   As in other protocols, it is not safe for all SASL mechanisms to
   exchange c2s and s2c messages over unprotected transports.  The c2c
   and s2s fields MUST be protected against tampering by rogue peers,
   and such protection also protects against tampering by rogue
   intermediates when using an unprotected transport.  In addition, c2c
   and s2s fields may also need to be concealed from peers and
   intermediates.

   Whether s2c is supplied in a Final 200 Response depends on the SASL
   mechanism, which may or may not have additional data to provide in
   this phase.  Note that SASL requires empty s2c messages to be
   distinguished from absence thereof.  When the server provides c2s
   and/or s2s data in a Final 200 Response, then it indicates that the
   supplied fields MAY provide one-step re-authentication with an empty
   s2c string, but the server MAY revoke this privilege at any time and
   for any reason; it would respond with an Initial Response in case of
   such revocation, but with a quick Final 200 Response if the one-step
   re-authentication is still acceptable.

   The following fields support SASL within the HTTP Authentication
   Framework:

   mech  selects the SASL mechanism to use.  It MUST be reflected from
         the preceding message, except: In an Initial Response, the
         field is filled with a space-separated list of SASL mechanism
         names; In an Initial Request, the client chooses one SASL
         mechanism name; In a User-Aware Request, the field is fixated
         to ANONYMOUS.



Van Rein                Expires February 15, 2018               [Page 5]

Internet-Draft                  HTTP SASL                    August 2017


   name  is the authorised user@domain.name or domain.name identity.

   text  is a user-oriented text explaining what information is needed.

   realm indicates the scope of authorisation.

3.  Standardising User-Aware HTTP

   This section specifies an optional extension to HTTP SASL.  HTTP
   clients, servers and proxies that adopt it will be called User-Aware.
   The purpose of User-Aware resources is to have standardised locations
   for user pages, including personal well-known URIs [RFC5785].

   Most protocols attach a service to a domain name or host name, and
   have a form like john@example.com to zoom in on a user of the
   service.  But although HTTP URIs can express user names, it lacks a
   standard interpretation of their meaning.  Ideally, access to user
   resources should support a mixture of public and protected resources.
   A possible approach is hereby proposed, using a User-Aware Request as
   introduced in Section 2.

   Whether or not content found with a user name is dynamic or static is
   orthogonal to the additional resource location information.  For
   caches, it is therefore possible to cache such content as soon as
   they recognise the lack of impact of SASL ANONYMOUS authentication on
   the content and its secrecy.

3.1.  User-Aware HTTP Servers

   User-Aware HTTP servers MUST NOT assume successful authentication
   when presented with a User-Aware Request.  It MAY however treat the
   c2s field as a modifier while locating public resources.  What the
   impact of this modifier is, if any, is an implementation matter of
   the server.  Intuitively, the c2s field can be made to feel like a
   user name whose data is requested, or a view on data, or just a
   sequence of requests that can easily be traced.  HTTP servers MAY log
   a trace message containing the c2s string.

   When a User-Aware Request addresses a resource that is not public,
   the server MAY send a Final 403 Response, or otherwise it MUST send
   an Initial Response.  The HTTP authentication exchange following the
   latter should then complete before deciding on resource access.

   An HTTP server may redirect a User-Aware Request with the HTTP
   Location header.  While constructing the new HTTP URI, the server MAY
   include the user field from the User-Aware Request, but only when
   redirecting to the same protocol, host name and port; configuration
   directives often have a relative URI notation for this purpose.  A



Van Rein                Expires February 15, 2018               [Page 6]

Internet-Draft                  HTTP SASL                    August 2017


   newly constructed HTTP URI with a different protocol, host name or
   port MUST NOT copy the user name from the User-Aware Request.

3.2.  User-Aware HTTP Clients

   When an HTTP URI contains a user name, then User-Aware HTTP clients
   MUST produce the User-Aware authentication header.  The c2s string,
   called a trace string in the SASL ANONYMOUS mechanism, is set to the
   user name portion of the HTTP URI.

   TODO: This assumes that all non-User-Aware HTTP Servers ignore the
   User-Aware Request's extras.  We tried Nginx, Apache and IIS, and
   they agree.  RFC 2616 also suggests that the client may choose to
   authenticate.

   At any time when provided with a User-Aware Request, the User-Aware
   HTTP server may decide to request authentication through an Initial
   Response.  It now matters whether the HTTP URI also contains a
   password.  With a password available, the User-Aware client SHOULD
   select a password-based SASL mechanism that it considers sufficiently
   secure.  Without a password available, the client is free to select
   any of the mechanisms supplied.  Even SASL ANONYMOUS may be chosen,
   though it must then be sent as an Initial Request, rather than as a
   User-Aware Request, so it can be distinguished as an explicit choice
   to skip authentication.

   HTTP clients may be referenced or redirected from one HTTP URI to
   another.  The client MUST NOT consider a reference with a username,
   and possibly even a password, to be an attack; it may hold a tracing
   identity, but so can paths and cookies; and the password can be
   useful, especially when it is short-lived and personalised.  When
   processing a step to another HTTP URI through a notation for an
   absolute URI, then a comparison is made of the protocol, user name,
   host name and port.  Only when all fields match and when no password
   is specified SHOULD the User-Aware HTTP client insert a password from
   the previous URI to the newly specified URI.  In notations that may
   hold a relative URI, such as in HTML references, the comparison is
   more strict; for those, there MUST NOT be any mentioning of the
   protocol, user name, password or host name if the user name and
   password are to be taken along to the new URI.

3.3.  User-Aware HTTP Proxies

   User-Aware HTTP proxies MAY store responses to User-Aware Requests
   when no other reasons disallow it, but they MUST use the c2s string
   as an additional part of the resource identity.  In other words, the
   stored resource MUST NOT be returned for requests that are not User-
   Aware Requests, or that carry a different c2s string.  This only



Van Rein                Expires February 15, 2018               [Page 7]

Internet-Draft                  HTTP SASL                    August 2017


   concerns Authorization header fields, not those in a Proxy-
   Authorization header.

   TODO: Do we ever use Proxy-Authorization in User-Aware Requests?

4.  Security Considerations

   The SASL exchange may be at risk of tampering when the sequence of
   HTTP messages is not secured to form one stream.  The termination of
   such a secure layer MUST also terminate an ongoing SASL handshake.

   SASL EXTERNAL can be a very efficient mechanism to combine with a
   secure transport layer if that includes authentication.  This may be
   the case for TLS, especially when client-side authentication is
   deployed.  Mechanisms other than EXTERNAL should take into account
   that a relation may exist between identities negotiated in the
   protective layer and the SASL exchange over HTTP.

   Channel binding is available in some SASL mechanisms.  When used with
   HTTP SASL, it binds to the TLS channel, by default using the type
   tls-unique [Section 3 of [RFC5929]].  When doing so, it is vital that
   either there be no renegotiation of the TLS handshake, or both secure
   renegotiation [RFC5746] and the extended master secret [RFC7627] are
   used.

5.  IANA Considerations

   This specification extends the "Hypertext Transfer Protocol (HTTP)
   Authentication Scheme Registry" with an "Authentication Scheme Name"
   SASL, referencing this specification.

   This specification defines an additional entry in the registry
   "Generic Security Service Application Program Interface
   (GSSAPI)/Kerberos/Simple Authentication and Security Layer (SASL)
   Service Names" namely:

   Service Name: HTTP
   Usage:        Web authentication using the SASL framework
   Reference:    TBD:this specification

6.  References

6.1.  Normative References








Van Rein                Expires February 15, 2018               [Page 8]

Internet-Draft                  HTTP SASL                    August 2017


   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616,
              DOI 10.17487/RFC2616, June 1999,
              <http://www.rfc-editor.org/info/rfc2616>.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              DOI 10.17487/RFC4120, July 2005,
              <http://www.rfc-editor.org/info/rfc4120>.

   [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,
              <http://www.rfc-editor.org/info/rfc4559>.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,
              <http://www.rfc-editor.org/info/rfc4422>.

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
              <http://www.rfc-editor.org/info/rfc5056>.

   [RFC5554]  Williams, N., "Clarifications and Extensions to the
              Generic Security Service Application Program Interface
              (GSS-API) for the Use of Channel Bindings", RFC 5554,
              DOI 10.17487/RFC5554, May 2009,
              <http://www.rfc-editor.org/info/rfc5554>.

   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
              "Transport Layer Security (TLS) Renegotiation Indication
              Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
              <http://www.rfc-editor.org/info/rfc5746>.

   [RFC5801]  Josefsson, S. and N. Williams, "Using Generic Security
              Service Application Program Interface (GSS-API) Mechanisms
              in Simple Authentication and Security Layer (SASL): The
              GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801,
              July 2010, <http://www.rfc-editor.org/info/rfc5801>.

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
              <http://www.rfc-editor.org/info/rfc5929>.






Van Rein                Expires February 15, 2018               [Page 9]

Internet-Draft                  HTTP SASL                    August 2017


   [RFC6595]  Wierenga, K., Lear, E., and S. Josefsson, "A Simple
              Authentication and Security Layer (SASL) and GSS-API
              Mechanism for the Security Assertion Markup Language
              (SAML)", RFC 6595, DOI 10.17487/RFC6595, April 2012,
              <http://www.rfc-editor.org/info/rfc6595>.

   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,
              <http://www.rfc-editor.org/info/rfc7235>.

   [RFC7615]  Reschke, J., "HTTP Authentication-Info and Proxy-
              Authentication-Info Response Header Fields", RFC 7615,
              DOI 10.17487/RFC7615, September 2015,
              <http://www.rfc-editor.org/info/rfc7615>.

   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,
              <http://www.rfc-editor.org/info/rfc7627>.

6.2.  Informative References

   [RFC4505]  Zeilenga, K., "Anonymous Simple Authentication and
              Security Layer (SASL) Mechanism", RFC 4505,
              DOI 10.17487/RFC4505, June 2006,
              <http://www.rfc-editor.org/info/rfc4505>.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              DOI 10.17487/RFC5785, April 2010,
              <http://www.rfc-editor.org/info/rfc5785>.

   [RFC5802]  Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
              "Salted Challenge Response Authentication Mechanism
              (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
              DOI 10.17487/RFC5802, July 2010,
              <http://www.rfc-editor.org/info/rfc5802>.

   [RFC7804]  Melnikov, A., "Salted Challenge Response HTTP
              Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804,
              March 2016, <http://www.rfc-editor.org/info/rfc7804>.








Van Rein                Expires February 15, 2018              [Page 10]

Internet-Draft                  HTTP SASL                    August 2017


Appendix A.  SASL Authentication Examples

   This section is non-normative.  It shows a number of examples of SASL
   exchanges over HTTP.

A.1.  Mechanism Inquiry

   Normally, a client is not aware of the need to authenticate, and in
   these cases it is sent an Initial Response.  For example, the Initial
   401 Response could be

   WWW-Authenticate: SASL mech="EXTERNAL ANONYMOUS GS2-KRB5"

   which indicates that this resource offers a choice, but nonetheless
   offers the option of ANONYMOUS authentication (which implies guest
   access only) and more uplifting options through EXTERNAL and GS2-KRB5
   authentication.  The client now chooses a SASL mechanism name for its
   Initial Request and both client and server continue to reflect it
   back and forth for the remainder of the authentication.

   There is no explicit mechanism for asking the server about the
   available SASL mechanisms, because this may depend on request aspects
   like the location and method.  To find out what the options are, it
   is best to simply attempt the intended access.

A.2.  SASL EXTERNAL

   The SASL EXTERNAL mechanism refers the context in which HTTP is run,
   such as its transport protocol, and attempts to infer client
   authenticity from it.  The normal context that can answer to this
   desire is the TLS transport; the client identity can be provided in a
   TLS handshake using an X.509 certificate, an OpenPGP key, a Kerberos
   ticket or an SRP handshake.  Each of these allow the derivation of a
   user name and its realm.

   The EXTERNAL mechanism [Appendix A of [RFC4422]] can simply be stated
   by the client, either when the server requests authentication or when
   the client wants to provide it, and should pass through without
   further interaction.  To authenticate as john@example.com, the
   request should contain

   Authorization: SASL mech="EXTERNAL",realm="example.com",
                  c2s="john",c2c=data0

   which would immediately lead to a Final Response.  Note that a Final
   200 Response mentions the realm and name that were actually
   authorized, and these may differ from the requested names.  SASL
   EXTERNAL is a very easy-to-use HTTP authentication method, and it is



Van Rein                Expires February 15, 2018              [Page 11]

Internet-Draft                  HTTP SASL                    August 2017


   arguably the most secure; given the dynamic nature and mixed origin
   of HTTP resources, it can be helpful to rely on lower layers such as
   the transport layer that is usually less involved in the dynamic
   resource mix.

A.3.  SASL ANONYMOUS

   The ANONYMOUS mechanism is another simple method.  It indicates a
   lacking desire to authenticate as a particular user.  This SASL
   method defines the c2s data as trace information [RFC4505] so the
   Initial Request

   Authorization: SASL mech="ANONYMOUS",realm="example.com",
                  c2c=data0,c2s="knock, knock"

   would probably log the "knock, knock" string but lead to guest-level
   access rights.  An important use of this SASL method is that it
   reflects an explicit client choice to access a resource as a guest,
   which brings it across the Initial Response that may be returned from
   the HTTP server when a resource requires authentication.

   Note the difference with a User-Aware SASL ANONYMOUS header

   Authorization: SASL mech="ANONYMOUS",c2s="knocker"

   which would not be considered an authentication attempt because the
   s2s and c2c fields are missing.  Instead, an attempt is made to serve
   public data for user knocker for the requested resource location.
   The server may decide to initiate an authentication exchange for the
   resource location if it deems the contents to not be public.

A.4.  SASL SCRAM-SHA-1

   SCRAM-SHA-1 is available as a SASL mechanism [RFC5802] as well as an
   HTTP mechanism [RFC7804] with identical data.  This means that a
   translation of the dedicated authentication mechanism onto a SASL
   backend of the HTTP server would be possible.  This helps to support
   the original HTTP mechanism even when only a SASL authentication
   backend is available.

   SCRAM mechanisms start off with data from the client, so c2s is
   already set in the Initial Request.  To demonstrate an existing
   example [Section 5 of [RFC5802]], we can set user name user with
   password pencil,

   Authorize: SASL mech="SCRAM-SHA-1",realm="example.com",c2c=data1,
              c2s="n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL"




Van Rein                Expires February 15, 2018              [Page 12]

Internet-Draft                  HTTP SASL                    August 2017


   or alternatively, using base-64 encoding for the c2s field,

   Authorize: SASL mech="SCRAM-SHA-1",realm="example.com",c2c=data1,
              c2s=biwsbj11c2VyLHI9ZnlrbytkMmxiYkZnT05Sdjlxa3hkYXdM

   to which the server would send Intermediate Response

   WWW-Authenticate: SASL mech="SCRAM-SHA-1",c2c=data1,s2s=data2,
                     c2s="n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL",
                     s2c="r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
                          s=QSXCR+Q6sek8bf92,i=4096",
                     text="Password for user"

   which causes the client to use the password for the Intermediate
   Request

   Authorize: SASL mech="SCRAM-SHA-1",c2c=data3,s2s=data2,
              s2c="r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
                   s=QSXCR+Q6sek8bf92,i=4096"
              c2s="c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
                   p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts="

   to which the server responds with a Final 200 Response and an
   informative header

   Authentication-Info: mech="SCRAM-SHA-1",c2c=data3,
                        s2c="v=rmF9pqV8S7suAoZWja4dJRkFsKQ=",
                        name="user@example.com",realm="example.com"

   and in addition, the server will have performed the requested work.

   As with the SASL EXTERNAL mechanism, it is arguably more secure when
   the password is entered into a browser popup then in a dynamically
   composed application that may not be under full control of the end
   user.

A.5.  GS2 Kerberos5 with TLS Channel Binding

   When a client decides to perform Kerberos5 [RFC4120] authentication,
   it should procure a service ticket for HTTP/
   www.example.com@EXAMPLE.COM when www.example.com is the web server
   host name and EXAMPLE.COM is its realm.  Clients usually derive the
   host name from a URI, but then need to find the realm; Kerberos5
   implementations and standards offer a few methods for that; clients
   MUST NOT use insecure mechanisms to derive the realm from the host
   name; clients MUST NOT accept realms from HTTP or even TLS for use
   with Kerberos5.




Van Rein                Expires February 15, 2018              [Page 13]

Internet-Draft                  HTTP SASL                    August 2017


   The client now provides an Initial Request to the www.example.com
   with the GS2 token in the c2s field, possibly with base-64 encoding

   Authorize: SASL mech="GS2-KRB5-PLUS",realm="example.com",
              c2c=data0,c2s=base64blob

   where the SASL mechanism name indicates Kerberos5 over the GS2 bridge
   [RFC5801], with channel binding [RFC5056] [RFC5554] [RFC5929],
   presumably to a TLS wrapper.  This usually suffices for the server to
   produce a Final Response.

Appendix B.  Acknowledgements

Author's Address

   Rick van Rein
   ARPA2.net
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl





























Van Rein                Expires February 15, 2018              [Page 14]