On Mon, Nov 11, 2019 at 11:41 AM Alan DeKok <al...@deployingradius.com> wrote:
> 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. > > [Joe] I agree that its best to only include the anonymous NAI. Including more information may cause a problem if the PSK works changes in the future or if you are copying the original NAI into subsequent transactions. > > 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. > > [Joe] If its needed then I also think we should include it in the EAP-TLS document. It wouldn't be bad to file an errata on TLS 1.3, but I think this is more of a corner case for them. > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
