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