Subject: [http-auth] rev -02 of charter text

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 23:01:51 +0000

A go at taking into account today's flurry of mail.

If you can, please send old/new text this time. If not,
then don't:-)

Ta,
S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 18:01:58 -0600

> If you can, please send old/new text this time. If not,

This is much better.  I like the clarification about "changes to
HTTP".  I still think the device authentication anti-requirement needs
clarification; I propose that device state authentication (think NEA)
be out of scope, but that as long an authentication mechanism does not
distinguish between humans and devices it should be OK.

For my proposal I will look into specifying a MAC mechanism for use
post-authentication to bind requests to sessions using the
WWW-Authenticate header, which would remove one significant header
addition in my proposal.  I will also look into using
draft-hallambaker-httpintegrity-01, as PHB has agreed to make changes
(namely, to support adding a channel binding input to his MAC
proposal) that would make it usable here.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Nov 2012 00:24:20 +0000

> distinguish between humans and devices it should be OK.

WFM,
S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 20:04:16 -0600

Ah, so the issue re: device authen. was device state authen?  OK, good
to know.  And I agree, that's not what we should be doing.  (Although,
of course, a pluggable framework means that a new authen. mech. can
come along later that does provide that, possibly by reusing work from
NEA.)

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 21:32:07 -0600

Regarding any possible addition of HTTP headers, we should not
preclude the specification of provisional or permanent header
registrations, each requiring only Expert Review, not for an
Experimental-track RFC.  Given that only Expert Review is required for
adding HTTP headers, I think we should not (indeed, must not) require
http-bis review of header additions, though should encourage inviting
http-bis review (not the same thing).  Remember, the http-bis WG
doesn't seem to have any interest in http-auth work, so requiring them
to review our work seems like a poison pill.

Moreover, I don't see a strong argument for saying that the addition
of a session binding header (say) amounts to a modification of HTTP,
or one that we could not ourselves undertake.  The requirement of only
Expert Review for adding headers only strengthens my conviction of
this.

Nico
--

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Nov 2012 16:06:23 +1100

> to review our work seems like a poison pill.

That's a really distorted view of things. You're effectively saying that you're going to purposefully avoid having HTTP experts and implementers review your work.

> Expert Review for adding headers only strengthens my conviction of

To me, the constraints on this proposed WG are there to keep its feet more firmly on the ground.

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 23:17:36 -0600

> That's a really distorted view of things. You're effectively saying that you're going to purposefully avoid having HTTP experts and implementers review your work.

Not at all: the registrations require expert review.

> To me, the constraints on this proposed WG are there to keep its feet more firmly on the ground.

