Re: [TLS] HTTPS client-certificate-authentication in browsers
Anders Rundgren <anders.rundgren@telia.com> Thu, 28 July 2011 04:51 UTC
Return-Path: <anders.rundgren@telia.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 ED70A21F8B15 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 21:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.567
X-Spam-Level:
X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 VnMTTHsPGgqN for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 21:51:20 -0700 (PDT)
Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1390C21F8B12 for <tls@ietf.org>; Wed, 27 Jul 2011 21:51:20 -0700 (PDT)
Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F008006EF; Thu, 28 Jul 2011 06:51:18 +0200
Message-ID: <4E30EAB7.8030406@telia.com>
Date: Thu, 28 Jul 2011 06:51:03 +0200
From: Anders Rundgren <anders.rundgren@telia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: mrex@sap.com
References: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp>
In-Reply-To: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Thu, 28 Jul 2011 04:51:21 -0000
On 2011-07-27 23:29, Martin Rex wrote: > Anders Rundgren wrote: >> >> Lots of banks wants to use CCA for their users. > > That is a non sequitur. > > Banks (here in Germany) have abandoned tradtional TANs based on > the unconditional presumption that client PCs are infested with > malware, and most banks in Germany are currently replacing indexed TANs (iTAN) > presumably based on the perception that malware on clients (trojans/phishing) > has caught up with iTAN procedure complexity. > > At this point, with the presumption that all client PCs are > thoroughly infested with malware, going for a Single Sign-On > mechanism would be completely braindead and irresponsible. So using client certificates for authentication is such a bad idea that there is no point in looking into issues on how to make it better? How is the German e-card supposed work then? When it comes to malware the situation in most cases is that the PKI underpinnings featured in modern computers haven't progressed a single step since 1995 when it was introduced. Elementary (in principle at least) stuff like putting ACLs on keys so that only granted applications which has been known for decades is still considered a research topic. Leaving this thread, continuing with making PKI for banks and other a better solution than passwords. Anders > > >> >> They find HTTPS' way of doing that intrusive. >> >> On the web you logoff from (or by) the server. >> >> Naturally logoffs must trickle down to clients >> if they have logged-in using HTTPS CCA otherwise >> they are de-facto logged-in due to the TLS caching. > > "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. > > And application level state management ought to be ***completely*** > independent from the TLS session cache management. The server > side TLS session cache management must be completely independent > from application level backend state management when you're > using a transport with non-persistent connections (such as HTTPS). > > The lower protocol levels of the server must be free to manage > TLS session cache lifetime based on resource availability > and administrative or operational requirements, and short > server-side TLS session lifetimes (several minutes absolute lifetime), > server-side TLS session cache flushing (when performing > debugging on an otherwise productive system, or when updating > the server certificate or changing the list of trusted > client cert signers), as well as temporarily completely > disabling server side TLS session caching MUST NOT interfere > with application level session management. Any application > that suffers from such server side TLS session cache > characertistics is seriously and thoroughly broken > (lack of abstraction and invalid protocol layering). > > > -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