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

Alan DeKok <aland@deployingradius.com> Wed, 18 September 2019 21:58 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 92223120072; Wed, 18 Sep 2019 14:58:56 -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 Rb3MYe5OpbOr; Wed, 18 Sep 2019 14:58:54 -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 E145B120043; Wed, 18 Sep 2019 14:58:53 -0700 (PDT)
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 B4DC6609; Wed, 18 Sep 2019 21:58:50 +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: <CY4PR1101MB2278103D6B59896837905DC2DB8E0@CY4PR1101MB2278.namprd11.prod.outlook.com>
Date: Wed, 18 Sep 2019 17:58:48 -0400
Cc: John Mattsson <john.mattsson@ericsson.com>, "draft-ietf-emu-eap-tls13@ietf.org" <draft-ietf-emu-eap-tls13@ietf.org>, EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC8ACA1E-D2BE-4E0D-B39A-C105806CA38E@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>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/BoSjRn8DwXE8-lqRR6ePtMNSQnc>
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: Wed, 18 Sep 2019 21:58:56 -0000

On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel) <ofriel@cisco.com> wrote:
> Giving some implementation guidance seems appropriate here. Naively, one could envisage the implementation simply having a DB table for extern PSKs and a table that holds NewSessionTickets. An implementation could simply check the extern PSK table using the PskIdentity.identity, and if no match is found then check the NewSessionTickets table.

  Which works, but should be called out in the draft.

  And what is to prevent the system from generating conflicting PSK identities?  i.e. I don't control OpenSSL.  From what I see, TLS 1.3 resumption means that OpenSSLL will choose whatever PSK identity it deems fit.

  As an implementor and/or admin, how do I choose *pre-provisioned* PSK identities which won't conflict with the ones OpenSSL choose?

> The default OpenSSL NSK ticketId is 32 bytes long https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c8de9/include/openssl/ssl3.h#L127 so something has gone seriously wrong if there is a clash (poor randoms, etc.). 

  i.e. "pick a long string and that should be good enough".

  If that really is the guidance, then this should also be called out in the draft.  PSK identities MUST be long (ideally 32 octets or more), and MUST be generated from a CSPRNG.

  Which then leads to the question of what will the poor user enter in a UI?  If "end users" shouldn't be doing this, the draft also needs to call that out.

> Well, more precisely, the PSK identity is visible in the ClientHello, not the actual PSK of course.

  Sure.

> And the PSK *must not* be a user-manageable string such as the
>> NAI.  On the other hand, if the PSK is sent after encryption begins, then the
>> PSK *should* be a user-manageable string such as an NAI.
> 
> https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> ...
> so TLS-PSK is not suitable for a user entered low entropy password. We need a PAKE for that (c.f. the ongoing CFRG PAKE assessment)

  Sure.

> There are some use cases Eliot and I are looking at related to IoT onboarding where a TLS-PSK authentication has definite value, and we really don't want to see this avenue closed off in EAP.

  I don't know the exact use-case, but TBH I'd suggest EAP-PWD for that.  I'm not sure that EAP-TLS with PSK adds any value here.

  Allowing PSK means that the draft should likely say "end users MUST NOT be using TLS-PSK".  Or maybe "TLS-PSK MUST be used only where systems can be automatically provisioned with long binary data for both PSK identity and PSK itself".  Or even "PSK identities and/or passwords that are composed solely of printable ASCII characters are likely to be humanly entered, and thus insecure".

  Which means, of course, that people will ignore that and demand simple user names / passwords for EAP-TLS with PSK.  Because that's ever so much easier than using nasty certs.

  That isn't something we should encourage.  It may be worth just forbidding it.

  Alan DeKok.