Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Feb 2012 09:31:50 -0800

The earnest calls for better authentication on this thread appear to ignore the fact that the very things that are being requested were put out of scope for the websec WG in their charter. I hope that no one things that a WG in the Applications Area will be better equipped to come up with a better authentication mechanism than one in the Security Area.

Asking the HTTPheads to guess what the securityheads might want is not a good way to design HTTP 2.0.

Proposal: leave the httpbis WG charter as-is and re-charter the websec WG to consider what is needed in the HTTP authentication model. Later, recharter the websec WG to, you know, actually do the security work for authentication.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Feb 2012 10:39:14 -0700

On 2/22/12 10:31 AM, Paul Hoffman wrote:
> The earnest calls for better authentication on this thread appear to
> ignore the fact that the very things that are being requested were
> put out of scope for the websec WG in their charter. I hope that no
> one things that a WG in the Applications Area will be better equipped
> to come up with a better authentication mechanism than one in the
> Security Area.

The WebSec WG is in the Applications Area.

> not a good way to design HTTP 2.0.

Probably not.

> Proposal: leave the httpbis WG charter as-is and re-charter the
> websec WG to consider what is needed in the HTTP authentication
> model. Later, recharter the websec WG to, you know, actually do the
> security work for authentication.

Or charter a separate WG to focus on HTTP authentication. (You might
recall that the BoF leading to formation of the WebSec WG was entitled
HASMAT = "HTTP Application Security Minus Authentication and Transport"
or somesuch.)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Feb 2012 09:52:37 -0800

> The WebSec WG is in the Applications Area.

Yeeps! My apologies. I guess seeing a room full of security regulars made me forget.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Feb 2012 18:35:17 +0000

> Yeeps! My apologies. I guess seeing a room full of security regulars made me forget.

Regardless of that you do have a fair point that asking
apps folks to do stuff that'll please security folks might
be asking for trouble:-)

However, the counter to that is that security folks doing
stuff without enough apps input might produce something that
won't get adopted which also doesn't produce the right end
result.

Anyway, I think this topic, if tackled, won't lack
interested participants and will get plenty of security
and apps input no matter how we organise it.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Feb 2012 10:39:49 -0800

> and apps input no matter how we organise it.

Peter St.Andre's suggestion of a separate WG to deal specifically with HTTP authentication seems like the best way to be sure both sets of parties are fully involved. If the IESG charters it within the next few months, the HTTP 2.0 work can be informed by any changes (if any) that are needed.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Feb 2012 14:18:46 -0700

On 2/22/12 11:39 AM, Paul Hoffman wrote:
>> Regardless of that you do have a fair point that asking apps folks
>> to do stuff that'll please security folks might be asking for
>> trouble:-)
>> 
>> However, the counter to that is that security folks doing stuff
>> without enough apps input might produce something that won't get
>> adopted which also doesn't produce the right end result.
>> 
>> Anyway, I think this topic, if tackled, won't lack interested
>> participants and will get plenty of security and apps input no
>> matter how we organise it.
> 
> 
> Peter St.Andre's suggestion of a separate WG to deal specifically
> with HTTP authentication seems like the best way to be sure both sets
> of parties are fully involved. If the IESG charters it within the
> next few months, the HTTP 2.0 work can be informed by any changes (if
> any) that are needed.

By the way, I forwarded this message to the [email-masked] list
(yes, we already have a discussion list for these topics). The small
sample of replies indicates that (1) folks would prefer to broaden the
topic to web authentication, not strictly HTTP authentication and (2)
not everyone who is interested in these topics subscribes to the more
general [email-masked] list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 23 Feb 2012 17:13:53 -0800

> HASMAT = "HTTP Application Security Minus Authentication and Transport"

Please understand that this exact same discussion was had in 1994 and
the IESG decided that the applications area couldn't possibly do this
work on their own, so they created a security area working group to
handle it.  That HTTP Security group, which was dominated by folks who
did not have any implementations of HTTP, decided to ignore the problem
for which they were chartered and instead invented SHTTP.

More importantly, the effect of that decision was that the people who
get work done at the IETF were prevented from improving HTTP's auth
mechanisms because it was out of scope, while the people who had it
in scope had no corresponding incentive to get it DONE.

