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.

  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 

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 

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

Reply via email to