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

[Joseph Salowey <[e-mail]>]

On Fri, Nov 1, 2019 at 4:08 AM Alan DeKok <[e-mail]> wrote:

> On Nov 1, 2019, at 6:15 AM, John Mattsson <[e-mail]>
> 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.
>
>   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.
>
>
[Joe] Do implementations use the whole common name or just the domain
portion.  Using the whole common name is not advisable with TLS 1.3.


> 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.
>

[Joe]  Is EAP Identity Synonymous with the NAI?


> ---
>
>   Alan DeKok.
>
>