Every time this topic comes up, people want to shove it off to some
other working group that is somehow going to magically get off its
collective ass and do real work.  Why?  It doesn't work.  It never
has worked.  We've gone through four iterations now of revising HTTP,
each one starting off with the same discussion, and each one concluding
that auth would be better owned by someone else.

There is nobody else.

How many times do we have to do this before we declare insanity?
I don't care how much risk it adds to the HTTP charter.  They are
all just meaningless deadlines anyway.  If we want HTTP to have
something other than Basic (1993) and Digest (1995) authentication,
then it had better be part of *this* charter so that the proposals
can address them.

....Roy

---

From: Tim Bray <[email-masked]>
Date: Thu, 23 Feb 2012 17:18:56 -0800

> then it had better be part of *this* charter so that the proposals

Well, Digest already isn't used by anyone :)

Seriously, someone needs to propose some charter language or this
discussion is a no-op.  -Tim

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Feb 2012 17:23:45 -0800

> then it had better be part of *this* charter so that the proposals

If only it were that simple. If the answer is "design an HTTP auth mechanism that is better than Digest", then this is a tractable goal. If it is "get IETF consensus on that auth mechanism", then it isn't. The latter has proven to be impossible because people say (possibly rightly) that web developers don't want auth mechanisms that use the browser chrome: they want auth in HTML, and anything that relies on the browser chrome is insufficient.

Notice how the topic changed from "HTTP" to "web" for the security discussion but not for the httpbis charter discussion? That topic-change has derailed the HTTP authentication discussions at recent (and not-so-recent) IETF meetings.

If the charter has "develop HTTP authentication mechanisms beyond Digest", that's great: we already have seen about five proposals in the past few years for those, some of them with security analyses. If the charter says "...and specify one that is mandatory to implement", that seems prone to consensus failure because of religion about zero-knowledge proofs versus operational simplicity, but I would be overjoyed to be wrong about that.

--Paul Hoffman

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 23 Feb 2012 17:24:07 -0800

> Well, Digest already isn't used by anyone :)

A popular misconception because it works unseen.  See tools.ietf.org

> discussion is a no-op.  -Tim

"Proposals for new HTTP authentication schemes are in scope."

....Roy

---

From: Tim Bray <[email-masked]>
Date: Thu, 23 Feb 2012 17:34:22 -0800

> "Proposals for new HTTP authentication schemes are in scope."

+1

I don’t think we’ll get one, but in the unlikely event someone can
build consensus for something, there’s no reason to brand it as
out-of-bounds.  -T

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 23 Feb 2012 18:21:14 -0800

> If only it were that simple. If the answer is "design an HTTP auth mechanism that is better than Digest", then this is a tractable goal. If it is "get IETF consensus on that auth mechanism", then i…

I don't need IETF consensus, just rough consensus and running code,
and I have no need to satisfy folks who think the Web is a browser.
The hard part is deploying anything that is incompatible with
already-deployed clients without letting them fall back to basic.

It is a trivial problem compared to choosing a new, non-MIME syntax.

What "web developers" want is based on what they can do today,
not what they can expect from an entirely new protocol.

> Notice how the topic changed from "HTTP" to "web" for the security discussion but not for the httpbis charter discussion? That topic-change has derailed the HTTP authentication discussions at recen…

It didn't derail them.  They were not on any rails to begin with.

The problem with defining security in a separate group without
shipping implementations is that there is no need to compromise,
no need to identify and resolve specific use cases, and no need
to do something better than nothing.

If we add a requirement to HTTP/2.0 that user authentication MUST
be accomplished via a mechanism not subject to UI spoofing,
then that's what people will implement (if they implement at all).
The protocol can give the server all the control it wants over the
display of a background or separate window explaining what to do
in that other mechanism-not-subject-to-spoofing.  Give people just
enough rope to solve that problem without hanging themselves, and
the rest of HTTP (non-browser clients) can implement right now.

> If the charter has "develop HTTP authentication mechanisms beyond Digest", that's great: we already have seen about five proposals in the past few years for those, some of them with security analys…

I'd be happy with several imperfect mechanisms with differing
trade-offs that can be implemented in parallel.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Feb 2012 13:47:18 +1100

> "Proposals for new HTTP authentication schemes are in scope."

No one has said they're out of scope; this discussion has been about whether -- at this point in time, before we have proposals -- we require the outcome to jump through some particular hoop regarding security. 

Cheers,

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

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Feb 2012 08:25:03 +0100