Constraints are good, sure, but in the world of HTTP much of interest
occurs in headers; requiring no new headers imposes a very large
constraint, much larger, I think, than intended.  What we're looking
for is a good rule for distinguishing headers that really require
review from http-bis versus ones where we can get by with expert
review, sort of like the obscenity standard ("I know it when I see
it"), only more objective.  I have not yet devised a good such rule,
but I don't want to settle for an extreme rule as currently proposed
either.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 23:38:13 -0600

One possible objective rule for headers might be they not require
server-side state.  For example, a session header with MAC for binding
could be designed either so it requires server-side state or not (or
either, at the server's discretion).  I'll note that a number of MAC
binding headers have been proposed to date, and none have been
controversial as additions to HTTP.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 23:44:34 -0600

I should also add that a session binding that has no server-side state
cannot provide replay protection, but I think that's just as well here
as the binding involves channel binding and TLS protects against
replays well enough.

Here's an example of something that should definitely be out of scope:
a method for providing cryptographic transport protection without TLS.

I'd probably be happy to say that new headers other than those needed
for session binding are out of scope.  But I object to excluding
session binding.  I could always consider session binding to be a form
of authentication (it is) and reuse WWW-Authenticate, in which case
the issue becomes moot, though some might nonetheless object.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 23:52:45 -0600

I'd also be happy with asking http-bis now whether they care where
session binding work gets done.  I'm just not happy with us
unilaterally declaring http-bis to be the home of things they may not
care to review (as, e.g., all of the http-auth work we're talking
about).  That is, I don't want any requirements that are impossible to
meet.

Nico
--

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Nov 2012 17:02:54 +1100

Let's be clear. HTTPbis didn't take this on because we didn't think there was a good chance of success -- as measured by deployment -- not because we don't care about authentication. 

If this proposed WG manages to come up with something actually useful that implementers want to work with, we'll absolutely review it and provide input. What I don't want to see is a group of people with comparatively little HTTP expertise minting new HTTP syntax or protocol mechanisms. 

Regards,

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Nov 2012 00:12:05 -0600

> Let's be clear. HTTPbis didn't take this on because we didn't think there was a good chance of success -- as measured by deployment -- not because we don't care about authentication.

I thought it was simply that there was no consensus to adopt any of
the works, as that's the call that was to be made: a consensus call on
adoption.

> If this proposed WG manages to come up with something actually useful that implementers want to work with, we'll absolutely review it and provide input. What I don't want to see is a group of peopl…

Well, first of all they'll get a chance to review any and all work of
this WG.  I've explained my concern with the charter as proposed: it
has a constraint phrased as a requirement that might have no chance of
meeting.  If indeed http-bis is willing to review such proposals as
session binding headers, then I may be happy to let it go, but it's
not clear to me that http-bis is indeed willing to do such review, and
anyways it's clear that it's not required to in order for such work to
progress, by the very rules (which I didn't write) of the registry in
question.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Nov 2012 00:20:00 -0600

Also, I want to make sure that http-bis doesn't need to be
re-chartered in order for any proposals here to be able to progress.
It's one thing to ask http-bis for input and proceed if they provide
none, and another to declare that some work belongs in http-bis where
it may not get done (e.g., because it's not in-scope for it).

Re-reading the last proposed charter I see that it requires only
consensus from http-bis.  That seems reasonable.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Nov 2012 08:25:39 +0100

> For the basic scheme, no technical changes are envisaged, the goal
> will simply be to improve the documentation of the scheme to allow
> obsoleting RFC 2617 which has some significant flaws when looked back
> at 13 years later.

Well, it would be nice if, while doing this, we could address the 
well-documented issue of I18N in usernames and passwords (see 
<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html>).

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Nov 2012 08:23:42 +0000

> <http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html>).

Fair enough. (Assuming we get someone to do the work, any volunteers?)
Added to -03.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Nov 2012 08:10:46 -0500

I would like to see HTTP work better with all forms of authentication
whether they are performed in-band to HTTP or not.

In particular the reason that I proposed the Integrity header is that it
provides functionality that is needed to support Web Services that is
currently implemented in SOAP and WS-Security in a very complex and hard to
understand fashion that is much better expressed as a HTTP header.

Since the semantics of WWW-Authenticate are actually statefull and rather
complicated, using a new header to express the semantics is actually much
simpler over all.

My current proposal is in the following draft, I have been discussing how
to extend the draft to add support for TLS binding with Nico.

http://tools.ietf.org/html/draft-hallambaker-httpintegrity-01

As far as process goes, I would like the header to eventually be adopted as
a standards track item. Whether that is a HTTP-bis item that is also
discussed in HTTP-Auth or vice versa does not matter much to me.

What I do care about is that we don't end up with each new authentication
proposal developing a separate mechanism for session continuation when this
is a feature that can and should be achieved by a common scheme.

Authentication is actually three distinct but possibly overlapping concerns:

1) Credential Management
2) Session Management
3) Session Continuation

It is clear that Credential Management has to take place somewhere and
equally clear that the place for this to occur for explicit credentials is
not in-band to HTTP. But there is one form of credential management that I
think should be a much higher priority than bike shedding my crypto in
DIGEST and that is providing a sane replacement for the use of the HTTP
Cookie mechanism for bearer token authentication.

At pressent the HTTP authentication mechanism boils down to

Client: Hello
Server: Password is Bob
Client: 'Bob', How much money do I have
Server: Password is still Bob
Client: 'Bob', Send the money to Nigeria

I think this is a problem. It is the reason that CRIME and BEAST are an
issue. It is also the enabler for Cookie stealing affiliate fraud which is
a hundred million dollar fraud right now.

A better approach would be to divide cookies into two separate classes:

1) Client side state, these tokens should be encrypted by the server and
opaque to everything else. They should not be used as bearer tokens.

2) Authentication tokens that can be passed in band if people must so that
they can be used as a drop in replacement for the use of cookies as a
bearer token. In the new scheme the conversation would be:

