> -----Original Message-----
> From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok
> Sent: 08 November 2019 12:43
> To: Joseph Salowey <j...@salowey.net>
> Cc: EMU WG <emu@ietf.org>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>
> 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.
[ofriel] Is the primary reason they MUST NOT be copied because of encoding
differences? UTF-8 vs. TLS raw bytes?
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?
Note that TLS1.3 PSK IDs are different to TLS1.3 client certs: PSK IDs are sent
in cleartext in the ClientHello, client certs are sent encrypted inside the
client's second flight. PSK IDs are not protected, client certs are (assuming
of course that the client can validate the server identity when the server
sends its first flight to the client).
>
> > 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.
[ofriel] Right.
>
> OK. I'm back to "how do you tell?"
[ofriel] You can of course trivially tell the difference between an extern PSK
and a cert based auth - the ClientHellos are different.
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
>
> 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?
[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.
>
> 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
