Re: TLS renegotiation

-----Original Message-----
From: Yoav Nir <synp71@live.com>
Date: Tuesday, 4 February 2014 07:25
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "Ludin, Stephen" <sludin@akamai.com>, Mike Belshe <mike@belshe.com>,
HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: TLS renegotiation
Resent-From: <ietf-http-wg@w3.org>
Resent-Date: Tue, 4 Feb 2014 07:26:01 +0000

>On 3/2/14 7:23 PM, Martin Thomson wrote:
>> On 3 February 2014 04:20, Yoav Nir <synp71@live.com> wrote:
>>> I don't think I can speak for all of those people, but I can speak for
>>>some.
>>> Client certificates on the web usually involve some user interaction.
>>>Even
>>> when not, they're rare. So I think we can live with needing another,
>>> non-coalesced connection for the certificate authentication. This would
>>> require some way for the server to know during the TLS handshake that
>>>this
>>> handshake requires a TLS handshake. Special ALPN string? An extension?
>>>An
>>> SCSV? Either way, the client would have to signal the server that it
>>>wants
>>> to present a client certificate. It would also require server-to-client
>>> signaling that client authentication is required at the HTTP (rather
>>>than
>>> TLS) layer.
>> I wasn't going to leap to solutions so soon.
>
>And you call yourself an engineer?  :-)
>You did ask what restrictions would be acceptable.
>
>> It's not a lack of possibilities that is the problem here.  It's a
>> lack of clarity around what the desired behaviour is.  If, as you
>> suggest, this is a problem that can be detected for a given request,
>> how do we then extrapolate that to other interactions with the same
>> origin?  Why would we?  This is, of course, always the issue with
>> client certificates.
>
>This is an issue with all forms of client or user authentication. Once
>I've entered my password for GMail (where I need to be authenticated so
>as to get my messages rather than yours), I seem to get personalized
>service from other Google services. At least my name appears everywhere.
>And there are those creepy content sites where the list of my Facebook
>friends who have read or liked this article appears on the right.
>
>The issue here is not the form of user authentication. It's the form of
>session management that we use based on cookies. Once the user has
>authenticated, her browser gets a cookie, and all future requests are
>"blessed" as part of the same session.
>
>I guess for websites with user authentication, regardless of whether
>that authentication happens at the TLS layer with client certificates,
>at the HTTP layer with Basic, Digest or MutualAuth, or at the
>application layer with forms, the process is something like this:
>
>  * A user connects to the web site. For the moment I'll ignore
>    connection coalescing and assume that website=origin.
>  * Depending on the website, we either establish a non-authenticated
>    session (by planting a cookie) or not. Either way, to get at the
>    really interesting stuff, the user needs to log in.
>  * So they can fill in a form, or click something that causes the
>    authentication dialog box to pop up, or click something that causes
>    the certificate picker to pop up.
>  * Once they complete the authentication, they get to an authenticated
>    session. That means that authorization for future requests in the
>    same session are handled according to user permissions.
>
>
>There are several issues with the current mechanism for session
>management: Other browser windows shared the same cookie, so you can't
>have two or more different sessions simultaneously with the same origin.
>Also the user cannot terminate a session unless the application provides
>this capability. But without going (again) into all of the reasons why
>we should have a serious look at how HTTP sessions are managed, there is
>nothing special about client certificates.
>
>Yoav
>
>
>

Much of this depends on:
* Definition of user
* UX requirements for the authenticated user

At the BBC we use client auth. a lot for various purposes, none of which
is (directly) audience facing.
'Users' are applications, engineers and editorial staff. My input to this
discussion is a widespread practical use case:
* Resources are typically http (conveniently for this group)
* We don't have a common requirement to 'negotiate up' to a higher
security level on a single resource, authentication requirement tends to
be grouped towards host:IP mappings
* Session lifetimes as long as practically possible

As the hard boundaries of an infrastructure start to dissolve, something
common with modern design methods and Cloud computing, we find an
increased need to mutually authenticate 'client' and server to avoid other
design nightmares. We find our use of TLS/HTTP with client auth
increasing, not decreasing and so a clean and robust model for h2 is
certainly desirable from our part. Renegotiation itself seems undesirable,
and I agree with the various comment heard today that forcing the client
to reconnect would be a valid workaround. Browser client experience aside
(which isn't great) I can't see that this would adversely impact any of
our workflows, engineers would 'understand' so it's just the editorial
teams that need a bit more protection from the user-agent....

I'm willing to share some of the particulars around the use case off 'the
list' should anyone think it useful...

Regards,
CraigT





-----------------------------
http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Wednesday, 5 March 2014 15:48:31 UTC