Thanks Alan, But these are more implementation guidance/history then security requirements.
"should configure all settings necessary to perform EAP-TLS in a secure manner" is extremely soft. If we put that in the document it has to be MUST. RFC 5216 has the normative text: "Once a TLS session is established, EAP-TLS peer and server implementations MUST validate that the identities represented in the certificate are appropriate and authorized for use with EAP-TLS." Can we update that to: "Once a TLS session is established, EAP-TLS peer and server implementations MUST validate that the identities represented in the certificate are appropriate and authorized for use with EAP-TLS on the specific link." RFC 3748 use the term link, but I think path or network might also be ok. Unless we can say that, it is very hard to justify the security claim of mutual authentication. Then we would likely have to explain that EAP-TLS only gives some very weak form of authentication. Might also be that the text in quoted text in RFC 5216 is not how things are implemented. An alternative approach would be to check that the certificates are issues by a CA that is exclusively used for EAP-TLS in a specific network and ignore the identities. /John -----Original Message----- From: Alan DeKok <[email protected]> Date: Thursday, 18 February 2021 at 22:39 To: John Mattsson <[email protected]> Cc: EMU WG <[email protected]>, Martin Thomson <[email protected]>, Benjamin Kaduk <[email protected]> Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3 On Feb 18, 2021, at 10:38 AM, Alan DeKok <[email protected]> wrote: > Implementations largely fixed that years ago via a few methods: > > * on initial connection to SSID, prompting the user to see if the certificate > is OK (historical, and less permitted these days) > > * pre-provisioning SSID / CA certificate / user credentials to each machine > > * certificate pinning so that the EAP server certificate is cached and > associated with an SSID / user credentials. i.e. not just the CA cert. This > caching prevents bad actors from getting their own certificate from the same > CA, and setting up their own "mirror" malicious SSID. > > The result is that this works for most situations, and is reasonably secure. Some suggested text, perhaps for Section 5.3, Certificate Validation: There are some proposed additions to the certificate validation text in Section 5.3 of RFC 5216: Experience shows that configuring EAP peers can be difficult and error-prone, especially when that configuration is performed manually by end users. In order to avoid errors and insecure configurations, EAP-TLS peers SHOULD be provisioned via an automated process. This process should configure all settings necessary to perform EAP-TLS in a secure manner, in its expected use-case(s). These settings can include not only the certificate chain from certificate authority to client certificate, but also the expected EAP server certificate. These settings can also include information about the protocol layers above or below EAP (MAC addresses, IP addresses, port numbers, WiFi SSID, etc.). Where these settings cannot be provisioned in an automated manner, the EAP peer SHOULD cache them after first use. The peer SHOULD then present the EAP-TLS credentials only when all of the cached settings match the network being accessed. Where these settings do not match, the EAP peer MAY refuse to proceed with authentication. Where the EAP peer does proceed, it SHOULD inform the end user (where possible) as to the nature of the changes, and give the user the option of proceeding or refusing the authentication. The above recommendations have been in wide-spread use in EAP-TLS peer implementations for many years. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
