Re: [TLS] HTTPS client-certificate-authentication in browsers
Martin Rex <mrex@sap.com> Wed, 27 July 2011 22:38 UTC
Return-Path: <mrex@sap.com>
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 4D31E11E8092 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 15:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8]
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 7JAhnAcotkJO for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 15:38:02 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6C41711E8084 for <tls@ietf.org>; Wed, 27 Jul 2011 15:38:02 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6RMbsSs017504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 00:37:59 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107272237.p6RMbr7r015848@fs4113.wdf.sap.corp>
To: henry.story@bblfish.net
Date: Thu, 28 Jul 2011 00:37:53 +0200
In-Reply-To: <6030F823-5D49-40FD-B619-3C9FCF9E2260@bblfish.net> from "Henry Story" at Jul 27, 11 11:56:49 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
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
Reply-To: mrex@sap.com
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:38:03 -0000
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. > > 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). 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. > > 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 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. 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) -Martin
- [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