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

From: Dirk Balfanz <[email-masked]>
Date: Thu, 1 Sep 2011 17:16:21 -0700

On Wed, Aug 24, 2011 at 11:52 PM, Yutaka OIWA <[email-masked]> wrote:

> 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.

Agreed. Which is why we don't actually attempt to authenticate the user at
the TLS layer. "Traditional" TLS ClientAuth attempts to do that (and so does
TLS/SRP, if my quick glance at the doc didn't deceive me), and I explain on
browserauth.net why I think that's broken:
http://www.browserauth.net/tls-client-authentication

>  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?
>

Channel-binding the cookie is exactly what TLS-OBC can support: see
http://www.browserauth.net/channel-bound-cookies That's what I imagine will
(continue to) be used to authenticate users - at the HTTP layer.

> 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.

Yes - agreed. Things like re-establishing the session key would totally be
up to the TLS layer - the layers on top of that don't control that. If we
channel-bind the cookie to the client's origin-bound cert like I propose,
then re-establishing the session doesn't break the cookie since the new
session will still be authenticated with the same client-side cert. So the
TLS layer can re-establish sessions without affecting the upper layers.

Dirk.

 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:
> >>
> >>
> >> On 08/22/2011 07:03 PM, Peter Saint-Andre wrote:
> >>>
> >>> 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?
> >>
> >
> > 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.
> >
> >>
> >> 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;-)
> >
> > 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.
> >
> >>
> >> S.
> >>
> >> PS: Since the question relates to http auth, I've
> >> not cc'd the tls list.
> >>
> >>
> >>>
> >>> -------- 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.
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> http-auth mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/http-auth
> >
> >
> > _______________________________________________
> > http-auth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/http-auth
> >
> >
>

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 1 Sep 2011 17:33:52 -0700

On Thu, Aug 25, 2011 at 1:50 AM, Stephen Farrell
<[email-masked]>wrote:

>
>
> On 08/25/2011 07:08 AM, Dirk Balfanz wrote:
>
>> On Tue, Aug 23, 2011 at 3:43 AM, Stephen Farrell
>> <[email-masked]>**wrote:
>>
>>
>>>
> 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.

Oh I see.

How would that work in practice:

- during the first handshake, the server doesn't ask for a client cert (so
as to make sure the user-agent doesn't pop up useless UI)
- then, once the HTTP request comes in and the client says "I have an
origin-bound cert", the server instructs the TLS layer to renegotiate the
session
- this time, the server _does_ require a client cert, but somehow (how?)
makes it clear that the client should use an origin-bound cert, and not pop
up any UI to the user.

Did I get that right?

If so, then a few questions:

- doesn't that mean more round trips (immediate session renegotiation)?
- if a server _does_ want to use "traditional" TLS ClientAuth (maybe in an
enterprise setting where they have installed certs on employees' machines),
then presumably the server would send a certificate request during the
"first" handshake?
- when the TLS layer on the client side sees a certificate request, how does
it know whether to use a "traditional" cert (with UI), or an
origin-bound-cert?
- similarly, when the TLS layer on the server side receives a client
certificate, how does it know whether to employ "traditional" verification
techniques (looking for it to chain up to a corporate CA, for example), or
"OBC"-style techniques (allowing self-signed certs)? Sounds to me like the
TLS layers would have to instructed somehow by the upper layers to switch to
an "OBC" mode?

Generally speaking, what's the advantage of signalling support for OBCs on
the HTTP layer? Is it the fact that we seem be able to get away doing this
without actually defining any TLS extension?

>>> for a site to allow a user to bind>1 of these
>> TLS-OBC: you simply bind the cookie that you set on the desktop browser to
> 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.
>

Mmh - that still sounds like you're asking what I though you were asking the
first time around. Maybe I'm still not quite understanding...

Anyway, here's another attempt at answering what (I think) you're asking:

- remember that the OBCs don't have user identity in them - they're
self-signed certs.
- so the two devices I have would each have their own OBC to talk to
www.example.com
- example.com, after authenticating me on the first device (in whichever
unspecified way), binds a cookie it sets on that device's browser to that
device's OBC.
- example.com, after authenticating me on the _second_ device (in whichever
unspecified way), binds a cookie it sets on that _seond_ device's browser to
that _second_ device's OBC.

So that's how the two certs would come to be bound to my account.

I'm having a feeling that I still didn't quite understand your question,
though...

Dirk.

>>>> those who couldn't be at the IETF meeting: http://browserauth.net (This
>>>> I-D: http://tools.ietf.org/html/****draft-balfanz-tls-obc<http://tools.ietf.org/html/**draft-balfanz-tls-obc>
>>>> <http://**tools.ietf.org/html/draft-**balfanz-tls-obc<http://tools.ietf.org/html/draft-balfanz-tls-obc>
>>>> >,
>>>>
>>>> which I submit
>>>> origin of the origin-bound cert as part of the OBC X.509 extension. When
>>>> comparing the SNI and OBC origins in some manner on the server side, but
>>>> perhaps at some higher layer compare the HTTP "Host" header with the OBC
>>>> domains choose to collaborate, they can probably find a way to correlate
>>>> ______________________________****_________________
>>>> http-auth mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/****listinfo/http-auth<https://www.ietf.org/mailman/**listinfo/http-auth>
>>>> <https://**www.ietf.org/mailman/listinfo/**http-auth<https://www.ietf.org/mailman/listinfo/http-auth>
>>>> >
>>>>
>>>>
>>>
>>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 07 Sep 2011 14:32:13 +0100

Hi Dirk,

Sorry for being slow responding. I will get back to it
though soon's I can.

S

On 09/02/2011 01:33 AM, Dirk Balfanz wrote:
>> The issue with any TLS-mutual auth scheme is that the user with>1