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

Alan DeKok <aland@deployingradius.com> Thu, 12 September 2019 15:27 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 994B4120041; Thu, 12 Sep 2019 08:27:58 -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 tn30MKICMSJO; Thu, 12 Sep 2019 08:27:56 -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 490CD120876; Thu, 12 Sep 2019 08:27:56 -0700 (PDT)
Received: from [192.168.20.47] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id 9864D619; Thu, 12 Sep 2019 15:27:53 +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: <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com>
Date: Thu, 12 Sep 2019 11:27:51 -0400
Cc: Aura Tuomas <tuomas.aura@aalto.fi>, EMU WG <emu@ietf.org>, "draft-ietf-emu-eap-tls13@ietf.org" <draft-ietf-emu-eap-tls13@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <246280B8-6E5C-484B-95BD-9C940C98C507@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>
To: John Mattsson <john.mattsson@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/bkNJDv2qvcpsFdZ_3v4aleHwMEg>
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, 12 Sep 2019 15:27:59 -0000

On Sep 12, 2019, at 10:55 AM, John Mattsson <john.mattsson@ericsson.com> wrote:
> 
>>     See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we *cannot* use PSK for >authentication in EAP-TLS.
> 
> I don't understand why this could not be done. My view is that allowing PSK authentication would be quite easy.

  How would systems tell the difference between "raw" PSK and "resumption" PSK?

  When allowing resumption, the server has sent a PSK identity in a NewSessionTicket message.  The client caches this and re-uses this.  But the client signals that it is performing resumption via the act of using PSK.  There's nothing else.

  Which means that if PSK was allowed, the server can't look at the packets to distinguish resumption from "raw" PSK.  Instead, the server has to look at it's resumption cache which may be in a DB.

>>> While there is the EAP-PSK method, I would much rather use EAP-TLS with PSK because it >provides identity protection and perfect forward secrecy, unlike EAP-PSK. 
>> 
>>     Use EAP-PWD for that.
> 
> Standardizing EAP-TLS should only be done if it has some significant advantages over EAP-PWD, and there are people wanting to implement and use it. 3GPP is e.g. adding  identity protection and perfect forward secrecy to EAP-AKA instead.

  I would prefer to forbid PSK in EAP-TLS. 

  Alan DeKok.