On Thu, Feb 23, 2012 at 05:23:45PM -0800, Paul Hoffman wrote:
> If only it were that simple. If the answer is "design an HTTP auth mechanism
> that is better than Digest", then this is a tractable goal. If it is "get
> IETF consensus on that auth mechanism", then it isn't. The latter has proven
> to be impossible because people say (possibly rightly) that web developers
> don't want auth mechanisms that use the browser chrome: they want auth in
> HTML, and anything that relies on the browser chrome is insufficient.

Maybe but you still need HTTP-based auth for proxies anyway. Also, I
partially disagree with your point, seeing the number of applications
in enterprise which rely on the hated NTLM auth which is also HTTP-based ;
they're using it because it's transparent to the user, and enterprise
customers do ask for such transparent auth schemes.

There would also be much less need for cookies if auth was carried by the
browser, and this would let the user log off. So I think there's a need
for this.

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 25 Feb 2012 00:42:19 +1300

> browser, and this would let the user log off. So I think there's a need

Keeping the focus for charter firmly on the transport area and away from 
the "web"/resource/content area allows us to split the two auth models 
HTTP currently supports (www-auth and proxy-auth) along those same lines.

www-auth is end-to-end and only in that single-hop scenario can it be 
considered close to a transport authentication. For all other hop counts 
it is an effective *message* authentication, with no bearing on the 
transport. The proxy-auth layer is the only one which remains strictly 
transport-related, since it explicitly stops and re-starts at every HTTP 
hop.

So IMHO, we can (indeed must) acknowledge that HTTP transport uses a 
relay hop model. Charter security as a per-hop thing in HTTP. Any 
proposals can define something to adapt/extend/replace/erase proxy-auth 
into a real transport-auth. Specific to the two communicating hops. With 
the same semantics and viability whether they be client-proxy or 
client-server hops.
  Bonus: per-hop allows us to ignore 2.0->1.x->2.0 compatibility. This 
auth requirement only applies on 2.0->2.0+ hops.

www-auth can be left as the message-oriented authentication it is today 
for the "web auth" stuff. Either pushed off to somebody else (again) or 
to ourselves some years in the future when messaging semantics are up 
for change.

Looking a little forward to potential proposals. We have TLS, Kerberos, 
PGP, maybe OAuth and others all available right now (meeting that "over 
current infrastructure" charter requirement) as schemes to define 
proposals around. Being a "new" transport-authentication mechanism all 
we have to do is ensure that implementation is reasonably easy and any 
management tools to generate tokens or whatever are readily/easily 
available to even clueless junior admin.

AYJ

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Feb 2012 12:54:10 +0000

On 02/24/2012 01:24 AM, Roy T. Fielding wrote:
>> On Thu, Feb 23, 2012 at 5:13 PM, Roy T. Fielding<[email-masked]>  wrote:
>>

How would a plan like the following look to folks:

- httpbis is chartered to include auth mechanism work as
   per the above (or whatever text goes into the charter)
- that'll generate a slew of proposals, some good, some
   bad, some better-than-current and some too complex
- plan is for httpbis to pick something (one or more if
   they want, but one better-than-current one is the goal)
- give all the above a short timeframe (this year, pick
   which to work on at the same time as re-chartering for
   the details of HTTP/2.0 maybe)
- httpbis pick what they want, (zero or more) and go
   do their stuff

- if there's still enough interest in some proposals
   that were not picked by httpbis we then try charter a sec
   area wg to develop experimental specs for those so
   they're off the critical path for httpbis (the rest die
   unloved;-)
- those experimental specs would be REQUIRED to work with
   http/1.1 and/or http/2.0 (as appropriate) with no change
   required to http; that'd be in the charter for that
   putative sec wg
- that sec wg charter might also say that the putative
   wg is not allowed to add new schemes until the
   originally chartered ones are completed (to avoid
   people turning up every week with their shiny new
   scheme)

Might that be a way forward that'll give enough folks
enough of what they want/need?

Cheers,
S.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Feb 2012 07:02:38 -0800

> enough of what they want/need?

It would, but I would like to give a counter-proposal that I think will use people's different talents better:

- new wg on developing http authentication mechanisms is chartered soon (BoF in Paris); call it the ham wg
- httpbis is chartered to follow the work of the ham wg and is required to make sure that the authentication framework in http 2.0 works for as many of the proposals from the ham wg as possible
- ham wg is responsible for most of what you list above
- http2.0 document says "the mandatory to implement auth mechanisms are named in that RFC over there", which comes from the ham wg

There will be overlap in wg membership, but not nearly as much as would be needed for your proposal.

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 25 Feb 2012 13:05:00 +1100

Hi Stephen,

> - httpbis pick what they want, (zero or more) and go

Is the goal for HTTPbis "one or more" or "zero or more"? I see both above.

Again - I'm absolutely fine with soliciting proposals, but requiring output is a different thing.

Thanks,

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Feb 2012 13:46:20 +0000

Hiya,

> Again - I'm absolutely fine with soliciting proposals, but requiring output is a different thing.

Yeah that's a tricky one. While one might like to
see "one or more" in both places that might not be
practical.

In the proposal above the goal is that httpbis pick one
or more but recognising the reality that we might not get
a new proposal that httpbis will accept and that folks
will really implement and deploy.

So:
    Goal = one or more
    Reluctant recognition of reality = zero or more

With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term is absolutely not intended to provide a way to
just punt on the question.

Such a failure at the point where httpbis was re-chartering
to work on a HTTP/2.0 selection with no better security than
we now have is probably better evaluated as a whole - I
guess the question for the IETF/IESG at that point would
be whether the Internet would be better with or without
such a beast, or better waiting a while until the security
thing did get fixed.

I can imagine an argument might ensue about that;-)

S

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Feb 2012 15:03:55 +0100

On 2012-02-25 14:46, Stephen Farrell wrote:
> ...
> ...

If we just need a new authentication scheme, nothing stops people from 
working on that right now. I don't see how that should affect HTTP/2.0.

If the "right" way to do security needs changes in the HTTP/1.1 
authentication framework, then we should fix/augment/tune HTTP/1.1. It's 
not going to go away anytime soon.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Feb 2012 14:13:27 +0000

On 02/25/2012 02:03 PM, Julian Reschke wrote:
> working on that right now.

I don't agree with you there - the perceived low probability that
something will be deployed is a real disincentive here. We have had
people wanting to do work on this and have been told there's no point
because it won't get adopted.

 > I don't see how that should affect HTTP/2.0.

Well, a number of people have noticed that current schemes
are getting long in the tooth and fixing stuff like that when
you do a major rev of a protocol is quite a reasonable thing
to do.

> not going to go away anytime soon.

Sure, I agree with that and think the plan above allows for it.

S

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Feb 2012 15:20:36 +0100

> because it won't get adopted.

Just checking: so you think what's needed is a normative requirement to 
implement the new scheme? Do you really believe that that's what holding 
up improvements in this area?

> you do a major rev of a protocol is quite a reasonable thing

If there's something from with the framework, let's fix the framework. 
That's already covered by the current charter, no?

> Sure, I agree with that and think the plan above allows for it.

My point being: this is something we already do in httpbis. What's 
missing is concrete bug reports.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Feb 2012 17:44:34 +0000

> up improvements in this area?

The first thing is not something I said and I don't know quite what
it means so its also not something I believe. I therefore also do not
believe the 2nd thing.

> That's already covered by the current charter, no?

I don't think fixing or changing the framework will give us better
auth schemes by itself. (Better auth schemes may or may not require
changes to the framework, I dunno.)

So I think you're raising a side issue here really.

S

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Feb 2012 19:23:24 +0100

> So I think you're raising a side issue here really.

Well, I'm one of the editors of the authentication framework spec, so if 
there's something wrong with it, I'd like to know.

So if we collectively think that the framework probably is ok, and that 
we *do* need a new authentication scheme, what's stopping us to start 
that activity *right now*?

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Feb 2012 18:29:10 +0000

> that activity *right now*?

I believe I answered just that question from you earlier today.
So you must be looking for someone else's answer I guess. Or
perhaps I'm confused.

S

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 26 Feb 2012 10:25:00 +1100

> because it won't get adopted.

Let's speak plainly here.

It's not hard for new things to be deployed -- there are lots of new things being deployed on the Web right now.

What IS hard is forcing browser vendors to deploy something that they don't think is going to work, or that they're not terribly interested in.

They are VERY VERY VERY interested in security, as are many other people in the broader community. If the IETF were to come up with a viable proposal that solves their problems, they would beat down this organisation's doors.

