On Nov 7, 2019, at 11:08 PM, Joseph Salowey <j...@salowey.net> wrote: > [Joe] How about > "If an implementation supports an external PSK it MUST provide a way to > configure the realm so it can create an Anonymous NAI to send in the > EAP-Identity response. An EAP-TLS 1.3 implementation MUST NOT copy the > PSK-ID into the EAP-Identity response. "
That's good. > If someone thinks there is a need to allow the PSK-ID to be copied then the > phrase could be extended with " unless there is prior knowledge that this > will have an acceptable impact to privacy and the use case supports Identity > responses that are not in the form of an NAI. ... and the PSK identity is compatible with the requirements of the EAP Identity field, i.e. UTF-8. > [Joe] The TLS 1.3 base spec teats certificate auth and external PSK auth as > mutually exclusive for a particular handshake. I do not think it restricts > a particular server from supporting both external PSK and certificate > authentication for separate connections. OK. I'm back to "how do you tell?" If the document suggests that plain PSK is OK, it would be very useful to describe the impact of that. What does an implementation do? How should administrators tell PSK identities apart? If the EAP authenticator can't control the derivation of PSK identities for resumption, is it even possible to have manually provisioned PSKs? Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
