On Nov 11, 2019, at 12:52 PM, Owen Friel (ofriel) <ofr...@cisco.com> wrote: > > [ofriel] Is the primary reason they MUST NOT be copied because of encoding > differences? UTF-8 vs. TLS raw bytes?
Yes. EAP Identities are UTF-8 encoded strings. Non-compliant identities will likely result in the packet being dropped. > On the privacy aspect, as the TLS PSK ID is sent unprotected and unencrypted > in cleartext in the ClientHello, what information leakage are we preventing > by not sending that same data in cleartext in the Identity Response? Not much. Except that if we send the data in the Identity, it MUST be encoded in some format which is acceptable to EAP, RADIUS, etc. Further, RFC 8446 says that PSK Identities can be be up to 2^16-1 octets in length. While EAP can carry large identities, RADIUS cannot. So we're left with a practical limitation of ~250 octets for the identity field. At that point, it's best to recommend that the EAP Identity carry only an anonymous NAI. That avoids the issue of PSK length and encoding entirely. Further, it means that all uses of EAP-TLS have the same recommendation: the Identity is an anonymous NAI. > This is a different question to the difference between an extern PSK and a > resumption PSK. That is implementation specific and not defined in TLS1.3 i.e. "good luck". :( It's difficult for implementors to do the right thing in such a situation. > [ofriel] I agree some implementation advice would be good here. Should this > be in EAP, or should we push for a TLS1.3 errata? It's the same advice that a > standard TLS1.3 server implementor needs. OpenSSL for example defines its own > resumption format, and provides a callback hook to check for extern PSKs, and > it looks like OpenSSL lets the application check for an extern PSK match > first before checking its internal resumption cache: > https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093. > But of course that is TLS stack specific. We would need to document guidance > olong the lines of checking for TLS stack behaviour. I think it's best to give guidance in this document. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
