IETF Logo Mail Archive

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

Alan DeKok <aland@deployingradius.com> Fri, 08 November 2019 12:43 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 4F97C120120 for <emu@ietfa.amsl.com>; Fri, 8 Nov 2019 04:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no 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 i_ORUY3Cb3le for <emu@ietfa.amsl.com>; Fri, 8 Nov 2019 04:43:30 -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 B7028120118 for <emu@ietf.org>; Fri, 8 Nov 2019 04:43:30 -0800 (PST)
Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 9AB0B1A40; Fri, 8 Nov 2019 12:43:27 +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: <CAOgPGoDMkMUCbdY6WL+StR22d2qkq87ycGQbVUncExYW_+-8Tg@mail.gmail.com>
Date: Fri, 08 Nov 2019 07:43:25 -0500
Cc: EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FF842AE-0FA8-40EA-9A82-672E3068EBAB@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> <0D21C6F3-DCF7-41FA-BEFB-9408575524A8@deployingradius.com> <CAOgPGoDMkMUCbdY6WL+StR22d2qkq87ycGQbVUncExYW_+-8Tg@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/RhZ9sEwgQGLbuSdQxoSkSIaVvGQ>
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: Fri, 08 Nov 2019 12:43:32 -0000

On Nov 7, 2019, at 11:08 PM, Joseph Salowey <joe@salowey.net> wrote:
> [Joe] How about 
> "If an implementation supports an external PSK it MUST provide a way to configure the realm so it can create an Anonymous NAI to send in the EAP-Identity response.  An EAP-TLS 1.3  implementation MUST NOT copy the PSK-ID into the EAP-Identity response. "

  That's good.

> If someone thinks there is a need to allow the PSK-ID to be copied then the phrase could be extended with " unless there is prior knowledge that this will have an acceptable impact to privacy and the use case supports Identity responses that are not in the form of an NAI.  

  ... and the PSK identity is compatible with the requirements of the EAP Identity field, i.e. UTF-8.

> [Joe] The TLS 1.3 base spec teats certificate auth and external PSK auth as mutually exclusive for a particular handshake.   I do not think it restricts a particular server from supporting both external PSK and certificate authentication for separate connections.  

  OK.  I'm back to "how do you tell?"

  If the document suggests that plain PSK is OK, it would be very useful to describe the impact of that.  What does an implementation do?  How should administrators tell PSK identities apart?  If the EAP authenticator can't control the derivation of PSK identities for resumption, is it even possible to have manually provisioned PSKs?

  Alan DeKok.

v2.23.0 | Report a Bug | By Email