Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

On Mon, Nov 11, 2019 at 11:41 AM Alan DeKok <aland@deployingradius.com>
wrote:

> On Nov 11, 2019, at 12:52 PM, Owen Friel (ofriel) <ofriel@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
>