Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

<oscar.koeroo@kpn.com> Tue, 19 November 2013 11:26 UTC

Return-Path: <oscar.koeroo@kpn.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7DD1ADF10 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnt5-MB8SAfg for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:26:37 -0800 (PST)
Received: from Mail3.kpnnet.org (mail3.kpnnet.org [192.58.226.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5534A1ADF24 for <tls@ietf.org>; Tue, 19 Nov 2013 03:26:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,729,1378850400"; d="scan'208";a="73843850"
Received: from w2006.kpnnl.local ([10.75.81.4]) by Mail3.kpnnet.org with ESMTP; 19 Nov 2013 12:25:25 +0100
Received: from W2053.kpnnl.local ([10.75.81.1]) by W2006.kpnnl.local ([10.75.81.4]) with mapi; Tue, 19 Nov 2013 12:15:14 +0100
From: <oscar.koeroo@kpn.com>
To: <skyper@thc.org>, <dharkins@lounge.org>
Date: Tue, 19 Nov 2013 12:15:13 +0100
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-pwd
Thread-Index: Ac7lEwK2Wn3s649oRYiwCgfqLr7CiAABJtcA
Message-ID: <D4318E7AF8480146A18F382CB1E64DBD15A20C0009@W2053.kpnnl.local>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com> <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net> <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
In-Reply-To: <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
Accept-Language: en-US, nl-NL
Content-Language: nl-NL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, nl-NL
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/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: Tue, 19 Nov 2013 11:26:40 -0000

May I add that it's not clear which elements are to be presented to the user for visual (or automated) inspection and in which form. I can handle long random string for visual inspection, but I wonder if this is to be expected from all users. If I've understood the spec correctly the fingerprint of the public key and the domain names, i.e. the subject alt names, are to be presented to the user. This could turn out to be quite a bit of data per certificate.

Also, if the fingerprint is tied to public key exclusively I wonder what the UAs are expected to do when subject alt names have changed in the certificates when the public key is preserved.


Oscar Koeroo
Red Team / Ethical Hacker
Chief Information Security Office
KPN
Tel: +31 6 1217 5278
Fingerprint: 3D5F 5BA5 AF84 BBE1 3D60 8621 0DCD 74C3 A211 B654


Van: TLS [mailto:tls-bounces@ietf.org] Namens Ralf Skyper Kaiser
Verzonden: dinsdag 19 november 2013 11:16
Aan: Dan Harkins
CC: tls@ietf.org
Onderwerp: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

Hi Dan,
The security risk lies within the implementation.

The capable client will always offer TLS-PWD. 

Simplified, this is how pinning will be implemented: The client receives the server's certificate. The client checks if the server's certificate (or better the SPKI) is already known to the client (e.g. pinned) and if the server's certificate is different to the pinned certificate then the connection fails.
The draft assumes that certificate based server authentication is the only authentication that exists.
The draft does not discuss the scenario where TLS-PWD is used.
In such a case I'm concerned that the part of the client source code that checks for pinning is not triggered and by-passed. The client goes into the TLS-PWD mode.

Instead what should be pinned is the SPKI _and_ that certificate based server-authentication must be used. E.g. once a client has pinned a certificate for a host it should not allow TLS-PWD.
This is obvious to us but not obvious to the developer and should be explicitly mentioned.
(It could be mentioned in websec-rfc as you say but that's beyond draft status and additions are no longer practical). Mentioning it in the TLS-PWD draft will hopefully prevent an insecure implementation.

regards,

Ralf


On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <dharkins@lounge.org> wrote:

  Hi Ralf,

On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:
> Hi,
>
> could not find it in the draft:
>
> the interoperability with draft-ietf-websec-key-pinning-08 should be
> mentioned explicitly to prevent
> an attack scenario. (e.g. user has pinned certificate for google.com.
> Attacker MITM forces
> client to do tls-pwd. Client should not allow this). E.g. once a host is
> pinned no other server-side
> auth mechanism should be allowed.
  If the client doesn't want to do TLS-pwd then it won't include the
mandatory extension in its client hello and it won't include any TLS-pwd
ciphersuites. I don't see how this attack happens.

  Perhaps the necessary requirements to deal with pinning certificates
for websec should be dealt with in the draft you mention.

  regards,

  Dan.