The IETF may have some smart people, and they may have ideas about Web security, but that doesn't necessarily make them into workable solutions for the various stakeholders. The discussion about Web security is much broader, involving not only the browser vendors, but also organisations like the W3C, IIW, etc.

Using HTTP/2.0 as a mechanism to shortcut all of this and force what people in the IETF think is a good solution down implementers' throats is going to lead to a very predictable and messy fail.

> just punt on the question.

This makes me very uncomfortable. How hard and long do we have to try before we convince you that we're not punting?

> such a beast, or better waiting a while until the security

If we "wait a while until the security thing [does] get fixed", I'll gladly bet any amount of money you care to name that SPDY will gain market traction so quickly as to make any HTTP/2.0 effort in IETF completely backwards-looking. Refer to the debacle with Cookies for one such example.

So, again, I'm fine with allowing new authentication schemes to be proposed, in the off chance that some genius will suddenly propose something that meets all of the myriad requirements (that still aren't well-defined) and gets consensus and buy-in from implementers. 

However, requiring us to output such a beast and gating HTTP/2.0 on it is effectively asking us to spin our wheels for n years. And the folks working on SPDY will - quite rightly - walk away and do their work somewhere more sane.

And I still don't see why it's necessary to do this all in one effort. Julian's point was that the only technical reason to combine authentication work with re-specifying HTTP is to make the new authentication scheme MTI. Otherwise, the work can be done separately. Roy has expressed interest in coming up with a new scheme that isn't necessarily targeted at browsers -- which is great, but I don't see why it has to be part of this WG.

We potentially have a LOT of work on our plate, and that work is channeling the energy behind a new serialisation of HTTP into something worthy of being called HTTP. Doing research and development on Web security is a very different kind of work, and the two don't mix well, IME.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Feb 2012 00:40:13 +0000

Mark,

I was going to respond blow-by-blow but there's not much
point in that, other than to say that your mail seems to
me a tad over the top.

(Maybe you misinterpreted me describing what might happen
as some kind of threat to try slow people down or something,
I don't know. I do know that I don't do that kind of thing
and if I tried I probably wouldn't be very good at it anyway;-)

Anyway, I think we should focus on a way forward that attempts
progress on what we appear to agree is the desirable outcome:

 > They are VERY VERY VERY interested in security, as are many other
 > people in the broader community. If the IETF were to come up with a
 > viable proposal that solves their problems, they would beat down this
 > organisation's doors.

I proposed a plan that I think might allow us to make progress
on that. I believe we could.

S

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 26 Feb 2012 11:44:29 +1100

> point in that, other than to say that your mail seems to

Sorry if you think so. I'm VERY sensitive to the risks that we're undertaking here, and I want to be crystal-clear about what we're going to do. As I saw it, your path forward was a risky one.

> and if I tried I probably wouldn't be very good at it anyway;-)

It may not have been your intent; my concern was that the effect would be the same.

> on that. I believe we could.

OK, great. 

Could you please explain why you think tying this effort to HTTP/2.0 is necessary to achieve that? To me that's the critical bit, and I still haven't seen the reasoning (perhaps I missed it).

Thanks,

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Feb 2012 01:32:11 +0000

On 02/26/2012 12:44 AM, Mark Nottingham wrote:
> Sorry if you think so. I'm VERY sensitive to the risks that we're undertaking here,

Fair 'nuff. I consider my self fairly insensitive generally
which of course means I don't care what others think about
that:-)

 > and I want to be crystal-clear about what we're going to do.
 > As I saw it, your path forward was a risky one.

I don't get that. I'd be interested in why it appears that way
to you and if there are ways to reduce risk but still try
make progress on security stuff.

> It may not have been your intent; my concern was that the effect would be the same.

Don't get that either. I think I just pointed out the obvious
based on the proposed charter - at the point of the next proposed
re-charter, there'll be IETF/IESG review.

> Could you please explain why you think tying this effort to HTTP/2.0 is necessary to achieve that? To me that's the critical bit, and I still haven't seen the reasoning (perhaps I missed it).

That's a fair question that doesn't have a good and quick
answer, and some of the argument applies to the httpbis wg
and not to HTTP/2.0 per se.

Caveats: this is probably something that needs more bandwidth
than mail; most of the points below were already raised by
others on this thread (though I didn't go back through all
the mail yet) and this is not in any particular ordering.

- We've not really improved this in over a decade. Its time.
- The community's appreciation of better security has
   changed in that time as well so maybe its more tractable
   now and we've more experience of real attacks.
