Subject: [saag] Fwd: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 May 2012 09:52:12 +1000

FYI; see in particular #2.

Begin forwarded message:

> Resent-From: [email-masked]
> From: Mark Nottingham <[email-masked]>
> Subject: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication
> Date: 27 April 2012 3:28:06 PM AEST
> To: HTTP Working Group <[email-masked]>
> Archived-At: <http://www.w3.org/mid/[email-masked]>
> 
> Just a reminder that we're still accepting proposals for:
> 
> 1. HTTP/2.0
> 2. New HTTP authentication schemes
> 
> As per our charter <http://datatracker.ietf.org/wg/httpbis/charter/>.
> 
> So far, we've received the following proposals applicable to HTTP/2.0:
>  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals>
> 
> But none yet for authentication schemes:
>  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals>
> 
> As communicated in Paris, the deadline for proposals is 15 June, 2012. It's fine if your proposal isn't complete, but we do need to have a  good sense of it by then, for discussion.
> 
> Regards,
> 

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 May 2012 08:40:32 -0700

Given the number of HTTP authentication proposals we have seen in the past 10 years, it's weird that *no one* has sent any of them to the HTTPbis WG. This is an opportunity to get the improvements we have wanted.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 10:54:49 -0500

> Given the number of HTTP authentication proposals we have seen in the past 10 years, it's weird that *no one* has sent any of them to the HTTPbis WG. This is an opportunity to get the improvements…

I'm working on an I-D that's not so much a proposal as a set of
classification / analysis criteria and a list of imagined proposals.
I've made a proposal in the past (REST-GSS) which I'll also update.  I
may be a little late with the actual proposal.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 May 2012 09:16:16 -0700

> may be a little late with the actual proposal.

I'm pretty sure that a pointer to draft-williams-rest-gss-00 (or any other expired draft in this area) is all the httpbis WG needs; they don't need an up-to-date draft.

Having said that, I bet that they would very much like to see a classification / analysis document to help them!

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 11:33:06 -0500

> I'm pretty sure that a pointer to draft-williams-rest-gss-00 (or any other expired draft in this area) is all the httpbis WG needs; they don't need an up-to-date draft.

Good point.  But working on the classification document is making me
think of possible enhancements to my proposal anyways :)

> Having said that, I bet that they would very much like to see a classification / analysis document to help them!

Right.  Assuming they get lots of proposals it will be necessary to
figure out how to analyze them.  Even if they get no proposals it'd be
useful to have such a document to guide any design team.

Personally I continue to believe that there will not be a single
authentication mechanism that satisfies all users' needs, so I will
continue to argue for pluggable frameworks.  However, I'm less
interested in this than I am in the analysis at this point.

As for the dearth of proposals...  I suspect part of it is not knowing
what HTTP 2.0 will look like, and part of it is weariness: web auth
has been a resisting solutions for many years now.  Perhaps no one
really expects HTTPbis WG to be able to crack that nut?

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 May 2012 09:41:29 -0700

> useful to have such a document to guide any design team.

At this point they have zero proposals, but I'm hoping to change that by nudging here (not by writing a proposal myself).

> interested in this than I am in the analysis at this point.

We already have a pluggable framework; if it needs changes, letting the httpbis WG know that early would be important.

> really expects HTTPbis WG to be able to crack that nut?

The IESG expects them to not only crack the nut, but to show that the inside is edible. This was made very clear in the rechartering discussion (well, without the food analogy).

--Paul Hoffman

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 May 2012 17:45:54 +0100

> Given the number of HTTP authentication proposals we have seen in the past 10 years, it's weird that *no one* has sent any of them to the HTTPbis WG. This is an opportunity to get the improvements…
I think Simon Josefsson and I will write a proposal based on SCRAM (RFC 
5802).

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 May 2012 13:06:56 -0400

On Tue, 2012-05-15 at 09:41 -0700, Paul Hoffman wrote:
> We already have a pluggable framework; if it needs changes, letting the
>  httpbis WG know that early would be important.

