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