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

From: Rick van Rein <[email-masked]>
Date: Mon, 02 Jan 2017 12:42:12 +0100

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 3 Jan 2017 17:30:25 -0500

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:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 3 Jan 2017 23:05:02 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Rick van Rein <[email-masked]>
Date: Thu, 05 Jan 2017 10:16:37 +0100

Hi Tony,

Thanks a lot!

> #1 could be solved in a straightforward fashion. But I don’t think there’s enough interest currently for #2.

I have a very concrete place where I want it, and it doesn't have the
usual chicken / egg problem:

The Nginx proxy has a "Auth Request" mechanism where authn / authz can
be performed via a HTTP call to a backend; status codes 401, 403 or 2xx
are interpreted and output header values may be harvested.  A similar
mechanism could be used for a SASL backend.

This could directly integrate with its backends for POP3, IMAP, SMTP and
(3rd party) XMPP.  Although there's no direct need to standardise it for
this internal purpose, it may be the best way to go.

That may turn out to be a useful bootstrapping path, making it flow into
closed systems and gradually spreading out.  Wishful thinking?  There's
no way to know but to try...

What you are stating is mostly pragmatic, and the need to build up
enthousiasm for writing it down.  I think HTTP SASL is well worth the
effort, and at least allow HTTP programmers to get away from the in-site
coding of password logic, and adopt more mechanisms.  So I now feel
encouraged to write it down.

Thanks!
 -Rick