Re: [TLS] Summarizing identity change discussion so far

Martin Rex <mrex@sap.com> Thu, 17 December 2009 23:47 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF053A6A09 for <tls@core3.amsl.com>; Thu, 17 Dec 2009 15:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.196
X-Spam-Level:
X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTz15C5VeWdk for <tls@core3.amsl.com>; Thu, 17 Dec 2009 15:47:46 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D03723A6A06 for <tls@ietf.org>; Thu, 17 Dec 2009 15:47:45 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBHNlUL9023384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 00:47:30 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912172347.nBHNlT3s026032@fs4113.wdf.sap.corp>
To: mrex@sap.com
Date: Fri, 18 Dec 2009 00:47:29 +0100
In-Reply-To: <200912172145.nBHLjDUT018568@fs4113.wdf.sap.corp> from "Martin Rex" at Dec 17, 9 10:45:13 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Summarizing identity change discussion so far
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Thu, 17 Dec 2009 23:47:47 -0000

Martin Rex wrote:
> 
> Maybe we should at least mention one valid reason for why a certificate
> may change in the Security Considerations: certificate update/renewal.
> 
> There were two scenarios mentioned where this seems to be a
> regular use case IIRC.  Was it gaming where they were using quite
> short-lived certificates and then XMPP, where they were using
> quite long-lived connections?


Thinking about the "valid reason" scenarios for certificate change,
I'm slightly concerned about a potential disconnect between the
original and the later certificates if the application designer
is a little sloppy.

If a design expects certificate renewal to be necessary
(either short lived-certs or long-lived connections) then it is
imperative that the application performs a full re-authentication
when the identity changes during renegotiation.
A simple certificate path validation could in some situations
subvert a limited-time access restriction.


Normally, you will need a specific certificate for initial authentication,
because it is used for some kind of app-level logon-operation
or ACL-check.  When a renegotiation needs to be performed because of
the expiration of the users cert, and the app does _not_ re-do the
authentication logon/ACL-check, but relies blindly on the
certificate path validation, then the user could simply use
an entirely different certificate with a longer validity during
renegotiation, succeed certificate path validation and keep
using the resource beyond the expiration of the original
access credential/certificate.


-Martin