On Apr 12, 2021, at 2:15 PM, Tim Cappalli <tim.cappa...@microsoft.com> wrote: > > Pinning the server certificate is unrealistic. A properly configured > supplicant with a trusted private root and subject match is adequate and > allows good security hygiene with server cert rotation.
While I agree, many customers don't. The only way to convince them otherwise is to present a "fait accompli" that all of the vendors now forbid this behaviour. > I believe the id-kp-eapOverLAN EKU should be a MUST. I think we can't use it. It's defined for client certs. We don't want client certs to pretend to be server certs. Using id-kp-eapOverLAN for both will allow this. > Public CAs should not be issuing server certificates for EAP in the first > place. I feel like this debate comes up every few years. Any public CA-signed > TLS web server certificate that is used for EAP can be requested to be > revoked for misuse. Replace EAP with EAP, SMTPS, XMPP, etc. i.e. any protocol using TLS. There was a long thread about this on EMU a year ago. Maybe it is the case that certificate authorities MUST revoke such mis-used certs. If so, I could write a script which would scan the net, find such certs, and report them. I suspect that it could take down 10% to 25% of TLS-enabled services. Is this a good idea? Probably not. Is it possible? According to multiple people, yes. What should we do about it? I don't know. But my $0.02 is that if it is true, then we should admit that the real-world use-cases for certs don't match how certificate authorities work. We should then likely change the definition of "id-kp-serverAuth" to mean "any TLS-enabled service", instead of "TLS WWW servers". > If an organization cannot ensure proper configuration of a supplicant, they > should not be using EAP. Or, they should rely on experts to ensure that systems can't be configured incorrectly. This is where the IETF has spent two decades not addressing these use-cases. Given the time frame for the EAP-TLS document, I suspect it's best to just say "here be dragons", and leave it at that. Any attempt to define new behavior may be time consuming. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