Client: Hello
Server: ID is X, Password is <128 bits>
Client: X, <proof of possession of <128 bits>>, How much money do I have
Server:
Client: X, <proof of possession of <128 bits>>, Send the money to Nigeria

Where <proof of possession of <128 bits>>  is a scheme involving either a
challenge nonce or a counter or a timer so as to ensure that it is not a
bearer token.

Other that this, my firm belief is that Credential Management really
belongs outside the HTTP layer.

This is obviously not the best way to exchange credentials. I would prefer
to use an exchange involving a DH exchange so as to protect the initial
exchange against passive eavesdropping and to bind it to TLS etc. But we
need to find a way out of the swamp and a cookie that can't be stolen is a
big improvement.

Even if this is only implemented in one browser, there would be a seven or
eight figure incentive for certain net retailers with extensive affiliate
networks to implement it.

On the Session management side, the main thing is how to enable a 'log out'
function in the browser. Here the conflation of state cookies and
authentication cookies is a mess. The browser does not know which type of
cookie is which and deleting all the cookies can have a really undesirable
negative impact on the user.

All that we need to support a browser level 'log out of all sessions'
feature is to distinguish authentication data from client side state.

As mentioned in the start of this post, I see session continuation as a
capability that can be shared by all the authentication mechanisms. Once
the authentication credential has been presented we are faced with a
situation where we have some form of session identifier (possibly implicit
in the TCP session layer) some form of secret (most likely a symmetric
shared secret) and a need to bind future transaction messages to that
session.

I don't much care how the authentication session is set up. In fact it
seems like a successful Web authentication scheme should be authentication
protocol agnostic just like URLs are protocol agnostic. But we should be
able to agree to a common session continuation mechanism.

On Tue, Nov 13, 2012 at 6:01 PM, Stephen Farrell
<[email-masked]>wrote:

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

-- 
Website: http://hallambaker.com/

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Nov 2012 10:17:47 -0600

On Wed, Nov 14, 2012 at 7:10 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> [...]

Indeed, and as sessions come from authentication (well, they can be
just created out of thin air, with no real security, but let's leave
that use aside for now) it seems logical to bundle this work in the
same WG as (1).  That is why I prefer this staying here.

That said, if websec of http-bis want to work on this (i.e., get
re-chartered to include sessions) then I'm happy to leave it there
too, even if that split makes little sense to me.

>[...]
>
> Other that this, my firm belief is that Credential Management really belongs
> outside the HTTP layer.

"This" (the proof of possession session continuation thing) is the
only piece of session management that I also think belongs in-band
(i.e., in headers).  Session creation and destruction are best done
above HTTP (with POST and DELETE, as in my proposal, with DELETE being
superfluous when server-side state is stored by the client).

> need to find a way out of the swamp and a cookie that can't be stolen is a

Well, authentication mechanisms often involve key exchange facilities
as well, so that they can key sessions, which is why I see a strong
link between authentication and session continuation.

> capability that can be shared by all the authentication mechanisms. Once the
> authentication credential has been presented we are faced with a situation
> where we have some form of session identifier (possibly implicit in the TCP
> session layer) some form of secret (most likely a symmetric shared secret)
> and a need to bind future transaction messages to that session.
>
> I don't much care how the authentication session is set up. In fact it seems
> like a successful Web authentication scheme should be authentication

I agree with pretty much everything you wrote.  Note that a session
continuation scheme imposes requirements on authentication schemes
(e.g., "establish a symmetric shared secret").  Thus by separating
session continuation into a separate spec we're making that spec a
pre-requisite for HTTP authentication schemes (at least if we want to
do better than cookies, which surely we do).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Nov 2012 10:42:23 -0600

Phillip,

One thing I am confused about is your claim that WWW-Authenticate is
stateful, but I don't see that in the specification.  Indeed, Digest
even discusses how state can be encoded in an opaque directive as well
as in a nonce.

I would argue that using WWW-Authenticate to carry a
proof-of-possession session continuation is perfectly appropriate:
after all, we're authenticating members of a session.  The sequence of
events would then be:

1. Authentication by any unspecified method.  This includes
establishing a key for session continuation.

