On Jan 16, 2023, at 7:57 PM, Joseph Salowey <[email protected]> wrote: > [Joe] The authority-ID was meant to be sent from the server to the client so > the client could choose the right PAC to use to establish the session with > the server. I don't think there is an equivalent for TLS tickets, so perhaps > it could be useful in this case. However, since it only applies to PAC, I > would suggest that it shares the fate of the PAC text unless there is a need > for it. A mechanism can be added later if the need arises.
I agree. A TLS server usually identifies itself to a client by providing a server certificate. Which makes me wonder a bit what's supposed to happen with TLS-PSK in general. Is the client supposed to just randomly send a PSK and hope for the best? This looks like an oversight in TLS. We're not going to fix that in EMU, but it is a concern for me. > [Joe] I can imagine use cases where TLS-PSK is used to establish a tunnel > for the initial provisioning of credentials, but it might be good to limit > its use until a need is explicitly defined. Off of the top of my head, a device could use TLS-PSK, MAC and/or serial # as the PSK for initial bootstrapping. But until there's more thought put into that, I wouldn't want to propose anything. I think I'll add a note about TLS-PSK, and suggest that it's possible, but not implemented, and therefore no analysis has been done of it. Using TLS-PSK with TEAP is NOT RECOMMENDED until a deeper analysis and use-cases have been done. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
