Subject: Re: [dispatch] SASL Authentication for HTTP

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Mar 2020 14:03:38 -0600

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Mar 2020 12:24:56 +1100

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 <[email-masked]> wrote:
> 
> Hi,
> 

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Mar 2020 20:49:28 -0600

Thanks Mark! By “short presentation”, were you thinking in terms of doing so in HTTPBIS or DISPATCH?

Everyone: If you find this interesting, please comment soon. We will be figuring out agendas really soon now, and Mark is correct that we need to prioritize meeting time for things that have had list discussion.

Thanks!

Ben.

> On Mar 3, 2020, at 7:24 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Ben,
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Mar 2020 15:35:48 +1100

In HTTPbis - I believe we can give it ~10 minutes.

> On 4 Mar 2020, at 1:49 pm, Ben Campbell <[email-masked]> wrote:
>

---

From: Rick van Rein <[email-masked]>
Date: Wed, 04 Mar 2020 08:47:22 +0100

Hello Mark/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 thing…

That is indeed why I was suggested to turn to DISPATCH and not
SECDISPATCH -- correct integration with the carrier HTTP is a bigger
concern than the integration of carried SASL.  At the very least,
HTTPbis should not object to the specification.

There was very little response when I proposed this in HTTPbis, though
Daniel was quite interested.  I am a little concerned that the low
response could be because it reaches more into the future than the group
is focussing on; and the same for the spec's motivation to have
consistency across protocols and move towards integrated identity and
realm crossover mechanismes.  Those might be grounds to develop this
elsewhere.

A talk may help to tease this out; I will not be in Vancouver but intend
to visit Madrid in July.

> 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 als…

There has been a strong past interest in this, as I understand it, but
it ran into technical difficulties such as server state that I solved
and that are in fact now prohibited.

I have long been unsure what to do with this spec, but a few years back
I discussed the idea with Nginx' security lead who was interested.  But
mostly, I am writing this from the background of the project that I am
chairing, and which needs this rather desparately.  I'm scratching a
personal itch :)

The architecture we're working on is a new protocol stack for hosting
providers, not the kind of people you will find here but they will be
able to use this well; the core of the stack is an identity model with
authentication and authorisation that spans between domains, using a few
mechanisms of realm crossover.  To make that happen, there is a need for
some consistency across the board in protocols.  The corner of Kerberos,
GSS-API, SASL can fill this requirement, but HTTP is not so
well-integrated with this authentiction technology (and its choice
mechanisms) as other protocols are.

We are actively building this into our software, and relying on the
value it adds; we would like to make this official and generally usable.

> 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 DISPA…

I will not be on 107, but plan to be at Madrid in July.

FYI, there will be an update to this document, probably today, based on
the feedback received in HTTPbis and a few other places.

-Rick

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 04 Mar 2020 14:25:15 +0000

On Wed, Mar 4, 2020, at 1:24 AM, Mark Nottingham wrote:
> 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.

The advantage of SASL framework is that once a new SASL authentication mechanism is added, it is immediately available in IMAP, SMTP, XMPP, LDAP, POP3 and several other protocols. HTTP always has to be "special", because it doesn't have SASL support.

You can see list of currently registered mechanism on IANA's website: <https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml>

> 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,
> 
>

---

From: Rick van Rein <[email-masked]>
Date: Wed, 04 Mar 2020 16:55:02 +0100

Hello DISPATCH,

I uploaded a new version of the draft, taking on board feedback from the
HTTPbis group (thanks, Daniel!).  It now features an example run.

-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:

CHANGELOG:

CHANGES FROM 03 TO 04:
 * Made the "realm" field optional; that is what RFC 7235 seems to suggest
 * Removed the "text" field; it is not SASL-specific; could be a
security risk
 * Fields c2s and s2c are base64-encoded and are absent in lieu of a
SASL token
 * Dropped userview= to make it an orthogonal HTTP User: header
 * Added an example run (that was a very useful suggestion!)
 * Confirmed the Authentication-Info header in the Final 200 Response
 * Changed envvar SASL_CLIENTID to the customary name REMOTE_USER
 * Replaced 403 Forbidden with a repeated response asking for authentication
 * Renamed Final 200 to Positive Response, Final 403 to Negative Response