Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Alan DeKok <aland@deployingradius.com> Mon, 04 January 2021 14:08 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7498F3A0D69; Mon, 4 Jan 2021 06:08:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 yLZMY_sxThcI; Mon, 4 Jan 2021 06:08:12 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766563A0D66; Mon, 4 Jan 2021 06:08:12 -0800 (PST)
Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id C3502208; Mon, 4 Jan 2021 14:08:09 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <0f2b05db-5c98-43d4-aae3-cf620814bacc@www.fastmail.com>
Date: Mon, 04 Jan 2021 09:08:07 -0500
Cc: Benjamin Kaduk <kaduk@mit.edu>, tls@ietf.org, emu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4BBA31B-8754-4D8C-B0F1-D1C6C859F6AE@deployingradius.com>
References: <160815821055.25925.15897627611548078426@ietfa.amsl.com> <20201216223842.GR64351@kduck.mit.edu> <0f2b05db-5c98-43d4-aae3-cf620814bacc@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/phfYgy1GSbvbVG2ZdnOTYr8sEAY>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2021 14:08:15 -0000

On Jan 3, 2021, at 10:44 PM, Martin Thomson <mt@lowentropy.net> wrote:
> # Key Schedule
> 
> The other thing I observe is the way that this slices up the exporter output.  This was something that old versions of TLS did, but TLS 1.3 did away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - and should - do the same.  All it means is having more exporter labels.

  That's easy enough to change at this state.  The question is what are those labels?

  And, we're getting very close to needing an implementation soon.  RFC 8446 is over two years old.  Web services have started serious migration to TLS 1.3.  But we still don't even have a standard for EAP.  I suggest that this is an issue.

  At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with the major EAP peer / server implementations.  This code is alpha, and not in any major release.  But we need to decide fairly soon what we're doing, as testing and releases take time.

  The alternative is to dither around for another year or two, all the while relying on legacy TLS versions for 802.1X / WiFi authentication.  i.e. packets which are trivially monitored by anyone with a WiFi card.

> I appreciate that this uses exporters now rather than abusing the internal PRF.  That's good.  The next step is to dispense with the intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS exporter for each of the six values that the protocol requires.  I also note that the 0x0D value is used multiple times, unnecessarily, both as a context strong to the exporter and as a prefix to the session ID.

  If EAP-TLS was the only TLS-based EAP method, I would agree with you.  But it's not.  Historically, each TLS-based EAP method uses it's own key derivations, using method-specific strings.  This practice made implementations more difficult and error-prone.

  The use of 0x0D is to allow standard key derivations across TLS-based EAP methods.  The other methods replaced the 0x0D byte with their own EAP type value.  This practice greatly simplifies implementations.

  See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for more information.

  Alan DeKok.