Re: [TLS] Summarizing identity change discussion so far

Martin Rex <mrex@sap.com> Fri, 18 December 2009 19:16 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 6821E3A6806 for <tls@core3.amsl.com>; Fri, 18 Dec 2009 11:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.197
X-Spam-Level:
X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, 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 kWPzAVKb9gyt for <tls@core3.amsl.com>; Fri, 18 Dec 2009 11:16:51 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 361B03A67F1 for <tls@ietf.org>; Fri, 18 Dec 2009 11:16:50 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBIJGYfl004996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 20:16:34 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912181916.nBIJGXap003912@fs4113.wdf.sap.corp>
To: aerowolf@gmail.com
Date: Fri, 18 Dec 2009 20:16:33 +0100
In-Reply-To: <6b9359640912171745k3be3d9a9je84a449fd998dab0@mail.gmail.com> from "Kyle Hamilton" at Dec 17, 9 05:45:38 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: Fri, 18 Dec 2009 19:16:52 -0000

Kyle Hamilton wrote:
> 
> On Thu, Dec 17, 2009 at 5:31 PM, Martin Rex <mrex@sap.com> wrote:
> > The application was able to perform the initial authentication
> > (log-on or ACL-check), so it is the duty of the application to
> > perform any reauthentication in the very same fashion when
> > renegotiation results in a different cert(chain).  Everything
> > else will result in endless pain.
> >
> >
> > ...and that is a reason why personally, I prefer that the necessity
> > for cert renewal requires a new connection and full initial handshake--
> > because that is exaclty the code path which has all of the
> > functionality and checks that we are looking for!
> 
> I do agree with you there.  Unless the saved session mechanism also
> triggers the functionality and checks that a full handshake would, but
> I think that's too much to hope for.

This could be another potential security problem for an application.

If the certficate path validation is only triggered during full
handshakes (because it is somehow chained into the processing
of the Certficate handshake message in a Callback-style),
then a TLS implementation of TLS session resume might skip
the certificate path validation (still providing the original
certificate to the application), and the application might
perform only the mapping (log-on, ACL-check) while assuming that
the certificate path validation was automatically provided
by the TLS implementation.

In theory, TLS sessions get purged from the server-side session
cache at some point in time, so the that the problem could be
temporary.  But depending on how the session cache
expiration is implemented (based on time-of-creation vs.
last-recently-used), there might be a possibility for a client
to "touch" the cached session regularly, so that it will not
be expired from a session cache that operates on last-recently-used,
which may allow the client to skip certificate-path-validation
(which would mean that expiration and revocation might be
 ignored for as long as the client can keep the session in
 the servers session cache).

-Martin