Re: [TLS] HTTPS client-certificate-authentication in browsers

Henry Story <henry.story@bblfish.net> Wed, 27 July 2011 22:54 UTC

Return-Path: <henry.story@bblfish.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41AD11E80AB for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 15:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.18
X-Spam-Level:
X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXfZreW5w2Is for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 15:54:30 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B688211E8084 for <tls@ietf.org>; Wed, 27 Jul 2011 15:54:28 -0700 (PDT)
Received: by wyj26 with SMTP id 26so1328067wyj.31 for <tls@ietf.org>; Wed, 27 Jul 2011 15:54:27 -0700 (PDT)
Received: by 10.227.160.140 with SMTP id n12mr343530wbx.69.1311807267749; Wed, 27 Jul 2011 15:54:27 -0700 (PDT)
Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id t46sm246425wec.38.2011.07.27.15.54.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 15:54:26 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <201107272237.p6RMbr7r015848@fs4113.wdf.sap.corp>
Date: Thu, 28 Jul 2011 00:54:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EDE3DAC-59A0-492F-A354-02CF472FC5AB@bblfish.net>
References: <201107272237.p6RMbr7r015848@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1244.3)
Cc: tls@ietf.org
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 22:54:32 -0000

On 28 Jul 2011, at 00:37, Martin Rex wrote:

> Henry Story wrote:
>> 
>> On 27 Jul 2011, at 23:29, Martin Rex wrote:
>>> 
>>> "Logoff" is a pure server-side concept with respect to server-side
>>> state.  A logoff concept that requires cooperation from the client
>>> is technical nonsense.  Any server-side destruction of backend-state
>>> associated with particular clients must work completely independent
>>> of what the client does.  Early consensual destruction of backend
>>> state if the client explicitly asks for it is OK.  But any
>>> server-initiated "logoff" concept that involves the client
>>> amounts to technical cluelessness.
>> 
>> why is that? Why can't the client log itself off.
> 
> That falls under "Early consensual destruction of backend state if
> the client explicitly asks for it is OK" above.
> 
>> That would be much better for the user, as he would be
>> in control of his identity.
> 
> The user is _always_ in control of his identity.
> But you can never get virginity back once you give it up.
> 
> Once you revealed your identity to a server, you can not
> undo it.

Well if you break the connection, and you reconnect without leaking 
any of the previous session information - ignoring the tricky
ip address issue - the server can't know you are the same person, and
so you are a virgin once more. (Which means of course that you loose
all the built up trust you may have worked on before. )

But of course you may wish to login to the site with a different personality.
A lot of people have done this by opening a number of Facebook accounts in order
to understand how that system works.

>> This could be done easily by a browser both with cookies and with TLS:
>> - with cookies: the browser should tie every cookie and state
>>    to a user identity. When the user switches identity, the cookies
>>    stop getting sent.
>> - with TLS the client breaks the connection,
>>   and re-established a completely new one.
> 
> If you're wondering whether there should be a standard where
> a Web Browser should offer a context-specific, easily accessible button
> to the user to make the Browser _prompt_ on the next connect to the server
> before providing any of the integrated "single Sign-on" functionality
> (be it cookies, WWW-Authenticate: headers, HTTP Negotiate, or TLS CCA
> or automatic user&password fill-in to forms).

This is what Aza Raskin at Mozilla Labs demonstrated with his Weave project.
http://www.azarask.in/blog/post/identity-in-the-browser-firefox/

I don't think this requires a standard here. It requires the browser to
be able to keep track of different user personas, be able to remember which
persona the user has on different sites, and make it easy for him/her
to logout or change persona on any of these sites. This could mean just sending
different cookies at the next connection (when changing persona) or sending
none - when becoming anonymous again.

> 
> Making such a functionality accessible to the server probably would
> not hurt.  Preferably _without_ javascript or other active content,
> and instead controls similar to (e.g. META) for page refresh and
> client-side cache flushing.

So as I see it the client does not need to do any of that. He can just
stop using the cookie information. 

Of course it could be nice if he browser could also send a polite logout 
message on a cookie or a TLS session before doing that. But I think it 
would already be a big step forward without this.

> 
> 
>> 
>>    For the server that ends up being the equivalent of a log-off.
> 
> If a user wants to perform a "logoff", he might be interested in
> _both_ happening:
> 
>  - the server side backend state getting flushed along with client-side
>    state (so that no-one with a copy of the server application sessionid
>    can resume the session from elsewhere without having to perform
>    an authentcation step).
> 
>  - the browser suspending _IN_A_CONTEXT/TARGET_SPECIFIC_FASHION_ any
>    single Sign-On functionality (Cookies,WWW-Authenticate,HTTP Negotiate,
>    TLS CCA, automatic user&password fill-in) until it is interactively
>    reconfirmed to continue


agree. 
I just think the second one could be done without the first one being finished.

> 
> It may be more difficult to standardize a client-side "button" and
> the signaling of the "logoff" to the server application so that it
> can clean up, than to require the application to offer a "logoff"
> button and tell the browser to suspend Single Sign-On for this
> context/target.

I don't think you need to standardise the client. Aza Raskin showed a
very appealing UI it seems to me. Others could do that in different ways.

>  Closing of a browser window does not necessarily
> imply a "logoff" for apps that allow for several parallel and
> independent workflows.  The server app usually knows more about
> the application architecture than the user does (and whether to
> warn the user about unsaved date that will get purged by logoff)

well login/logoff is perhaps the wrong terms. Authentication and recognition
of a user is what counts. 

> 
> 
> -Martin

Social Web Architect
http://bblfish.net/