Re: [TLS] HTTPS client-certificate-authentication in browsers
Martin Rex <mrex@sap.com> Wed, 27 July 2011 20:29 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 6819611E8149 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 13:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.88
X-Spam-Level:
X-Spam-Status: No, score=-9.88 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 oN2U1ktzgiqL for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 13:29:18 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1B211E8092 for <tls@ietf.org>; Wed, 27 Jul 2011 13:29:18 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6RKTG8V007982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 22:29:16 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107272029.p6RKTFNA008101@fs4113.wdf.sap.corp>
To: anders.rundgren@telia.com
Date: Wed, 27 Jul 2011 22:29:15 +0200
In-Reply-To: <4E3067DD.7020209@telia.com> from "Anders Rundgren" at Jul 27, 11 09:32:45 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 20:29:19 -0000
Anders Rundgren wrote: > > > 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. TLS does *NOT* provide any PKI functionality to applications, never did, never will. If you need that, you'll have to newly build it form ground up, potentially re-using existing technologies and protocols (such as PKCS#7/CMS). > > And most of all, how to do it in a such way the the applications > doesn't get affected. That is a non sequitur. "Wash me, but don't get me wet". > > > 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. I'm having serious difficulties to understand what you want, because you constantly intermix two completely distinct things. On the one hand, you talk about application level session management, which has nothing to do with PKI whatsoever. And on the other hand you're talking about using PKI functionality from within the application, which has nothing to do whatsoever with transport-level protection of the communication and Single Sign-On. Just because both, PKI/X.509-based Single Sign-On and application-level use of PKI for digital signatures both use some common pieces of technology (X.509), does not make these to issues fall into an even remotely related problem space. > > 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. In Single Sign-On scenarios, there is _NO_SUCH_THING_ as a server logout with respect to the authentication. The very purpose of Single Sign-On is that the authentication will be automatically performed should that be necessary. What you refer to with "server(-initiated) logout" looks like very misleading terminology to me. Any server that is not operating state-less, can decide at any point in time, at his very own discretion, to forget/flush that backend state. That is completely independent from what any clients do and works even if the network connection of the client breaks down or the client is inadvertently powered off. In pre-HTTP legacy protocols, servers used to keep backend state for as long as the network connection was active. When using connection-less transports, such as performing communication over short-lived request&response HTTP connections, the server needs to come up with some alternative means to determine when to delete/flush backend state associated with particular clients. And seriously, any such replacement backend-state management logic needs to work completely independent of the client's behaviour. Robust traditional client-server scenarios with persistent network connections also had provisions to terminate the network connection on the server end according to locally configured policy (idle timeouts, connection time limits, hours of operation, etc.) and without cooperation from the client. > > > > > 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 ***. If you're doing it _correctly_, it works remarkably smooth. As I've mentioned it before, we've been doing it for like 12 years for all employees and pretty much all intranet server/services. We started out with X.509/PKI-based Single Sign-On for legacy, persistent connection client-server communication with GSS-API based Single Sign-On, and it was natural and straightforward to extend this to TLS CCA for Server/Services accessed through HTTPS. And from the abstraction standpoint, the applications, both legacy and HTTP-based, should NEVER bother whether the transport was connection oriented legacy or HTTPS, and neither should the application bother whether Single Sign-On was provided through X.509 certs (what we prefer and have been using since 1996) or through Kerberos (what some others prefer). btw. certificate enrollment in Browsers hardly works, e.g. Windows 7 was shipped with broken certificate enrollment last bullet "issues fixed" of http://support.microsoft.com/kb/974431 we've been distributing client certs to MSIE through Crypto-API exclusively. For all other browsers, its manual pkcs#12 import. > 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. It is extremely unlikely that banks want Single Sign-On, because that would shift the entire responsibility for fraud on their very own shoulders. Therefore I consider HTTPS CCA completely irrelevant to banks. And anyone who talks about using HTTPS CCA for banks likely has little clue about the technology of TLS and Web Browsers. > > > 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. Using the same cert for Single Sign-On as for transaction based authorization would be braindead and irresponsible. The key usage bits in a certificate become completely meaningless if a certificate is being used for Single Sign-On. Single Sign-On reduces the value of any credential to at most "credential present". Attributing any kind of intent to Single Sign-On authentication is technically and legally impossible. And anyone who claims otherwise lacks technical and legal understanding of the issues. -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