Subject: [http-auth] Fwd: [TLS] TLS-OBC proposal

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Aug 2011 12:03:30 -0600

Of interest.

-------- Original Message --------
Subject: 	[TLS] TLS-OBC proposal
Date: 	Mon, 22 Aug 2011 10:53:05 -0700
From: 	Dirk Balfanz <[email-masked]>
To: 	[email-masked]

Dear TLS-WG,

I few weeks ago I presented a proposal for an "origin-bound
certificates" TLS extension at IETF 81. It's much easier to understand
what this extension is trying to accomplish when presented in a broader
context of web authentication (which I tried to give in Quebec), so I
put together a little web site that is supposed to do just that for
those who couldn't be at the IETF meeting: http://browserauth.net (This
took me a little while, hence the delay in sending out the I-D).

Anyway, here is the
I-D: http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit
for your comments/feedback. (Again, remember to read
http://browserauth.net for some context.)

All feedback is welcome, of course, but if you can't think of anything
to comment on, I have a couple particular questions:

- in Section 2.1.1 we currently stipulate that the client include the
origin of the origin-bound cert as part of the OBC X.509 extension. When
we implemented this, we didn't really know what to do with that data on
the server side. If the client also uses TLS-SNI, then we could imagine
comparing the SNI and OBC origins in some manner on the server side, but
there isn't really a vehicle to signal an error back to the client
saying "your SNI and OBC origins don't match". Similarly, we could
perhaps at some higher layer compare the HTTP "Host" header with the OBC
origin, but then again - what do you do when they don't match? Respond
with a 400 at the HTTP layer? An alternative to the current language in
the I-D would be to simply mark the cert as origin-bound, but without
putting the origin itself into the cert. Any thoughts?

- What do you think of the privacy-enhancing power of using per-origin
certs? The idea there is that different domains see different
"identities" (public keys) for the same client. Of course, if two
domains choose to collaborate, they can probably find a way to correlate
the two identities they see for the same client. This is similar to
cookies, where normally "identities" (cookies) for one domain are not
revealed to another domain unless, of course, they choose to
collaborate. How much privacy would we really lose if we just used one
certificate for all origins? It would certainly make the design and
implementation simpler. (I tend to favor per-origin certs, but I'm
curious as to what other people think.)

Thanks for your consideration!

Dirk.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Aug 2011 11:43:53 +0100

> Of interest.

Indeed. This is quite like the idea I was trying
to propose on this list before quebec, but does
the negotiation inside TLS rather than as a HTTP
authentication scheme.

I *think* I'd still prefer the latter, but am
wondering if the authors thought about that?

One of the reasons it might be better to do this
outside TLS is that I think then it'd be easier
for a site to allow a user to bind >1 of these
cert to the same account (you could provide the
URL that allows that as a parameter maybe).
Again though, maybe the authors thought that
through, which I didn't;-)

S.

PS: Since the question relates to http auth, I've
not cc'd the tls list.

> From: 	Dirk Balfanz<[email-masked]>
> To: 	[email-masked]
>
>
>
> Dear TLS-WG,
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 24 Aug 2011 23:08:03 -0700

> wondering if the authors thought about that?
I'll copy-and-paste a response I gave to a similar question on the TLS list
below::

I made a few attempts at doing this on HTTP layer - they didn't really work
out. One problem is security: if we look at integrity, for example, TLS
gives us that for free. To recreate that, say, at the HTTP layer, we'd have
to invent some form of signature on the HTTP request. So immediately the
question is: how much of the request do you sign? Do you sign the all
headers? The POST body? If you sign the whole POST body, then you can't
generate the signature until you've seen the whole POST body. What if the
POST body is a multi-gigabyte video? And if the signature goes into the HTTP
headers, which must come _before_ the POST body, this means you have read
the whole POST body for signing it, and then read it again to pump it out to
the network (assuming it's so big that it doesn't fit into whatever buffer
you have).

Another problem was performance: Signing every single HTTP request with an
asymmetric key seems like overkill. So somehow, the server and client would
have to negotiate an HMAC key that would be used to sign HTTP requests. That
HMAC key would probably be visible to the attacker (which we assume sits in
the browser). To decrease the benefit that the attacker has from seeing the
HMAC key, we would re-negotiate a new HMAC key every so often, with the
client having to re-prove that it is in possession of its private key (we
assume that the attacker can't get to the private key, since that can sit in
a TPM). It's hard to imagine how to do that on the HTTP or application layer
without introducing a roundtrip between client and server that establishes
that new HMAC key. While that roundtrip is happening, you can't make other
calls to the server (well, you can make 3 others or so depending on how many
simultaneous HTTP connections your browser allows with a server, but the
point is that you're using one of your limited number of TCP channels for
this key renegotiation). In TLS, we have a similar problem - the session
master secret might be known to the attacker, so every now and then we'd
like to reset it by renegotiating the TLS session. In TLS, however, we can
interleave data and handshake messages, so renegotiating the session secret
doesn't mean that we're holding up a whole TCP connection.

These (and a couple of other) nice features that TLS gives us for free we
would end up "reinventing" on the HTTP layer, up to the point where we would
have reinvented almost all of TLS.

> through, which I didn't;-)

Just like today you can have multiple cookies "bound" to the same account
(e.g., one for the browser session you have open on your desktop, and one
for the browser session on your laptop), you can do the same thing with
TLS-OBC: you simply bind the cookie that you set on the desktop browser to
the desktop browser's cert, and the cookie that you set on the laptop
browser to the laptop browser's cert.

Does this make sense?

Dirk.

>> I-D: http://tools.ietf.org/html/**draft-balfanz-tls-obc<http://tools.ietf.org/html/draft-balfanz-tls-obc>,
>> which I submit
>> ______________________________**_________________
>> http-auth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/http-auth<https://www.ietf.org/mailman/listinfo/http-auth>
>>
>

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 25 Aug 2011 15:52:52 +0900

Hi Dirk,

This does support for use of TLS, but does not support for doing
authentication and authorization in TLS.
Your point mentioned seems to be solved by the major solution which
has already been widely deployed:
using TLS for encryption and basic server authentication, and
performing authentication in the application
layer. What we need here more are strong authentication and channel binding
(which I am proposing one of them).

Doing authentication in the lower layer like TLS brings too much
complexity and inconvenience to
both applications and users.  Apart from TLS-OBC for a while, for
example, TLS-SRP will work
on Web only for very simple web application, but it cannot support any
good user experiences
for conventional large websites which usually need much control of how
and when the users
will be authenticated and authorized.
TLS-OBC seems to be a bit different in this situation, but can you
give me some more hint
on the sales point of TLS-OBS, compared to using the combination of
conventional TLS,
some secure session management (e.g. secure cookie), HTTP or application-layer
authentication (which the TLS-OBS is already relying on), and channel
binding among those?

And one another word, you've mentioned about use of TLS renegotiation
for resetting the key,
but please never rely on TLS renegotiation for any means
other than re-establishing the session key independently with the upper-layer's
requirements (e.g. solely controlled by the number of bits sent or the
time since key generation).
Controlling TLS's behavior from the application layer seems never be
realistic to be implemented and
deployed, especially on the Web server side.  This requirement is very strong
especially on the Web system than others, because Web server (which has TLS
capability) and Web applications are separate entities with loose
coupling interfaces.
This is not the case for other services like SMTP or IMAP: each mail
server itself
handles both TLS and the application logic in a single application, so
they can e.g. kick in TLS-SRP using TLS renegotiation if desired.

2011/8/25 Dirk Balfanz <[email-masked]>:
>
>
> On Tue, Aug 23, 2011 at 3:43 AM, Stephen Farrell <[email-masked]>
> wrote:
>>
>>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Aug 2011 09:50:30 +0100

> I'll copy-and-paste a response I gave to a similar question on the TLS list

Yep, saw that there, but its the answer to a different question:-)

What I was thinking about was having a HTTP authentication scheme
that flagged that the server supported OBC (or equivalent) and
then having the client (re)negotiate TLS with a new or existing
OBC cert. So basically using TLS as-is in protocol terms, but
flagging the OBC stuff in HTTP.

>> for a site to allow a user to bind>1 of these

Again I think you're answering a different question.

The issue with any TLS-mutual auth scheme is that the user with >1
device needs a way to bind those TLS client certs to one account.
I think for any TLS mutual auth scheme to work we need a way
to do that, including OBC or equivalent. I was asking if there's
a way to do that with your scheme, and suggesting that maybe it'd
be easier to do if the negotiation of OBC happened at the HTTP
layer.

S.