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

Alan DeKok <aland@deployingradius.com> Mon, 17 May 2021 12:53 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 993CC3A36D3 for <emu@ietfa.amsl.com>; Mon, 17 May 2021 05:53:19 -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 mjfcIM_Lp0-d for <emu@ietfa.amsl.com>; Mon, 17 May 2021 05:53:14 -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 58FBE3A36D1 for <emu@ietf.org>; Mon, 17 May 2021 05:53:14 -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 7B53EB7; Mon, 17 May 2021 12:53:12 +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: <CAOgPGoDFMKRzm40byZSAU6-Q3FEXiBQAwuqQtd-cRJE8O1+FGA@mail.gmail.com>
Date: Mon, 17 May 2021 08:53:11 -0400
Cc: EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7F8ED82-9F12-460D-8731-BF3D55035293@deployingradius.com>
References: <CAOgPGoBXRAABeC_kCcCrsUPC03e8C_GGpzJHB+aWAue5sE=9zw@mail.gmail.com> <4789411B-9D6A-4A33-B465-DCEC2369E671@deployingradius.com> <CAOgPGoDFMKRzm40byZSAU6-Q3FEXiBQAwuqQtd-cRJE8O1+FGA@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/xhnHJkGA3SkXzIreLDX1U6lJPOE>
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: Mon, 17 May 2021 12:53:20 -0000

On May 16, 2021, at 2:30 PM, Joseph Salowey <joe@salowey.net> wrote:
> This is under-stating the issue rather severely.  We know with
> absolute certainty that most (if not all) EAP implementations and
> access networks limit the number of EAP packet exchanges.  Perhaps
> update the text to reference implementation and interoperability
> experience.
> 
> [Joe] Is there a paper that should be referenced?

  No papers that I recall.  But source code to hostap and FreeRADIUS is publicly available.  I've previously posted stable links to specific revisions of the source, for both projects.

> Section 5.1 says:
> 
>   [4] Cryptographic Negotiation: TLS 1.3 increases the number of
>   cryptographic parameters that are negotiated in the handshake.  When
>   EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
>   negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
>   groups, and signature algorithm, see Section 4.1.1 of [RFC8446].
> 
> Question: what does this mean in practice for EAP-TLS?  i.e. this text
> describes a capability.  It does not describe what that capability
> does, or how it benefits EAP-TLS.
> 
> [Joe] Although this is an internal TLS detail I don't see any problem discussing this in the security considerations. 

  I don't see it's a problem, but I don't know why it's there.  Should the EAP-TLS document discuss all of the properties of TLS?  If not, then perhaps a subset?  And which subset to pick?

  As an implementor, anything which is explicitly called out in the document should be there for a reason.  i.e. to guide implementors.  So reading the above text leads me to conclude that the text is important.  But there are no actionable items coming from that text.  No recommendations, and no further discussion.

  And the first sentence is truncated from a grammatical sense:  "TLS increases..." as compared to what?

  Perhaps it's simpler to just say:

 [4] Cryptographic Negotiation: Compared to earlier versions, TLS 1.3 increases the number of
 cryptographic parameters which are negotiated in the handshake.  When
 EAP-TLS is used with TLS 1.3, EAP-TLS inherits all of the increased capabilities of TLS.  See Section 4.1.1 of [RFC8446] for more information.

> [Joe]  How about 
> 
> "When peer authentication is not used, deployments
>    MUST take care that the resulting access granted by AAA servers and network authenticators is appropriate for
>    unauthenticated peers."

  Yes.

  Alan DeKok.