> -----Original Message-----
> From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok
> Sent: 01 November 2019 11:08
> To: John Mattsson <john.matts...@ericsson.com>
> Cc: draft-ietf-emu-eap-tl...@ietf.org; Michael Richardson
> <m...@sandelman.ca>; John Mattsson
> <john.mattsson=40ericsson....@dmarc.ietf.org>; EMU WG <emu@ietf.org>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> On Nov 1, 2019, at 6:15 AM, John Mattsson <john.matts...@ericsson.com>
> wrote:
> > I strongly support working group adoption of draft-dekok-emu-tls-eap-types.
> Can we make sure to get this document going, I agree that this is a very 
> needed
> draft. I think it should include updates for everything people wants to use. 
> I do
> not think draft-ietf-emu-eap-tls13 strictly have to wait for 
> draft-dekok-emu-tls-
> eap-types, but draft-dekok-emu-tls-eap-types should be published shortly 
> after.
>   I will do an update to my document shortly.

[ofriel] Question to the WG: should the TEAP changes for TLS1.3 be included in 
draft-dekok-emu-tls-eap-types? Or in draft-lear-eap-teap-brski - and note that 
the title is changed to " TEAP Update and Extensions for Bootstrapping "? Or 
potentially both? Eliot, Nancy and I had planned on adding TLS1.3 updates to 
draft-lear-eap-teap-brski, but haven't got it done yet.

>   I also added an issue with the EAP-TLS document on GitHub.  The suggestion 
> is
> to add text which explains how (and why) the EAP Identity is chosen during
> resumption:
> ---
> The EAP Identity used in resumption SHOULD be the same EAP Identity as was
> used during the original authentication. This requirement allows EAP packets 
> to
> be routable through an AAA infrastructure to the same destination as the
> original authentication.
> The alternative is to derive the EAP Identity from the identity used inside 
> of TLS.
> This derivation is common practice when using certificates, and works because
> the "common name" field in the certificate is typically compatible with EAP, 
> and
> it contains a routable identifier such as an email address. This practice 
> cannot be
> used for resumption, as the PSK identity may be a binary blob, and it might 
> not
> contain a routable realm as suggested by RFC 7542.
> In some cases, the PSK identity is derived by the underlying TLS 
> implementation,
> and cannot be controlled by the EAP authenticator. These limitations make the
> PSK identity unsuitable for use as the EAP Identity.
> ---
>   Alan DeKok.
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

Emu mailing list

Reply via email to