Re: [http-auth] Why is there no SASL support in HTTP?

When Alexey and I were working on the SCRAM SHA-256 SASL mechanism and using that for HTTP SCRAM authentication, it was purposely done in a way that followed standard SASL practices and that would allow a stock SASL SCRAM library to be used. Please review RFC 7804 and the use of sid= and data= within the WWW-Authenticate response from the header and subsequent Authorization response from the client. The sid= “session identifier” is the binding mechanism that preserves the state between the server and client, and data= holds the SASL payload. This could easily generalize to other SASL mechanisms, so <that> portion of the problem can be considered resolved. 

The missing links are:

1) a mechanism for SASL mechanism discovery.
2) the willingness by client and server implementers to extend this into other SASL mechanisms.

#1 could be solved in a straightforward fashion. But I don’t think there’s enough interest currently for #2. I considered writing a follow-up to RFC 7804 to generalize the mechanism for SASL in general, but felt a lack of enthusiasm at that time for any additional authentication mechanisms.

	Tony Hansen

On 1/3/17, 5:30 PM, "http-auth on behalf of Ken Murchison" <http-auth-bounces@ietf.org on behalf of murch@andrew.cmu.edu> wrote:

    Already tried once: https://tools.ietf.org/html/draft-nystrom-http-sasl-12

    This effort was before my interest in HTTP so I don't know why it died.

    On 01/02/2017 06:42 AM, Rick van Rein wrote:
    > Hello,
    >
    > I've been wondering why HTTP Authentication does not support SASL, but
    > instead chooses independent mechanisms from SASL?
    >
    > Having a pluggable framework that is updated independently from HTTP
    > appears beneficial to me.  Also, integration with other systems that do
    > use SASL would be greatly improved.  With support for SASL is so many
    > mail clients already, its introduction to HTTP clients may be relatively
    > smooth.
    >
    > I am aware that mechanisms need to store state on the validating side,
    > so the server, which contradicts HTTP design.  That may be easily
    > resolved by passing some state back to the client, and making it supply
    > when it continues.  For example, digest-based authentication might send
    > back random bytes as state, and hash it with an internal key to form a
    > challenge.  When presented with the state and response, the computation
    > can be validated without a need for state on the server.
    >
    > Alternatives to state on the server may also exist -- for instance, a
    > TLS wrapper may provide consistent entropy using RFC 5705.
    >
    >
    > One thing I've been thinking is that SASL EXTERNAL may be a useful
    > addition.  Not to actually authenticate, but it could trigger
    > authorisation processes, possibly using another identity and/or
    > triggering the generation of Authorization-Info headers that might relay
    > information (such as identity) to the client at the HTTP layer.
    >
    >
    > If so desired, I am willing to write an I-D for this.
    >
    >
    > Thanks,
    >
    > Rick van Rein
    > (wishing all a properly secured 2017)
    > http://internetwide.org
    >
    > _______________________________________________
    > http-auth mailing list
    > http-auth@ietf.org
    > https://www.ietf.org/mailman/listinfo/http-auth

    -- 
    Kenneth Murchison
    Principal Systems Software Engineer
    Carnegie Mellon University

    _______________________________________________
    http-auth mailing list
    http-auth@ietf.org
    https://www.ietf.org/mailman/listinfo/http-auth