Re: [dispatch] SASL Authentication for HTTP

Hi Ben,

I think it belongs in HTTPbis, given that it's a HTTP extension - unless someone is arguing that it deserves a separate WG. Given the potential pitfalls in terms of integration (especially if things are stateful), we need careful review by HTTP folks to make sure it doesn't break anything.

However, we generally only adopt things when we have signs of interest from implementers; so far we haven't seen that.  So it'd be good to see some more on-list discussion - in particular, it'd also be good to understand what adding SASL to the mix of already existent HTTP authentication mechanisms brings.

A short presentation or discussion at IETF107 might also help; I'm a little wary of giving a time slot to a presentation with so little on-list discussion, but if that makes things easier for DISPATCH, we can manage that (provided IETF107 happens, of course).

Cheers,

> On 4 Mar 2020, at 7:03 am, Ben Campbell <ben@nostrum.com> wrote:
> 
> Hi,
> 
> Does anyone in DISPATCH (esp. our HTTP experts) have thoughts on Rick’s draft?
> 
> I see that it had a small amount of discussion in HTTPBIS back in January. Is this something that should be discussed in DISPATCH or does it clearly belong to HTTPBIS? (I’ve copied the HTTPBIS chairs)
> 
> Thanks!
> 
> Ben.
> 
>> On Feb 25, 2020, at 2:10 AM, Rick van Rein <rick@openfortress.nl> wrote:
>> 
>> 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 has now been proposed to go through DISPATCH, as this
>> is more related to the binding with protocol headers than to SASL, which
>> itself is quite clear on requirements to its carrier.
>> 
>> 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
>> 
>> 
>> ---------
>> 
>> 
>> A new version of I-D, draft-vanrein-httpauth-sasl-03.txt
>> has been successfully submitted by Rick van Rein and posted to the
>> IETF repository.
>> 
>> Name:		draft-vanrein-httpauth-sasl
>> Revision:	03
>> Title:		HTTP Authentication with SASL
>> Document date:	2020-01-20
>> Group:		Individual Submission
>> Pages:		12
>> URL:
>> https://www.ietf.org/internet-drafts/draft-vanrein-httpauth-sasl-03.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/
>> Htmlized:       https://tools.ietf.org/html/draft-vanrein-httpauth-sasl-03
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-vanrein-httpauth-sasl-03
>> 
>> 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.
>> 
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
> 

--
Mark Nottingham   https://www.mnot.net/