Re: [TLS] HTTPS client-certificate-authentication in browsers
Anders Rundgren <anders.rundgren@telia.com> Wed, 27 July 2011 19:33 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 10CFF11E80F2 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 12:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.413
X-Spam-Level:
X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
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 FqekiEY59+af for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 12:33:04 -0700 (PDT)
Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF2711E80AD for <tls@ietf.org>; Wed, 27 Jul 2011 12:33:04 -0700 (PDT)
Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E9700002421; Wed, 27 Jul 2011 21:33:02 +0200
Message-ID: <4E3067DD.7020209@telia.com>
Date: Wed, 27 Jul 2011 21:32:45 +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: <201107271834.p6RIYfjB001802@fs4113.wdf.sap.corp>
In-Reply-To: <201107271834.p6RIYfjB001802@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: Wed, 27 Jul 2011 19:33:05 -0000
On 2011-07-27 20:34, Martin Rex wrote: > Anders Rundgren wrote: >> >> AFAICT you indirectly say that the de-facto standard for maintaining >> (note, not creating) secure sessions on the web, i.e. server-side >> HTTPS + session cookies is inferior. > > Huh? I'm completely lost. Pardon me if I read too much into your response. > If you want to do application-level session management, then you > ought to do application level session management, and NOT try to > mess around and interfere with Single Sign-On functionality at the > transport layer. Sure, but the question was to use client-side PKI in such an application. And most of all, how to do it in a such way the the applications doesn't get affected. > Even in closed environments, where TLS client certificates are used > for Single Sign-On, there usually is a fallback capability to use > passwords as well as support for migration from pure-password-based > logons to cert-based logons, and during the transition, both > authentication schemes must be supported in parallel. See previous section. > So the only sensible application level session management is doing > it uniformly at the application level independent of whether the > user authenticated via password (which he may have to re-enter > occasionally), or via some Single Sign-On functionality -- be it > TLS client certs or HTTP Negotiate, or potentially other schemes > (saml, oauth). This is exactly what I want. Unfortunately as I have described earlier, this is easier said than done using the currently only standardized CCA method. Without a server-initiated "logout" added to TLS it can never be done in a portable way. But as we (all) know the vendors doesn't care **** about CCA on the web. > You really don't want having to redesign & update the installed base > whenever you're adding support for a new authentication scheme, > therefore messing around with authentication scheme internals > when all you want to do is application level session management > seems to be an unconditionally bad idea. Of course nobody wants to redesign the applications. >> The fact is that exactly $0 has been spent by the people building and >> defining the TLS/HTTPS platforms on *researching* the issues I mentioned, >> while *hundreds of millions of dollars* has been spent on *code* that >> merges client-side PKI and the web in other ways than using HTTPS CCA. > > HTTPS CCA is a means to use Single Sign-On (using X.509 certs for > online authentication) and equivalent to using Kerberos with > HTTP Negotiate or Kerberos with other protocols. > > You seem to be entirely mislead about the purpose and usage constraints > of X.509 when used for GSS-API based Single Sign-On or TLS Single Sign-On. Purpose is an opinion. IMO, HTTPS CCA as an enterprise SSO-solution sucks ***. As a one-to-many-independent-RP-sign-in it does OK. > It has _NOTHING_ to do with digital signatures and can not be used > to authorize individual transactions. We are not talking about me; we are talking about hundreds of banks. > The only reliably means to ensure that a "proof of identity" can NEVER > be confused (or maliciously abused) with an explicit authorization > for some transaction is to use distinct PKI credentials, distinct > protocols and distinct credentials management functions. > > If PKI credentials, protocols or credentials management for these > completely distinct purposes are conflated, huge risks and damages > will ensue, and people will get hurt badly. They typically use the same certificate for app-level auth as for HTTPS CCA. They do (in the rare case specific signature applications are supported), provide certificate with the NR bit set for those. Anders
- [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