Re: [TLS] Implementation survey: Client Certificate URL extension

pgut001@cs.auckland.ac.nz (Peter Gutmann) Fri, 04 April 2008 05:42 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08C93A69CB; Thu, 3 Apr 2008 22:42:36 -0700 (PDT)
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 EBFB83A69CB for <tls@core3.amsl.com>; Thu, 3 Apr 2008 22:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9HX+-nIQwH4j for <tls@core3.amsl.com>; Thu, 3 Apr 2008 22:42:35 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id F13BA3A67AC for <tls@ietf.org>; Thu, 3 Apr 2008 22:42:34 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6EAB24808A6; Fri, 4 Apr 2008 18:42:38 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5HIk8W-r5Mx; Fri, 4 Apr 2008 18:42:38 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 556EA4808A3; Fri, 4 Apr 2008 18:42:38 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D84AE19EC0B9; Fri, 4 Apr 2008 18:42:31 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1Jheh5-0007lu-O7; Fri, 04 Apr 2008 18:42:31 +1300
From: pgut001@cs.auckland.ac.nz
To: martin.rex@sap.com
In-Reply-To: <200804031610.m33GAJ6V004192@fs4113.wdf.sap.corp>
Message-Id: <E1Jheh5-0007lu-O7@wintermute01.cs.auckland.ac.nz>
Date: Fri, 04 Apr 2008 18:42:31 +1300
Cc: tls@ietf.org
Subject: Re: [TLS] Implementation survey: Client Certificate URL extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Martin Rex <Martin.Rex@sap.com> writes:

>Although this Papers describes a serious design flaw in the rfc3280
>suggestion to put URLs of intermediate CAs into X.509v3 cert extensions and
>have peers use them in order to be able to build a certification path, the
>very same problem will apply to every concept that a communication peer can
>be coerced to access one or more arbitrary URLs prior to authentication, and
>the Client Certificate URL extension appears to suffer the same
>vulnerabilities and security problems.

This has been known for a long time, and is even worse in protocols like OCSP
where you can use this facility to scan and penetrate corporate networks, use
machines as attack amplifiers, and so on.  The PKIX response in the past has
been "not our problem".

I don't know if the TLS WG wants to make it their problem or not.  It's always
seemed a very obvious flaw, my code deliberately doesn't support any of these
"turn a host into an attacker-controlled proxy" extensions.

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls