Subject: Internet Draft: HTTP += SASL

From: Rick van Rein <[email-masked]>
Date: Tue, 21 Jan 2020 09:23:11 +0100

Hello,

The following I-D is a specification that adds SASL authentication to
HTTP.  It allows sharing security mechanisms with other protocols such
as for email, and resolve security matters in transport-level software
rather than in applications.  I believe this offers dramatic benefits.

An informal example run is presented on
http://internetwide.org/blog/2018/11/15/somethings-cooking-4.html

We are looking forward to hearing your opinions to this proposal.

Thanks,

Rick van Rein
InternetWide.org

-----

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.

The IETF Secretariat

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 21 Jan 2020 09:53:39 +0100 (CET)

> http://internetwide.org/blog/2018/11/15/somethings-cooking-4.html

...

> https://www.ietf.org/internet-drafts/draft-vanrein-httpauth-sasl-03.txt

Hi!

Let me offer some quick initial comments after my first read:

1. RFC2616 is dead, refer to RFC 723X specs instead

2. I would really like to see protocol examples in the spec that better 
explains the flows. I couldn't understand it without reading the blog post -
that features such examples.

3. The mandatory 403 when not authenticated seems unorthodox. Regular HTTP 
auth returns 401 (or 407 for proxy) when not authenticated.

4. Section 3 wrongly states that Basic and Digest auth uses usernames in URIs. 
They didn't and don't. They speak of user names but they don't (have to) come 
from the URI.

-- 

  / daniel.haxx.se

---

From: Rick van Rein <[email-masked]>
Date: Tue, 21 Jan 2020 11:15:21 +0100

Hello Daniel,

Thanks for reading/commenting.

> 1. RFC2616 is dead, refer to RFC 723X specs instead

*Oops* -- will fix that.

> 2. I would really like to see protocol examples in the spec that
> better explains the flows. I couldn't understand it without reading
> the blog post -

Fair enough, will do that.

> 3. The mandatory 403 when not authenticated seems unorthodox. Regular
> HTTP auth returns 401 (or 407 for proxy) when not authenticated.

Indeed.  I was confused by the required inclusion of a challenge, but
didn't know the client recognised a repeat.  Will fix.

> 4. Section 3 wrongly states that Basic and Digest auth uses usernames
> in URIs. They didn't and don't. They speak of user names but they
> don't (have to) come from the URI.

Agreed, what I said is indeed browser behaviour.

Good criticism, thanks!  I will fix this in the next one up.

-Rick

---

From: Ken Murchison <[email-masked]>
Date: Tue, 21 Jan 2020 12:31:12 -0500

FYI.  Are you aware of the previous effort in this area 
https://tools.ietf.org/html/draft-nystrom-http-sasl-12

And did it inform your draft in any way?  I don't know why this draft 
went stagnant.  Perhaps someone else on the list has the history behind it.

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

---

From: Rick van Rein <[email-masked]>
Date: Thu, 23 Jan 2020 10:42:36 +0100

Hello Ken,

> https://tools.ietf.org/html/draft-nystrom-http-sasl-12

I was not aware of this work, no.  Thanks for pointing it out.

> went stagnant.  Perhaps someone else on the list has the history behind it.

Would be most interesting to learn.

Thanks,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Thu, 23 Jan 2020 12:18:50 +0100

Hallo Ken,

>From the document history in the datatracker, as well as the last draft,
there was interest in improving on the last draft, but it never seems to
have concluded.

AFAIK our new proposal improves on the raised points,

Scalability:

 - stateless server side (server state passes via the client)
 - distribution of a sequence of connections is no problem

Security:

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

Cheers,
 -Rick