Yeah; this is kind of poor.  Instead of inventing a new framework, why
not reuse an existing one?  The whole point of frameworks like SASL is
to _avoid_ having every application protocol have its own framework and
its own set of mechanisms.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 May 2012 20:25:22 +0200

> its own set of mechanisms.

I think Paul meant the HTTP authentication framework (401), whereas you
and Nico seems to think of SASL and GSS-API.

Indeed, if there is something in core HTTP that doesn't lend itself to
adding a generic SASL or GSS-API negotiation on top of it, that is
something that could be worked on.  However, such an HTTP update could
be done independently of a simple replacement for Basic/Digest like
SCRAM.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 May 2012 15:15:51 -0400

>be done independently of a simple replacement for Basic/Digest like

Yes.  HTTP tends to deal fairly poorly with multi-round-trip
authentication exchanges.  It tends to deal poorly with authentication
prior to disclosing the URI you want to access.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 May 2012 15:21:49 -0400

> and Nico seems to think of SASL and GSS-API.

No; I think all three of us are talking about what HTTP/2.0 should look
like, since that's the topic of this thread.

-- Jeff

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 May 2012 12:35:27 -0700

> like, since that's the topic of this thread.

Simon is correct. There is already a pluggable HTTP authentication framework in HTTP 1.1. Is there any need to update that framework for the kinds of things that we would want to plug into HTTP 2.0?

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 14:37:46 -0500

> Simon is correct. There is already a pluggable HTTP authentication framework in HTTP 1.1. Is there any need to update that framework for the kinds of things that we would want to plug into HTTP 2.0?

See Sam's response.  I'll go further and argue that HTTP is the wrong
layer for user authentication.  I'm not prepared to argue that today,
but I will in my submissions (I do, too, in REST-GSS, though I need to
strengthen the arguments presented there).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 May 2012 21:52:29 +0200

Nico Williams <[email-masked]> writes:

>> Simon is correct. There is already a pluggable HTTP authentication
>> framework in HTTP 1.1. Is there any need to update that framework
>> for the kinds of things that we would want to plug into HTTP 2.0?
>

I agree that HTTP is the wrong layer for user authentication in most
common use cases -- I have seen people from different backgrounds come
to that conclusion after trying to get it to work and eventually
failing, sometimes a couple of times.  It would be useful to have a good
writeup to point at to explain the issue.  For that matter,
authentication via TLS (i.e., HTTPS) is also often the wrong layer for
user authentication.

However, and this is important, the HTTP authentication framework is
still useful for some use-cases (e.g., device authentication, non-web
protocols layered on top off HTTP, simple websites), and further, it is
so widely used, that I believe a simple drop-in update for HTTP-Digest
is warranted and will be useful during a transition to something better.

/Simon

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 14:59:10 -0500

> authentication via TLS (i.e., HTTPS) is also often the wrong layer for

Yes, TLS is also the wrong layer.  I think the truth is that the
transport layer (TLS or HTTP in this case) is always the best layer
for cryptographic session protection (and since TLS does this well
enough, TLS is it), but the application layer is almost always the
best layer for user authentication.  This is not safe to do without
either a) strong enough server authentication in the transport (TLS)
or b) channel binding (with mutual authentication at the app layer).

> is warranted and will be useful during a transition to something better.

I don't agree.  I believe that a standard pattern of application-layer
authentication can address all those use cases too.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 May 2012 16:02:47 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    >> However, and this is important, the HTTP authentication framework
    >> is still useful for some use-cases (e.g., device authentication,
    >> non-web protocols layered on top off HTTP, simple websites), and
    >> further, it is so widely used, that I believe a simple drop-in
    >> update for HTTP-Digest is warranted and will be useful during a
    >> transition to something better.

    Nico> I don't agree.  I believe that a standard pattern of
    Nico> application-layer authentication can address all those use
    Nico> cases too.

Nico and I disagree here.
I think that http authentication is more or less the right layer for
webdav, atompub, and some HTTP-based RPC layer authentications.
I don't care about digest, but I do care about getting the HTTP
framework right for these use cases.

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 15:04:20 -0500

