IETF Logo Mail Archive

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

Alan DeKok <aland@deployingradius.com> Thu, 07 November 2019 17:48 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 E87071209A9; Thu, 7 Nov 2019 09:48:19 -0800 (PST)
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 LXooHsQNlJ6X; Thu, 7 Nov 2019 09:48:18 -0800 (PST)
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 1E1A112098A; Thu, 7 Nov 2019 09:48:18 -0800 (PST)
Received: from [192.168.20.137] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id E111A1946; Thu, 7 Nov 2019 17:48:15 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <MN2PR11MB390137BA293101102515A3AFDB780@MN2PR11MB3901.namprd11.prod.outlook.com>
Date: Thu, 07 Nov 2019 12:48:14 -0500
Cc: Joseph Salowey <joe@salowey.net>, "draft-ietf-emu-eap-tls13@ietf.org" <draft-ietf-emu-eap-tls13@ietf.org>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, Michael Richardson <mcr@sandelman.ca>, EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D21C6F3-DCF7-41FA-BEFB-9408575524A8@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> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <CAOgPGoBko6N_JebmisoSk_EJ=Hq21sV3xoXjLw4r7D+OFSsdZA@mail.gmail.com> <CC58A292-03D6-4D70-A11F-B8FEE7311E78@cisco.com> <26738.1570791861@dooku.sandelman.ca> <AD799A14-8268-4BAF-8925-3567973C7507@cisco.com> <9501.1570802988@dooku.sandelman.ca> <DCC85780-B079-4AD0-8870-7528270B70D8@cisco.com> <CAOgPGoA0RCY+J5bDOyUiKtFy5Vk=C11yvE8O=rsJPQeS8Fzk0A@mail.gmail.com> <B31BF8C4-6568-49F2-BBD1-BD6AC66D393C@cisco.com> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <CAOgPGoCAb6hbWfPLLGDXAv80Grxn1vTTxOzLctx4E+R0ZhBvGg@mail.gmail.com> <MN2PR11MB390137BA293101102515A3AFDB780@MN2PR11MB3901.namprd11.prod.outlook.com>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/D6wz4OAd6ks0opeEk77rUkvh1L8>
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, 07 Nov 2019 17:48:20 -0000

On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel) <ofriel@cisco.com> wrote:
> [ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously. draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I don't think TLS with extern PSK is really intended for Web/Browser HTTPS connections. Its more for devices/things which are preprovisioned with the extern PSK.

  Then the EAP-TLS document should disallow it, too.  If TLS 1.3 doesn't support it, I don't see how something built on top of TLS 1.3 can support it.

> In TLS1.3, by design the protocol does not differentiate between resumption and external PSKs, and says nothing about PSK ID format, as commented here https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 , https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc 

  Which is fine.  I'm happy to have PSKs be anything.  The caveat is that we then MUST forbid the PSKs from being copied to the EAP Identity field.  So the EAP-TLS document has to make a recommendation.

> And its application specific how the two are differentiated, the spec says nothing about it: https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o
> 
> I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3. Surely it should be an EAP server implementation decision on whether to support that feature or not, but we should not preclude a specific EAP server implementation from supporting extern PSK by disallowing it in the spec. If a particular EAP server does not want to support extern PSK - that’s fine.

  Then we need to give guidance on what implementors and administrators should do.  Even if it means adding text saying "you can do certs OR PSK, but NOT BOTH".

  Alan DeKok.

v2.23.0 | Report a Bug | By Email