- Improving security after the fact is not a good plan.
- Thinking a separate security WG could provide an answer
   that'd be adopted seems less likely to work to some. (It
   does seem more likely to work for some others admittedly.)
- A backwards-incompatible change (if needed) could be
   done much more easily when changing HTTP. Its at least
   time to explore the area with that possibility in mind..
- A scheme less susceptible to phishing that got deployed
   could be very valuable. Its not ridiculous to think that
   might require breaking backwards compatibility somehow.

So, a bunch of things. Maybe none individually compelling.
But arguably taken together sufficiently convincing that
not attempting again to do something here would really be
inexcusable.

And yes, I do recognise that attempting to solve this does
add some risk. Most good things do.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 26 Feb 2012 12:54:02 +1100

> and not to HTTP/2.0 per se.

Aha. If we can decouple the auth work from the HTTP/2.0 deliverable, I'm less concerned -- although we're going to be quite busy. 

For *this* re-charter, can we only solicit proposals for auth, and make the decision about what/if we'll go ahead in the *next* re-charter? 

I.e., I'd like to wait before we decide on both pieces (the wire protocol and auth) before making commitments, or even plans. Part of the selection process for the wire protocol is determining implementer interest, and gathering the same information about the auth proposals will shed a lot more light on this conversation, I think.

> the mail yet) and this is not in any particular ordering.

That's OK - we'll be in Paris soon.

> - We've not really improved this in over a decade. Its time.

Don't disagree.

> - Improving security after the fact is not a good plan.

Of course.

>  does seem more likely to work for some others admittedly.)

Yes, there are arguments on both sides.

>  time to explore the area with that possibility in mind..

Hmm. One of the core ideas we're moving forward with is that 2.0 is semantically compatible with 1.x, even if it isn't syntactically. 

>  might require breaking backwards compatibility somehow.

Agreed, but I think that's much more about the browser UI than about the wire protocol.

> add some risk. Most good things do.

Absolutely.

Cheers,

---

From: Adrien de Croy <[email-masked]>
Date: Sun, 26 Feb 2012 14:54:01 +1300

I wonder if it would be helpful for people to outline what they expect 
are the issues to be solved by doing more work on an HTTP auth mechanism.

I get the feeling that some think the scope would encompass providing 
auth support for web applications, whereas others are mainly concerned 
with the transport level auth.

IMO http auth is not particularly suited to solve the issues required 
for web site authors, for the simple issue of administrative boundaries 
and realms of accounts.

For example the web server that sits on an OS that has 1 user database, 
yet hosts 10 web sites each of which require their own independent user 
database, and require the ability to create and destroy accounts, and 
these accounts NOT be OS ones (i.e. not grant any access to the OS).  
Sure these issues could be engineered around, but it would add to the 
current scope (for change) every web application that currently manages 
accounts (a great deal of them).

If we're just talking about transport auth, then what's wrong with 
something like kerberos.  As for server logging a client out, the auth 
mechanism would need a token that can be revoked by the server, since 
one cannot rely on client co-operation in such a matter.  A kerberos 
ticket seems to fit this bill.  then we'd just need a mechanism for a 
client to request revokation (logout).  It is also AFAIK supported on 
all server platforms, unlike any auth mechanism that requires access to 
plaintext passwords at the server end - these are not always available.

Adrien

On 26/02/2012 3:03 a.m., Julian Reschke wrote:
> authentication framework, then we should fix/augment/tune HTTP/1.1. 
> It's not going to go away anytime soon.
>
> Best regards, Julian
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 26 Feb 2012 07:14:00 +0100

Hi Amos,

> available to even clueless junior admin.

I get your point. I totally agree on the hop-by-hop view. It's what is
built today despite not having been designed this way, and a number of
current issues comes from the fact that we try to insert intermediaries
by force and create hops where they're not expected (eg: setting a LB
between an NTLM client-based and server is a real pain).

My goal is not to define new auth schemes ; it's only to ensure that
what we define does not require awful hacks when auth needs to be added.

Best regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 26 Feb 2012 07:28:18 +0100

Hi Adrien,

> with the transport level auth.

I am personally concerned with the risk that new auth schemes continue
to mix messages and transport. I don't think we need to define these new
schemes, we just need to ensure the new protocol offers provision for
doing the things right. I'd like to ensure we never get a new NTLM-like
design error which forces every implementation to break the HTTP model
to try to be compatible.

