[Emu] Minor PR on eap-tls13

Alan DeKok <aland@deployingradius.com> Tue, 22 June 2021 13:02 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 929D23A2445 for <emu@ietfa.amsl.com>; Tue, 22 Jun 2021 06:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SkBNuTMLsPzh for <emu@ietfa.amsl.com>; Tue, 22 Jun 2021 06:02:41 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4AC3A2442 for <emu@ietf.org>; Tue, 22 Jun 2021 06:02:40 -0700 (PDT)
Received: from [] (24-52-251-6.cable.teksavvy.com []) by mail.networkradius.com (Postfix) with ESMTPSA id 805C4113 for <emu@ietf.org>; Tue, 22 Jun 2021 13:02:38 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
From: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <784048A1-DFF5-4D84-8468-9A8C97C0DEA7@deployingradius.com>
Date: Tue, 22 Jun 2021 09:02:36 -0400
To: EMU WG <emu@ietf.org>
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/QRQsG1HZDabLVFu5E-SHVz2_nek>
Subject: [Emu] Minor PR on 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: Tue, 22 Jun 2021 13:02:45 -0000


  I didn't see anything on cross-protocol use of certs.

  i.e. Section 2.2 suggests that the certs contain an FQDN.  But it's likely bad practice to allow the same cert to be used for EAP, and for WWW.

  There's some suggested text forbidding this behavior.

  I would have expected similar text to be part of RFC 8446, but I couldn't find anything relevant.


5.11 Certificate Reuse

Certificates used for EAP-TLS MUST NOT be used in any other protocol besides EAP. Section 2.2 above suggests that certificates typically have one or more FQDNs in the SAN extension. However, those fields are for EAP validation only, and do not indicate that the certificates are suitable for use on WWW (or other) protocol server on the named host.

Allowing the same certificate to be used in multiple protocols would possibly allow for an attacker to authenticate via one protocol, and then "resume" that session in another protocol. Section 5.7 above suggests that authorization rules should be re-applied on resumption, but does not mandate this behavior. As a result, this cross-protocol resumption could allow the attacker to bypass authorization policies, and toobtain undesired access to secured systems. The simplest way to prevent this attack is to forbid the use of the same certificate across multiple protocols.