Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

Alan DeKok <aland@deployingradius.com> Fri, 07 May 2021 20: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 415843A3264 for <emu@ietfa.amsl.com>; Fri, 7 May 2021 13:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 T3QjOg8hK09h for <emu@ietfa.amsl.com>; Fri, 7 May 2021 13:48:49 -0700 (PDT)
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 6DF583A325E for <emu@ietf.org>; Fri, 7 May 2021 13:48:48 -0700 (PDT)
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 814781DB; Fri, 7 May 2021 20:48:46 +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.6\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <MW2PR2101MB0923906E4C51058575AD6198D1579@MW2PR2101MB0923.namprd21.prod.outlook.com>
Date: Fri, 7 May 2021 16:48:45 -0400
Cc: Joseph Salowey <joe@salowey.net>, EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF74710A-EA1A-449B-96F8-449721A0CF1A@deployingradius.com>
References: <CAOgPGoBXRAABeC_kCcCrsUPC03e8C_GGpzJHB+aWAue5sE=9zw@mail.gmail.com> <4789411B-9D6A-4A33-B465-DCEC2369E671@deployingradius.com> <MW2PR2101MB0923906E4C51058575AD6198D1579@MW2PR2101MB0923.namprd21.prod.outlook.com>
To: Jorge Vergara <jovergar@microsoft.com>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/glDuWNRZSx0pQJeVBv35V4i4syU>
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
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, 07 May 2021 20:48:51 -0000

On May 7, 2021, at 4:09 PM, Jorge Vergara <jovergar@microsoft.com> wrote:
> The Windows implementation is using draft-13 exporters; it is not possible to change at this point unless a critical technical issue that prevents functionality or impacts security were to be discovered. I don't think this is such an issue. The preference to keep draft-13 exporters was discussed at IETF 110 and I do not recall any objection. The draft-15 exporter is problematic for Windows at this point.

  The interop report involved Microsoft, FreeRADIUS, and hostap.  All have implemented the -13 exporters, and the 0x00 Commitment message.  Interoperablity has been demonstrated to the satisfaction of all participants.

  Pretty much everyone else with supplicant and/or RADIUS server implementations is out of the loop.  They're either unaware of this work, or have no opinions on it.

  From the Open Source side, it's easy to change code.  But I will not ship a product which fails to interoperate with the dominant supplicant platform.

  I see no major security issues with the -13 exporters.  It's "nicer" to use separate labels, but it's not critically important for the security of the protocol.

> I have fewer opinions on the less-technical areas of the draft. One of my flaws as an implementor of several EAP methods is that I can parse the current draft and assume enough intent to complete my implementation. I do call out questions I have - but I sometimes make assumptions without realizing due to prior experience in the area. This may be true of several others in the working group as well. Non-implementors don't have the luxury of this experience and I think it is extremely difficult to create a secure and robust EAP method implementation from scratch. The more guidance toward this goal that can be included in the document the better, in my opinion.

  I agree.

  I have expressed strong opinions that the document gives insufficient guidance to implementors.  For me, "rough consensus and running code" means I should be able to say the following, and be taken seriously:

  "Hi, as someone with running code, I believe that it is critical for the specification to say X, in order to address implementation and interoperability issues".

  It's surprising when the response to such a comment is "No".

  Alan DeKok.