Re: [Emu] EAP-TLS 1.3 Section 2.2 text
Joseph Salowey <joe@salowey.net> Sun, 16 May 2021 00:22 UTC
Return-Path: <joe@salowey.net>
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 664B83A21F4 for <emu@ietfa.amsl.com>; Sat, 15 May 2021 17:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdfzweZV07vq for <emu@ietfa.amsl.com>; Sat, 15 May 2021 17:22:13 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 A1B343A21F5 for <emu@ietf.org>; Sat, 15 May 2021 17:22:12 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id p20so2880068ljj.8 for <emu@ietf.org>; Sat, 15 May 2021 17:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3EGrcp8lNP70dtM6PsgvL6Dxhe95FcHYM2yfXwpF02w=; b=hu6tWhx+Mp/lJzhEQgbVOd7ndycMnzTxBO28aBHn89mW8qyDxD5r2z1OFzj48Ykq0v +ZcVme/hFnE/dXGB8Kb9M63Kq4KHIKieLeRF/OQUj3ehVR4M5RAd1YqS6Wyo8BhbQ10a lP2Wz2wWjN4dZjYl5ARc4bahgckQ+RjmZkigmw2oQARIoeuTuzkVSjor9Y27BwBYhrIi ZYFEQuYp13qS9s9nQi+rAHzfBLrFNChryJMEEHUsDlX2vYDXlaGzhIJv+fU5jPuodHDS 4bIm3Bq0D7pE12O6kxYyhQ9nNfRkSzfzdEBPc2sjfMB69m8v12UXSS+1xC7+p2RHUjPu Idlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3EGrcp8lNP70dtM6PsgvL6Dxhe95FcHYM2yfXwpF02w=; b=NudZUCgJpXGprvqvPCNeZR3IZbn+IFe3Lg0hv+4xwZZdJ2uyQtf9o7TuPruNHKN0ge joX52Hu+LGTzR3gTOmWPStLJyThzqPHZkVYyVE92rJt0xW5INCQfv8RIQTVxRZqsgzQq RwcGyRzkYS2aNwoD7VZ67R98G+WF8pKAx2YKOLHmLx/4tXgkrUgxRHjcRtKVUp6SZ5Rj NWDf+C3Qx7NfCSWgfevd+yAKy8rcnpvfaUPqNyOmOQNe8MYoIowbrAtZyfLQZtAmNC0R MMXXgB2bNdGups73G8zE/acihe8DScX3mx8fLT+vPvjzfnjozjJVnsV5xrfxzfjqET4z R28Q==
X-Gm-Message-State: AOAM533SSljTAVsRQ/pRq3PYiymCjFtCy5hE9S2F6Vld0YxtgS55OdEW 9UUQZB4KX48dIfSEQhxjRGXy4ry7V/+xOxPoO/87KA==
X-Google-Smtp-Source: ABdhPJzMC96oQgwcgZJKkA3cinmcSEYOtLIDXtqvByr8qfWgPRaTfBzP95fdVzJn48eSnrrldZ+C3tHn9YNsj7eYpeA=
X-Received: by 2002:a2e:8e21:: with SMTP id r1mr42996962ljk.166.1621124529424; Sat, 15 May 2021 17:22:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAOgPGoBDcbDxGB3_Qy_xXymhnxrfMaOPNP545eMh8XLvU6OX+A@mail.gmail.com> <92D9824F-82C2-440F-807F-7B4799DCF1B6@deployingradius.com>
In-Reply-To: <92D9824F-82C2-440F-807F-7B4799DCF1B6@deployingradius.com>
From: Joseph Salowey <joe@salowey.net>
Date: Sat, 15 May 2021 17:21:58 -0700
Message-ID: <CAOgPGoAd3CcaqPYd0aYXBDtCmv32T8hpGH+6ysEn7Pi9M+FSiw@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: EMU WG <emu@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b69a4705c26777ab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/Bp9CWk7sBf1c4735Me13aF3_8g4>
Subject: Re: [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: Sun, 16 May 2021 00:22:19 -0000
I proposed a PR#72 <https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/72> based on this suggestion. The resulting text for the section is below. Please review to see if it is OK. Thanks, Joe 2.2. Identity Verification This section updates Section 2.2 of [RFC5216]. The EAP peer identity provided in the EAP-Response/Identity is not authenticated by EAP-TLS. Unauthenticated information SHALL NOT be used for accounting purposes or to give authorization. The authenticator and the EAP-TLS server MAY examine the identity presented in EAP-Response/Identity for purposes such as routing and EAP method selection. EAP-TLS servers MAY reject conversations if the identity does not match their policy. Note that this also applies to resumption, see Sections 2.1.3, 5.6, and 5.7. The EAP server identity in the TLS server certificate is typically a fully qualified domain name (FQDN). EAP peer implementations SHOULD allow users to configure 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. EAP-TLS deployments will often use more than one EAP server. In this case each EAP server may have a different certificate. To facilitate 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 certificate. If server name matching is not used, then peers may end up trusting servers for EAP authentication that are not intended to be EAP servers for the network. If name matching is not used with a public root CA, then effectively any server can obtain a certificate which will be trusted for EAP authentication by the Peer. 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 a 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 including ones where multiple EAP servers are deployed for high availability. On Mon, May 10, 2021 at 5:11 AM Alan DeKok <aland@deployingradius.com> wrote: > On May 9, 2021, at 9:16 PM, Joseph Salowey <joe@salowey.net> wrote: > > [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. > > FWIW, wpa_supplicant has a list of allowed host names for SAN. I don't > think it allows wildcards. > > > 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 > certificate." > > That's good. > > > [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 > certificates) > > Perhaps just state that it does not work well in HA configurations. > > I don't think TOFU can be secure here. > > Alan DeKok. > >
- [Emu] EAP-TLS 1.3 Section 2.2 text Joseph Salowey
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Alan DeKok
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Joseph Salowey
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Alan DeKok
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Eliot Lear
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Russ Housley
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Oleg Pekar
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Oleg Pekar
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Alan DeKok
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Joseph Salowey
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Joseph Salowey
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Alan DeKok
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Heikki Vatiainen
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text Oleg Pekar
- Re: [Emu] EAP-TLS 1.3 Section 2.2 text John Mattsson