Re: [TLS] HTTPS client-certificate-authentication in browsers

Anders Rundgren <anders.rundgren@telia.com> Wed, 27 July 2011 21:03 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 05E8511E8152 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 14:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.566
X-Spam-Level:
X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 iLW1JW2xvPg8 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 14:03:00 -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 C7A7911E814F for <tls@ietf.org>; Wed, 27 Jul 2011 14:02:59 -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 4E305E970000728C; Wed, 27 Jul 2011 23:02:55 +0200
Message-ID: <4E307CF1.60105@telia.com>
Date: Wed, 27 Jul 2011 23:02:41 +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: <201107272029.p6RKTFNA008101@fs4113.wdf.sap.corp>
In-Reply-To: <201107272029.p6RKTFNA008101@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 21:03:01 -0000

Martin,
Lots of banks wants to use CCA for their users.

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.

There are really ugly workarounds but you should not build
secure services based on moderately understood fixes.

That's all.

Anders


On 2011-07-27 22:29, Martin Rex wrote:
> 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
>