Subject: [Secdispatch] Draft: Adding SASL to HTTP

From: Rick van Rein <[email-masked]>
Date: Fri, 06 Mar 2020 08:24:20 +0100

Hello,

This draft proposes to introduce SASL as an authentication mechanism
into HTTP.  Adding such mechanisms requires IETF Review according to RFC
7235.

I don't know where to turn, and this has long stopped this proposal from
progressing.  It currently hangs somewhere between DISPATCH And
SECDISPATCH, so it would be useful to hear thoughts about this proposal.

I have been made aware that SASL in HTTP has been tried before; the
reasons why that didn't finish 15 years ago are resolved in this draft:

Scalability:

 - stateless server side (server state relays through the client)
 - sequential messages distributed over connections is no problem

Security:

 - no fixation on DIGEST-MD5 (compatibility pulls down security)
 - support for channel binding without fixating protocol layering

Benjamin Kaduk noted my search for IETF mechanisms and responded with:

> That said, I'm happy to see work in this space and would be willing to
> AD-sponsor it upon a recommendation of either DISPATCH group, if that is
> the recommendation.

The authors of the prior HTTP SASL proposal also welcome this work being
done.

What are your recommendations towards this work?

Thanks,
 -Rick

Name:		draft-vanrein-httpauth-sasl
Revision:	04
Title:		HTTP Authentication with SASL
Document date:	2020-03-04
Group:		Individual Submission
Pages:		14
URL:
https://www.ietf.org/internet-drafts/draft-vanrein-httpauth-sasl-04.txt
Status:
https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/
Htmlized:       https://tools.ietf.org/html/draft-vanrein-httpauth-sasl-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl
Diff:
https://www.ietf.org/rfcdiff?url2=draft-vanrein-httpauth-sasl-04

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 27 Mar 2020 12:16:31 -0700

Hi Rick,

Thanks for bringing this to SECDISPATCH.

Doing a quick read of the draft before the session, the prospect of caching
authentication results via a "s2s" field in a Positive Response stuck out
at me -- is this effectively a bearer token or is there a way envisioned to
bind such cached data to some cryptographic keying material?

Thanks,

Ben

On Fri, Mar 06, 2020 at 08:24:20AM +0100, Rick van Rein wrote:
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch