Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Alan DeKok <aland@deployingradius.com> Thu, 19 September 2019 13:39 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C277120025; Thu, 19 Sep 2019 06:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 mfUAJk5txpgk; Thu, 19 Sep 2019 06:39:23 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFBC120058; Thu, 19 Sep 2019 06:39:23 -0700 (PDT)
Received: from [192.168.20.61] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id 75845CE; Thu, 19 Sep 2019 13:39:21 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <008b01d56eb3$5c51e550$14f5aff0$@augustcellars.com>
Date: Thu, 19 Sep 2019 09:39:20 -0400
Cc: "Owen Friel (ofriel)" <ofriel@cisco.com>, draft-ietf-emu-eap-tls13@ietf.org, EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE49E199-E8CF-42EE-9832-C7BE2AF24652@deployingradius.com>
References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <CY4PR1101MB22781AB8C8982ACF99B61544DB8E0@CY4PR1101MB2278.namprd11.prod.outlook.com> <DAE24683-2B66-40F1-AFC6-77250113B204@deployingradius.com> <1FD26215-86AF-4C64-83ED-AB1D67D1937B@ericsson.com> <DB61AD67-77D5-4EF9-9207-4CD20C3B61C7@deployingradius.com> <CY4PR1101MB2278103D6B59896837905DC2DB8E0@CY4PR1101MB2278.namprd11.prod.outlook.com> <BC8ACA1E-D2BE-4E0D-B39A-C105806CA38E@deployingradius.com> <008b01d56eb3$5c51e550$14f5aff0$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/jmBHdO6JsymjN53jAtyagFdcAKQ>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 13:39:25 -0000

On Sep 19, 2019, at 2:27 AM, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> I am going to come down on the side of no PSK should not be supported.
> However my issues have nothing to do with how things are implemented and
> more to do with the security properties of the EAP method.

  I'm leaning that way myself.  I'm not opposed in principle, but it looks like other options have better properties.

> When you use certificates, there is no leakage of who the client is as this
> is encrypted by TLS.  When you use a restore session ticket, it is possible
> to limit the number of times that the ticket can be used (for example once).
> The PSK identity is public and unprotected so it can be used to track.  If
> one is using PSK for the purpose of authentication then that value will
> always be visible to intermediate parties for the purpose of tracking.
> This can be slightly mitigated by using restore session tickets with PSK,
> but you are going to send that PSK identifier over the wire many times.

  i.e. the only secure way to use PSK is one-time authentication, as per Owen's IoT use-case.

  If we do allow it, there's just no question that people will abuse it.  That for me is a strong reason to forbid it.

  Alan DeKok.