Subject: [Unbearable] Proposal to reduce scope

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Dec 2014 10:13:15 -0500

I am usually the person who is arguing for the scope of a WG to be wider.
In this case I think it would be best if we narrowed the scope of the WG so
as to avoid conflict with other groups.

Following Alan Kay's assertion that the Internet is the only large scale
object oriented system functioning today, what I think important in a scope
discussion is to try to define the interface to other parts of the system.

As I see it, this problem should be scoped as being for two party
interactions. That gives us a bright line between unbearable and SAML,
OAUTH, etc. which are all designed to support multi party interactions.

Another constraint is that we are only dealing with a single authentication
factor and only for devices and we are requiring that the proof of
possession presents an unfeasible work factor to an attacker looking to
extract the credential.

It seems to me that binding to the TLS channel should certainly be an
option. But I don't think it should be a requirement because I don't think
TLS should be a requirement.

TLS is definitely desirable, but TLS is not necessarily end to end. There
are many architectures in which TLS is deployed in a system that hide the
tunnel parameters from the application.

What people are proposing with TLS binding is a layer violation. It is an
occasion where a layer violation is justified and useful but we are still
committing a layer violation because that is an inevitable consequence of
binding the application layer to the transport tunnel.

That is OK, I agree that we should support that as useful. But we have to
make it optional on the server side.

The client side is a little different. Here architecture would demand that
we make it an option too. But the point here is that the server wants to
have a way to make certain of getting an end to end channel.

I proposed the HTTP Session ID scheme some time ago and I find it
simplifies the design of Web Services immensely. There are some important
differences between my proposal and this one. I have also been thinking of
the problem a little more generally since so the SessionID proposal is not
necessarily the best one.

One objective of Session-ID was to provide a drop in replacement for HTTP
authentication cookies, 'hard cookies'. So the idea is that the client can
tell the server it supports hard cookies. If the server returns a hard
cookie to such a client, the client will present a proof of possession with
future requests and never send a soft-cookie.

So this is where I have been going since.

A hard cookie consists of:

* An opaque identifier
* A set of algorithm parameters
* A shared secret

In a Web Service context it is most convenient to provide these in the
discovery mechanism so I defined a JSON schema. And when the need for hard
cookies was raised I translated the encoding into a HTTP header:

Set-Session:
    Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
      j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
      oB29dgs/ei6ieINZtmvXNCm2NUkWA==
    Key=7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4
    Alg=HMAC-SHA256 Start=True Request=True Time=True Now=745531
    Domain=example.com Max-Age=31536000

It now occurs to me that the most convenient form for exchanging this type
of credential would be as a URI:

XXXSession:TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvij8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4oB29dgs_ei6ieINZtmvXNCm2NUkWA:
HMAC-SHA256:7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4

The advantage of the URI form is that it can be edited into configuration
files and the like to establish the secret out of band.

Now that isn't a path we should probably go down right now. But it would be
a very powerful technique. And it needn't be limited to symmetric key.

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 11:23:45 -0600

On Thu, Dec 11, 2014 at 10:13:15AM -0500, Phillip Hallam-Baker wrote:
> factor and only for devices and [...]

Hmm, maybe.  The one factor (the "token") might embody more than one in
the protocol for obtaining it.

> option. [...]

Yes.

>  [...]. But I don't think it should be a requirement because I don't think

Maybe.  The complexity of having two session crypto layers is quite
painful.  SASL has ended up dropping the "SL" part of SASL, leaving just
"SA", precisely because of this.

> tunnel parameters from the application.

But HTTP as-used is not end-to-end!  This list is about HTTP/web...

We could define "service" so broadly that it's effectively one end-
point, even with load balancing, routing, and CDNs in the picture.

Some deployments effectively do this.

It's a fair question whether that's what we want to do as a *standard*.

(I'm not sure.  It depends on what the cost of linking related services
in other ways might be.)

> What people are proposing with TLS binding is a layer violation. It is an

I disagree.  Channel binding is all about this.  Relying on an unbound
channel's protection is a bigger layer violation.  (In practice we do
perform a binding based on the server's name, but it's weak and in some
cases too asymmetrical, which is the reason for proposals like
origin-bound cookies, for example.)

> binding the application layer to the transport tunnel.

Abstractions are leaky.  Internet protocol layers are particularly
leaky.  I'm not justifying this.  The key is that this only helps when
the end-points match in some sense.  See above comments about
end-to-end.

> make it optional on the server side.

If the cost is HTTP-layer session crypto, then I think that is bound to
fail.  If the cost is application-layer session crypto, that might be
more feasible (largely because JavaScript crypto is spreading, and if
provided natively and if the tokens can key this... it should be
tolerable, even workable), but even then you risk doing double the
session crypto -- no one will want to!

(I've made my peace with TLS.  Can you tell?)

> have a way to make certain of getting an end to end channel.

Well, no, typical website architecture doesn't have a single end-point,
unless we define it broadly or otherwise link all those ends together.
(Not linking them at all gets us into various web security problems.)

> [...]

I did too.  IIRC there were several proposals.  You might recall that no
one cared.

Nico
--