[Emu] EAP-TLS 1.3 Section 2.2 text

Joseph Salowey <joe@salowey.net> Mon, 10 May 2021 01:17 UTC

Return-Path: <joe@salowey.net>
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 BA6253A2891 for <emu@ietfa.amsl.com>; Sun, 9 May 2021 18:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IxqIzieKZy0V for <emu@ietfa.amsl.com>; Sun, 9 May 2021 18:17:12 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6623A288B for <emu@ietf.org>; Sun, 9 May 2021 18:17:12 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id x19so20913375lfa.2 for <emu@ietf.org>; Sun, 09 May 2021 18:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+92Bti983s7UyEEKMzsqCA0M8da0Y+QCs8MWMyvmkuw=; b=aCfrAQYn5Mr6liLwRKoN1IcTRdEMY1/+pK+rCT3GAj/xKvd7peNAVNqfYVUhf5uK7P At+JN/o87nuN601OP/sJV41Bixj6/Cu//CFoBIQYGPLJ2GnV8KJjDumjdiWWYUHRsbEB WdJ9/5bTDtdLjrqAAmALwdTqRf4jNrHTCDzhpr5Cbrt60EeoNT4xbkCi2UlA4i5KX7kR tJEgqXP6Bka3RNnWZsV0nHPUX/t9i205Bc18EscUwZ4fwaNicoZU67CYit6M4tWkMYC9 uu3g5EuYrw8hLI3Z1KPAsj1fw+Gsuc+6eauf40lcKKOpZY17fy/VmXALyTDVLkPomlhA 5YyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+92Bti983s7UyEEKMzsqCA0M8da0Y+QCs8MWMyvmkuw=; b=mpPvR4KbDegOSOMPlUkxOi5vU9jM0CwMVPE1NaPJoBl/ZD3yMQcPwXA7H6E/+PBtLP B3TnF1/Iv+838vHkm6QEFpRnNvek2uuFtXeBMh7RnXHD9Ta6Tr56RbXAFiyjFxHJTn/A /WLUjEUyU+2I9wgy5/+ZtoSaATIdjIXldG9CJxQzx9j+nJyPxekAWCtY8uiH8O8l84g4 W697+hgEHpuraxD4CM+SKq/Y9eT11MkYLSjvMdMIElffZse0UXnuN+zDbbTMLc5p6ZSK sPpyHUN1tKGwkN6nOuoaKEr07c1jCy8S4ICRqYnPh+irokogToHfXMW3YkuILqm6nLTZ O5JQ==
X-Gm-Message-State: AOAM532QFXykhqGY2VtpTho59wPBuUWPQE6EeTdpjNF6mccDw+xawPCT nPHPSEidzhaIm2VIgd9KgGDrSQ/i17dyYJ8fJltdBYzhrLaQ8OdA
X-Google-Smtp-Source: ABdhPJwki/GEKDbE6z/hdCg7MSZFgi3ntbJSzsHxMTtNKpoys4sHimIyoDrTZl409Dclv6+pDRWOZT4Uv3dexrewOW0=
X-Received: by 2002:a05:6512:20c5:: with SMTP id u5mr14906016lfr.198.1620609428407; Sun, 09 May 2021 18:17:08 -0700 (PDT)
MIME-Version: 1.0
From: Joseph Salowey <joe@salowey.net>
Date: Sun, 9 May 2021 18:16:55 -0700
Message-ID: <CAOgPGoBDcbDxGB3_Qy_xXymhnxrfMaOPNP545eMh8XLvU6OX+A@mail.gmail.com>
To: EMU WG <emu@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004cd81c05c1ef8956"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/7mBwQM1R-vqZweLxYnXhOx0egzE>
Subject: [Emu] EAP-TLS 1.3 Section 2.2 text
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, 10 May 2021 01:17:18 -0000

Alan's review made the following comments:

>  Section 2.2 has substantial new text which was not previously discussed
on the WG mailing list.

>  The EAP server identity in the TLS server certificate is typically a
>  fully qualified domain name (FQDN).  EAP peer implementations SHOULD
>   allow users to configuring a unique trust root (CA certificate) and a
>   server name to authenticate the server certificate and match the
>   subjectAlternativeName (SAN) extension in the server certificate with
>   the configured server name.

> Comment: How does this text related to RFC 5216 Section 5.2 ?  There
seems to be substantial overlap.

> What does this text add to / change from RFC 5216 Section 5.2 ?

[Joe] It was brought up in discussions that RFC 5216 does not sufficiently
describe how to validate the identity in the certificate.

>  Requiring a supplicant to be configured with a peer name is a new
requirement from RFC 5216, and isn't called out as such.

[Joe]  This can be called out in this section

>  What happens in a high availability (HA) environment?  Are all of the
EAP servers required to have the same FQDN?

[Joe]  This is a good question.  There are multiple ways this could be
addressed.  All servers should have one of their list of SANs that matches
the name used for EAP servers.  Another option is for supplicants to allow
for the configuration of multiple certificates or allow for a wild card
match.   How about this text addition:

"EAP-TLS deployments will often use more than one EAP server.  In this case
each EAP server may have a different certificate.  To facilitate the SAN
matching, EAP Server certificates can include the same name in the list of
SANs for each certificate that represents the EAP-TLS servers.  EAP-TLS
peers SHOULD allow for the configuration of multiple EAP server names since
deployments may choose to use multiple EAP servers each with their own

>  While this text is intended to increase security, there are
implementation and operational considerations which need addressing.

>   In the absence of a user-configured root
>  CA certificate,

> Comment: I'm not sure what that means.  It seems to assume certain things
without explaining them.

[Joe] This text doesn't seem to add much.  I'd suggest removing that

>   The process of configuring a root CA certificate and a server name is
>   non-trivial and therefore automated methods of provisioning are
>   RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
>   a Configuration Assistant Tool (CAT) to automate the configuration
>   process.  In the absence of a trusted root CA certificate (user
>   configured or system-wide), EAP peers MAY implement a trust on first
>   use (TOFU) mechanism where the peer trusts and stores the server
>   certificate during the first connection attempt.  The EAP peer
>   ensures that the server presents the same stored certificate on
>   subsequent interactions.  Use of TOFU mechanism does not allow for
>   the server certificate to change without out-of-band validation of
>   the certificate and is therefore not suitable for many deployments.

>  i.e. when there's an HA configuration.

[Joe] Is your comment about HA and the TOFU mechanism?  I'm not really sure
how the TOFU mechanism is supposed to work and be secure.  Perhaps we
should remove the TOFU mechanism text or state that it does not work well
in all HA configurations (where different servers use different