Nit: RFC 5280 (see Section 4.2.1.6) talks about the subject alternative name extension, which as an ASN.1 definition for SubjectAltName. So, please do not refer to subjectAlternativeName.
Russ > On May 15, 2021, at 8:21 PM, Joseph Salowey <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>> wrote: > On May 9, 2021, at 9:16 PM, Joseph Salowey <[email protected] > <mailto:[email protected]>> 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 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
