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
- [TLS] Summarizing identity change discussion so f… Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] Summarizing identity change discussion … Stephen Farrell
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Eric Rescorla
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Stefan Santesson
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Michael Gray
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- [TLS] OpenPGP Certs for TLS [was: Re: Summarizing… Daniel Kahn Gillmor
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Kyle Hamilton
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … Peter Saint-Andre
- Re: [TLS] Summarizing identity change discussion … David-Sarah Hopwood
- Re: [TLS] Summarizing identity change discussion … Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] Summarizing identity change discussion … Marsh Ray
- Re: [TLS] Summarizing identity change discussion … Joseph Salowey (jsalowey)
- Re: [TLS] Summarizing identity change discussion … Stephen Farrell
- Re: [TLS] Summarizing identity change discussion … Martin Rex
- Re: [TLS] Summarizing identity change discussion … Nelson B Bolyard
- Re: [TLS] Summarizing identity change discussion … Nasko Oskov
- Re: [TLS] Summarizing identity change discussion … David-Sarah Hopwood
- Re: [TLS] Summarizing identity change discussion … David-Sarah Hopwood
- Re: [TLS] Summarizing identity change discussion … Joseph Salowey (jsalowey)
- Re: [TLS] Summarizing identity change discussion … Pasi.Eronen
- Re: [TLS] Summarizing identity change discussion … Joseph Salowey (jsalowey)