On Jul 3, 2023, at 3:04 PM, Eliot Lear <l...@lear.ch> wrote: >> Eliot notes that you can't renew a client certificate in EAP-TLS. >> Therefore, there may be good reason to use TEAP in "client certificate only" >> mode. > > I'll just add that the current TEAP support in wpa_supplicant supports just > this case.
It's technically fine. IIRC the "SHOULD NOT" is just that it doesn't make much sense to replicate EAP-TLS in another EAP type. However, if the functionality is not the same, then there is good reason behaviour similar to EAP-TLS. > I would suggest that we provide some guidance, but perhaps not normative. > The reason is that RFC 7170 states that the Trusted-Server-Root TLV may > return a list of certs, and it may be in some cases to provision multiple > root certificates. That having been said, the text in that section is not as > clear as it could be with regard to the purpose of those other certs. In an > enterprise environment, it may be broadly desirable to inform an IOT device > of a trust anchor within the enterprise. On the other hand, if the device is > a collaboration device or some other human oriented system, that advice taken > blindly may lead to exposing communications on a personal system. > > In short, my suggestion is to add some text in Security Considerations, and > some text suggesting that the primary use be for EAP authentication and > renewal, and that other uses should be considered carefully by clients. This > might also lead to an EKU discussion, and that might be something we want to > address here. OK. I've already issued -07. I'll try to do some word-smithing around the subject, and issue -08 later this week. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
