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 (Anders Rundgren)
Date: Wed, 27 Jul 2011 22:29:15 +0200 (MEST)
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