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

Martin Rex <mrex@sap.com> Wed, 27 July 2011 18:34 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 982ED11E8123 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 11:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.719
X-Spam-Level:
X-Spam-Status: No, score=-9.719 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, 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 HZhRczxk3J68 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 11:34:45 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CAE2D11E8084 for <tls@ietf.org>; Wed, 27 Jul 2011 11:34:44 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6RIYgDT016976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 20:34:42 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107271834.p6RIYfjB001802@fs4113.wdf.sap.corp>
To: anders.rundgren@telia.com (Anders Rundgren)
Date: Wed, 27 Jul 2011 20:34:41 +0200 (MEST)
In-Reply-To: <4E2FC9F3.10205@telia.com> from "Anders Rundgren" at Jul 27, 11 10:18:59 am
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 18:34:45 -0000

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.

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.

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.

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).

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.


> 
> 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.
It has _NOTHING_ to do with digital signatures and can not be used
to authorize individual transactions.


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.


-Martin