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/
- [TLS] HTTPS client-certificate-authentication in … Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Saint-Andre
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Paul Wouters
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Daniel Kahn Gillmor
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Matt McCutchen
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Stefan Winter
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Henry Story
- Re: [TLS] EU cards Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Peter Gutmann
- Re: [TLS] EU cards Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Henry Story
- Re: [TLS] EU cards Nikos Mavrogiannopoulos
- Re: [TLS] EU cards Yoav Nir
- Re: [TLS] EU cards Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] HTTPS client-certificate-authentication… Wan-Teh Chang
- Re: [TLS] EU cards Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… t.petch
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex