On Jan 17, 2020, at 5:19 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > } c) supplicants do not check DNS names or any other field in the > certificates > } d) as a result of this lack of verification, supplicants ship with all > known > } CAs disabled for TLS-based EAP methods"
For (d), CAs are disabled also because of protocols like EAP-TTLS with embedded PAP. If the supplicant trusted a root CA, then it would trust any certificate signed by that CA, and expose the users clear-text password to anyone. Supplicants now check: * for a named SSID * the CA is manually enabled for that SSID * the server certificate is known (pre-configured or downloaded and cached) All of those conditions have to be met before EAP is performed. > [c] is a problem that we partly want to fix. Yes. > Let's go back to the start with goals and requirements. > > 0) there is nothing broken with manual provisioning of private CAs to be used > in Enterprise-WPA (EAP-TLS, etc.) uses of EAP/802.1X. This can continue > as is. The server certificate needs to have id-kp-serverAuth OID set in > order to be trustable by comododity clients as deployed today. > There is very little use of additional OIDs, even those some have been > defined. > Clients do not insist upon them, and *as a result*, it is technically > possible to use certificates issued by public CAs here. Yes. I've omitted BSRKI comments. I have less to contribute there > So, it seems that we ought to: > a) suggest that EAP-TLS (and EAP-TEAP) clients should include the DN > (rfc822Name) of the certificate that they should be talking to. I'm not clear on "include". > b) we should perhaps have an OID extension in the CA certificate (trust > anchor) that says if the CA will use the id-kp-eapOverLAN bit or not. > (or other extensions) > If so, then the client should insist that the resulting extension be > present. > Maybe there is another way to do this that would be easier, but this > makes sense to me. There may be other ways. Taken to the extreme, each use-case for TLS should have its own OID. I don't know that there's a good solution here. On a related note, Stefan Winter had a proposal for a standard configuration for EAP: https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-02 That would seem to solve all of the provisioning problem. There are still verification problems. I suspect we need to clearly separate the two situations, i.e.: 1) a supplicant magically has the information it needs to authenticate. What does that information look like? What's in the certs? 2) a supplicant is unconfigured, how is it possible to get the supplicant to state (1) above? Is the information available in state (1) helpful for provisioning? Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