> authentication can address all those use cases too.

I should add that if that's true (that we can have a standard
app-layer pattern) then it's a useful simplification to just not have
any user authentication in HTTP/2.0.  Simple is usually better.

---

From: Steven Bellovin <[email-masked]>
Date: Tue, 15 May 2012 16:04:26 -0400

On May 15, 2012, at 3:37 46PM, Nico Williams wrote:

> layer for user authentication. 

Yup.  *No* major site uses it; everyone some roll-your-own scheme
that provides for (a) passwords; (b) password recovery/reset, and
(c) a *pretty* login screen.  This last is probably the most important
issue.  Any schemes that do not satisfy all three needs will fail
in the marketplace.  I conclude from this that the correct solution
probably involves some interaction between HTML and HTTP, with the
security area goo hidden underneath a very large rock that very
few sites will bother to lift -- they're more or less happy with
passwords...

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 15:05:44 -0500

> webdav, atompub, and some HTTP-based RPC layer authentications.

It's not that HTTP-layer user authentication is not appropriate.
Rather, app-layer user authentication would work just as well for
these apps.  Given that I'd rather not have to design and implement
user authentication at two layers.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 May 2012 16:08:25 -0400

Nico> On Tue, May 15, 2012 at 3:02 PM, Sam Hartman <[email-masked]> wrote:
    >>    Nico> I don't agree.  I believe that a
    >> standard pattern of    Nico> application-layer
    >> authentication can address all those use    Nico>
    >> cases too.
    >> 
    >> Nico and I disagree here.  I think that http authentication is
    >> more or less the right layer for webdav, atompub, and some
    >> HTTP-based RPC layer authentications.

    Nico> It's not that HTTP-layer user authentication is not
    Nico> appropriate.  Rather, app-layer user authentication would work
    Nico> just as well for these apps.  Given that I'd rather not have
    Nico> to design and implement user authentication at two layers.

The problem is that these app protocols do not currently support
authentication.
Including authentication in an app-protocol well does take work.
And I believe that fixing the deficiencies in the HTTP framework is
easier than adding app layer authentication to all of these protocols.

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 15:11:30 -0500

> easier than adding app layer authentication to all of these protocols.

I grant this, but I think the solution is to implement a common HTTP
app-layer authentication facility as a library that all these apps can
easily implement.

Note that for most non-web HTTP apps there's really very little
difference between HTTP-layer and app-layer user authentication.  In
all cases developers will want the user authentication abstracted by a
nice API.

It's the web applications where the difference between the two layers
becomes stark.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 15:13:02 -0500

On Tue, May 15, 2012 at 3:04 PM, Steven Bellovin <[email-masked]> wrote:
> issue.  [...]

Note that this means that today apps already do app-layer user
authentication.  Given the complete disconnect between the transport
crypto layer (TLS) and what web apps can manage for app-layer
authentication the result is utterly dependent on the TLS server PKI
for security.  This is true whether the app uses forms with passwords
or OAuth, or SAML, or...

> [...]   Any schemes that do not satisfy all three needs will fail

I agree that HTML and/or ECMAScript, and through them the browser
user-agent, must play a role in web app-layer user authentication.
I'd rather HTTP have no role to play though, except as a transport.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 May 2012 22:14:22 +0200

> any user authentication in HTTP/2.0.  Simple is usually better.

I think that HTTP/2.0 without user authentication makes sense too,
although I'm willing to be surprised.  The work that I perceive is
useful right now would include:

  a) improvements to HTTP/1.1 authentication framework for the many
     protocols and applications out there that uses HTTP/1.1 already.
     (e.g., replace HTTP-Digest with something stronger, either SCRAM
     natively in HTTP, or SCRAM indirectly via HTTP-GSS)

  b) recommendations/guidelines on how to do user authentication at the
     web application layer that enables stronger mechanisms than
     username/passwords.

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 May 2012 21:19:17 +0100

Just a small reminder of the subject line:-)