Also, (that's not directly related to auth) it would be nice if we could
have a random session ID in messages that browsers would send to help the
whole intermediary chain select the appropriate server. A simple hash on
this session ID would make load balancing much easier and much more reliable
than any other algorithm right now and would definitely help when challenge
based auth schemes are needed.

(...)
> plaintext passwords at the server end - these are not always available.

It is comparable to what is already done with cookies in most applications
(ie I have nothing against this). We just have to keep in mind that auth
methods will change with time. Many applications right now expect two-factor
auth and/or some complex UI adaptations to protect against malware. That's
why I think that our work on supporting auth should mainly ensure we offer
the solid blocks for building new auth schemes and don't necessarily need
to define these schemes ourselves.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Feb 2012 15:54:10 +0100

On 2012-02-26 10:44, Yoav Nir wrote:
> I think I have *an* answer to this, though probably not *the* answer.
>
> There's two stages to adoption - implementation and roll-out. Obviously you can't roll out "new authentication" before the browsers and servers implement it. For my website, I wouldn't roll out new auth if only one or two of the browsers out there implemented it. Even if all the big ones (IE, Firefox, Chrome, Opera) did, I would still have to provide a backwards compatibility authentication scheme to support older browsers. This would lead to both inconsistent UI and to ugly javascript that detects the browser version, and makes the roll-out slower.

You can send multiple challenges in one response.

We could also define a way to make HTML-form-based login an HTTP scheme 
(see <http://tools.ietf.org/id/draft-broyer-http-cookie-auth-00.txt>) to 
integrate better what people use today.

> If any HTTP/2.0 browser is bound to have "new authentication" it makes things much easier.
>
> This could be circumvented by adding request headers that advertise capabilities, but I don't think we like those much.

I don't believe we need those. If we do, we should retrofit this into 
1.1 as well.

Anyway, I see lots of theoretical discussion about process. What's 
needed is people doing the actual work, both spec-wise and 
implementation-wise. That's the critical problem.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Feb 2012 21:49:30 +0000

> I.e., I'd like to wait before we decide on both pieces (the wire protocol and auth) before making commitments, or even plans. Part of the selection process for the wire protocol is determining impl…

Right, that's pretty close to what I proposed.

Let's see if we hear supportive noises or howls of outrage or silence.

I think I'd suggest to keep the idea of chartering a sec wg to pick up
the pieces that httpbis doesn't want to progress, once that situation 
becomes clear. All going well, that'd result in some experimental RFCs
that could be picked up with little effort should events warrant. But
that doesn't directly impact on httpbis I guess.

S.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 26 Feb 2012 09:45:09 +0000

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Fri, 24 Feb 2012 22:17:14 +0000

>> per the above (or whatever text goes into the charter)

<snip/>

> There will be overlap in wg membership, but not nearly as much as would be needed for your proposal.

I like the idea, but there is always the danger of the HAM working group either getting stuck with multiple non-interoperable proposals like we've seen at IPsecME with the PAKE work.

There is also the possibility of getting stuck with conflicting requirements. For example, there will be a need to use existing user databases (RADIUS/DIAMETER servers, LDAP directories), but that is hard to reconcile with the preference for ZKPs.

I'm not really worried, because HTTP/2.0 is bound to take a long time, and there will be plenty of opportunity for chair and ADs to step in and intervene if the wg actually does that.

On a more technical note, we are 12 days past the cutoff date for new BoF session requests, so it's probably too late for a BoF in Paris. 

Yoav

---

From: TEVFİK ŞAHİN <[email-masked]>
Date: Sun, 26 Feb 2012 15:05:17 +0000

Zc
-----Original Message-----
From: Yoav Nir
Sent:  26.02.2012, 11:45
To: Mark Nottingham
Cc: The IESG; [email-masked] Group; IETF-Discussion Discussion
Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Yoav

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

“This Message (including any attachments) contains confidential information and is intended only for the individual named. If you are not the named adressee or not related with the content of this Message, you are forbidden to read, disseminate, distribute, copy, reproduce or modify this mail by our Company. Please notfy the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmisson can not be guaranteed to be secure or error-free as the mail may arrive late or incomplete or the information could be intercepted, corrupted, lost, destroyed, amended, , or contain viruses. The sender therefore does not accept liability for any errors, loss of integrity or confidentiality or ommissions in the contents of this Message or for the information transmission, reception, storage of use of such in any way whatsoever, which arise as a result of e-mail transmission. Any opinions expressed in this message are those of the author and may not necessarily reflect the opinions of Our Company.

Copyright in documents created by or on behalf of our Company remains vested in us, and we assert all of our moral and intellectual property rights.”

“Bu mesaj (ve ekleri) gizli bilgi içermektedir ve sadece gönderilen kişiye yöneliktir. Bu e-mailin muhatabı değilseniz veya içeriği ile ilginiz yoksa, Şirketimizin onayı olmaksızın bu mesajın okunması, değiştirilmesi, kopyalanması, üçüncü kişilere açıklanması, yayınlanması, ifşa edilmesi veya iletilmesi yasaktır. Bu mesajın gönderilmek istendiği kişi değilseniz (ya da bu e-posta'yı yanlışlıkla aldıysanız), lütfen yollayan kişiyi hemen haberdar ediniz ve mesajı sisteminizden derhal siliniz. E-mail iletiminin güvenli veya hatasız olduğunun garantisi olmadığından geç veya eksik iletim veya içerik ve bilgilerde eksiklik, kayıp, değişiklik veya virüs olabilir. Bu nedenle, bu mesajın iletiminden dolayı, gönderen, içerikteki hata, eksiklik, doğruluğun ve gizliliğin ihlalinden veya bu yolla bilgi paylaşımı, iletimi, depolanması gibi herhangi bir kullanımından hiçbir şekilde sorumlu değildir. Bu mesajın içeriği yazarına ait olup, Şirketimizin görüşlerini içermeyebilir.

Bu mesajın içeriğinde geçen Şirketimizin ad veya nanıma yaratılan fikri ve sınai haklar Şirketimize ait olup, maddi ve manevi tüm hakları Şirketimizde saklıdır.”

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 20:55:24 +0100

> because it won't get adopted.

I do not agree that getting new auth schemes deployed if they do make
sense is such big problem in the longer scope.

We have already had two new auth schemes deployed within HTTP/1.1 during
the lifetime of HTTP/1.1 and which is in wide scale use today across
numerous different implementations. And these doesn't even followin HTTP
semantics...

A beauty of HTTP auth model here is that it can downgrade nicely,
allowing old clients to continue working only not gaining the benefits
of the new auth model. But that obviously have security implications as
well if newer user-agents can be fooled into downgrading.

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 20:57:31 +0100

> changes to the framework, I dunno.)

Obviously not. Fixing the framework giving better use of auth schemes
may triggering interest in finding a better auth scheme however.

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 21:11:00 +0100

> there's something wrong with it, I'd like to know.

Only the thing said earluer

- Define how servers may influence the visible appearance of the login
action

- Perhaps some way of triggering a logout.

> that activity *right now*?

Nothing.

A cleaned up http digest with less fancy bells no one implements
correctly and stronger methods would do nicely at improving the raw
security side of things.

But at the same time it alone does solve the reasons why HTTP Digest is
not widely used today which is or any of the newer use cases with auth
delegation via trusted third parties.

A very interesting thought is to look into how for example Kerberos
could be implemented as a first class HTTP Auth citizen without
violating HTTP messaging semantics. Is there anything needed at the
framework side for making that work right?

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 21:20:26 +0100

> This could be circumvented by adding request headers that advertise capabilities, but I don't think we like those much.

HTTP auth have response header that advertise capabilities. Works quite
well. Just challenge for all the auth schemes you support and the client
picks what it thinks is the best.

Regards
Henrik

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 29 Feb 2012 12:39:15 -0800

> picks what it thinks is the best.

It doesn't work well if your goal is to never send passwords in the clear
and never share the true password (before being hashed) with each server,
but that's because of the lack of new auth schemes.  Hence, it isn't
actually useful for the introduction of new schemes that are intended
to solve those very problems.

....Roy

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 29 Feb 2012 23:30:03 +0100

> to solve those very problems.

I disagree. It allows for a clean transition. Yes, the goal is not
reached until you can disable basic auth, but this does not mean it's
not useful. It's not realistic to have a model of protocol evolution
without transition period.

There may be framework things to improve in that area making sure that
user-agents are not easily fooled into downgrading to a less secure auth
scheme than needed, but not sure it can be realistically done within
HTTP/1.1.

Regards
Henrik