2. Post-authentication arbitrary requests with WWW-Authenticate to
bind the requests to the session.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Nov 2012 13:28:04 -0500

The thing with WWW-Authenticate and Authorization is that they are a total
mess. I didn't choose those headers BTW. I was sick with food poisoning
when they were thrown in.

The Authorization header describes authentication data for a start.

Most of the attributes that should have been defined as common attributes
are instead bound to the scheme. So Digest specifies a bunch of attributes
but these are really not the right ones and they are confused between
session establishment and continuation.

Thing with HTTP headers is that they are plentiful. In my view it is much
better to specify a new header for new semantics rather than try to contort
new semantics into an existing header. It is not like it is going to be
possible to drop in a new authentication scheme with the APIs that don't
provide access to unknown headers (if there are any left).

The only case where WWW-Authenticate is essential is when a 401
Unauthorized  response is returned. So there might be an argument for using
WWW-Authenticate as part of a session establishment protocol but I don't
see a good argument for using Authorization.

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Nov 2012 12:43:50 -0600

WWW-Authenticate is used for negotiation in 401s, so it's needed there.
The values of this header are specified by the mechanisms, so i see no
reason that it couldn't be used for session binding. And Digest's sins seem
irrelevant.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Nov 2012 14:02:29 -0500

Maybe using existing headers will appear to be the right thing after we are
finished. But I really prefer to look at the design of a mechanism
separately from how it is implemented in a 20 year old spec.

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Nov 2012 13:42:16 -0600

> separately from how it is implemented in a 20 year old spec.

M'ok, though nothing from the original is needed except for this:

   challenge   = auth-scheme 1*SP 1#auth-param

Everything in auth-param is specific to the the auth-scheme selected.

We must keep this much for 401s; we will need an auth-scheme by which
to indicate "or you can use session binding if you already have a
session", which is really a way of indicating support for sessions.

For the rest we can use a new header (though I don't think we have to)
and I'm willing to do that if nothing else so that we save some bytes
on the wire ;) (maybe).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Nov 2012 16:26:43 -0600

BTW, note that a simple session MAC thing is insufficient to protect
against CRIME/BEAST unless we have replay protection, which then requires
server-side state.  We can make it so we require a unique MAC (using a
unique nonce or tls-unique CB) at the beginning of a connection's life, but
that's weird.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Nov 2012 16:37:34 -0600

The session MAC does protect against MITM attacks because of the channel
binding, which is one of my main uses for this.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Nov 2012 17:56:17 -0600

> unique nonce or tls-unique CB) at the beginning of a connection's life, but

Oh, i forgot that thse attacks need to observe the same cookie many times,
so just changing a nonce input to the MAC suffices to defeat them without
needing any replay protection.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 15 Nov 2012 10:57:52 -0800

I think this discussion is perhaps a bit ahead of consensus on the charter.  ;-)

However, to continue the sin:  any HTTP-layer channel binding will need to account for TLS-channel renegotiation.  The world is never as simple as we would like it to be.

On Nov 14, 2012, at 2:26 PM, Nico Williams wrote:

> BTW, note that a simple session MAC thing is insufficient to protect against CRIME/BEAST unless we have replay protection, which then requires server-side state.  We can make it so we require a unique MAC (using a unique nonce or tls-unique CB) at the beginning of a connection's life, but that's weird.
> 
> Nico

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Nov 2012 14:05:25 -0600

On Thursday, November 15, 2012, Henry B. Hotz wrote:

> However, to continue the sin:  any HTTP-layer channel binding will need to
> account for TLS-channel renegotiation.  The world is never as simple as we
> would like it to be.
>

That's already accounted for :)  see RFC5929.  (And yes, there was some
trickiness getting that right, though mostly due to one implementor
shipping something slightly different than a previously agreed spec.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Nov 2012 22:02:18 -0600

FYI, with the agreed change regarding device authentication I'm happy with
this proposed charter.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Nov 2012 08:51:08 +0100

> Fair enough. (Assuming we get someone to do the work, any volunteers?)

Note that the work essentially is done (see the draft). What's missing 
and what has kept me from progressing it is a proof-of-concept 
implementation (I was planning to do that in the Mozilla code base, but 
that needs a new WWW-Authenticate parser first; see 
<http://greenbytes.de/tech/tc/httpauth/>).

Best regards, Julian