I'd really like to see some good proposals produced
rather than only discuss whether that's perfection
or not. (I might even make a proposal of my own if
only to flush out better ones:-)

If people have additional things they think are also
worthwhile, then they can propose those too, on this
list or as an I-D. Sean and I are very open to seeing
work happen on such things, but that's not the same
as the work the httpbis WG are doing now.

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 15:24:39 -0500

> Just a small reminder of the subject line:-)

So you're saying that we should change the subject line?  Surely
you're not complaining about the sudden interest where there had been
none in spite of begging for it!  ;)

But yes, I agree that it'd be nice to have some I-Ds to discuss.
Matters like which layer is best for user authentication don't really
have an impact on which authentication mechanisms can be used, so
specific proposals for, say, using ZKPPs or whatever, can be made and
debated regardless.  But the question of which layer to do this in is
actually fascinating, critical even.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 May 2012 21:26:32 +0100

> none in spite of begging for it!  ;)

:-)

> actually fascinating, critical even.

I agree, but am just concerned lest we spend too much effort
on that and miss what is a relatively short window during
which its likely we might be able to improve HTTP security.

S.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 May 2012 16:27:54 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> I grant this, but I think the solution is to implement a
    Nico> common HTTP app-layer authentication facility as a library
    Nico> that all these apps can easily implement.

    Nico> Note that for most non-web HTTP apps there's really very
    Nico> little difference between HTTP-layer and app-layer user
    Nico> authentication.  In all cases developers will want the user
    Nico> authentication abstracted by a nice API.

It's not obvious to me at all why this is true. To me, a webdav
app-layer authentication would look different than a atompub app-layer
authentication.
And both of those seem like they would involve more damage to the app's
state machine than  http-layer.

I'd expect the webdav layer to probably use http headers for a lot of
the work.  I'd expect the atompub layer to want to put everything into
the xml document.  I'd expect the atompub layer to get really unhappy at
the idea of adding challeng/response into the state machine of the app
layer but to be fine with this in the http layer.

---

From: Mouse <[email-masked]>
Date: Tue, 15 May 2012 16:29:03 -0400 (EDT)

> [E]veryone some roll-your-own scheme that provides for (a) passwords;
> (b) password recovery/reset, and (c) a *pretty* login screen.  This
> last is probably the most important issue.

Actually, I think it's not.  What I suspect most of those content
providers care about more is a *branded* login screen.  Indeed, many of
them are pretty hideous - though of course that's a judgement call on
which reasonable people will disagree.

Of course, this brings us right back to the tension between the desires
of the content provider and presentation imposer and the desires of the
content consumer.  (Personally I'd prefer to see peer-to-peer, but
there's less and less of that left these days.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Steven Bellovin <[email-masked]>
Date: Tue, 15 May 2012 16:33:44 -0400

> as the work the httpbis WG are doing now.
I'm saying something slightly different: I'm saying that effort
spent on http security is probably wasted unless there's a
plausible way to link it to my other points.  We can't bolt
on authentication here; the market isn't interested.  We
need an integrated design, even if that means talking to
other standards bodies and (shudder) web site designers.

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 May 2012 15:48:02 -0500

> other standards bodies and (shudder) web site designers.

I'm assuming that the WG will entertain your arguments (and mine) and
that the scope is not strictly HTTP authentication.  The WG charter
says this:

  With regard to security requirements, in the initial phase of work on
  HTTP/2.0, new proposals for authentication schemes can be made.  The WG
  will have a a goal of choosing at least one scheme that is better than
  those available for HTTP/1.x.  However, the WG might select zero schemes.
  In addition, non-selected schemes might be discussed with the IETF
  Security Area for further work there.

To me this says that our arguments are in scope and that it's possible
that the WG will decide to not pursue HTTP-layer solutions.  I'd also
argue that the charter does not rule out app-layer authentication
systems specifically intended for running over HTTP -- the charter's
language is not sufficiently specific as to layering.  Lastly, if the
charter text were to presecriptive we could argue to re-charter (I
would).

Nico
--