I think that's good. > On May 25, 2021, at 12:45 AM, Joseph Salowey <[email protected]> wrote: > > I made some changes to the pull request to address some of the comments and > make the text clearer: > > The EAP peer identity provided in the EAP-Response/Identity is not > authenticated by EAP-TLS. Unauthenticated information MUST 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) in the SubjectAltName (SAN) > extension. Since EAP-TLS deployments may use more than one EAP > server, each with a different certificate, EAP peer implementations > SHOULD allow for the configuration of a unique trusted root (CA > certificate) to authenticate the server certificate and one or more > server names to match against the SubjectAltName (SAN) extension in > the server certificate. To simplify name matching, an EAP-TLS > deployment can assign a name to represent an authorized EAP server > and EAP Server certificates can include this name in the list of SANs > for each certificate that represents an EAP-TLS server. 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 Thu, May 20, 2021 at 10:23 PM Joseph Salowey <[email protected]> wrote: > > > On Wed, May 19, 2021 at 5:58 AM Alan DeKok <[email protected]> wrote: > On May 19, 2021, at 8:37 AM, Oleg Pekar <[email protected]> wrote: > > After thinking a bit more about it - for the sake of the client > > implementation clarity, would it be better if we provide the strict > > algorithm for server identity check or maybe reference RFC 6125. > > Given the time frame and what we know, I think the existing text is OK. > > > [Joe] In addition the intent of the text is to make implementers aware of the > issues and provide some guidance as to how to solve the problem. I don't > think we can dictate too much more at this point. We can have follow-on > work to have a strict algorithm is depolyers and implementers feel it is > necessary. > > This is what wpa_supplicant does in it's implementation, and it seems to > work fine. Apple appears to do the same thing: > > https://opensource.apple.com/source/eap8021x/eap8021x-264.30.3/EAP8021X.fproj/EAPTLSUtil.c.auto.html > > Look for "trusted_server_names", which leads to: > > https://opensource.apple.com/source/eap8021x/eap8021x-156/EAP8021X.fproj/EAPTLSUtil.c > > server_name_matches_server_names() > > Which checks if the name from the cert is an exact match for one of the > "trusted_server_names", or contains "*." followed by a suffix which is one of > the trusted server names. > > I think it's past the time where this document can ask supplicants to > change their behavior. We know what the supplicants do, it's not wrong, and > it seems to work. So let's document that, and move on. > > Alan DeKok. >
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
