Hi Alan, On 12/28/19 3:29 PM, Alan DeKok wrote: > On Dec 27, 2019, at 1:54 PM,internet-dra...@ietf.org wrote: >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08 > Which adds some text about identities: > > It is RECOMMENDED to use anonymous NAIs with the same realm in > the > resumption and the original full authentication. This requirement > allows EAP packets to be routable to the same destination as the > original full authentication. > > That's good, thanks. I still would prefer some additional text as I had > suggested. The text explains related issues in more detail: > > 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.
Is there a case when the PSK identity is not derived by the underlying TLS implementation? And perhaps you meant to say that it cannot be controlled by the EAP peer (rather than the EAP authenticator)? --Mohit > I find it's easier for people to follow recommendations when they have a > full picture of the pros and cons of the choices being recommended. > > For the original authentication: > > Anonymous NAIs MAY be derived from > the client certificate used in TLS. Client certificates typically > contains an identity with a routable domain such as an email address. > > How is this derivation done? Many things "may" be done, but that doesn't > help guide *why* or *how* things are done. > > If there's no clear guidance possible, then that should be said, too. > > I also believe that the document should also RECOMMEND that the > EAP-Response/Identity be in the form of an anonymous NAI. > > I would prefer to have a separate section about identities. I find the > current text a bit unclear. It helps to explain why an anonymized NAI is > useful, even when there is no email address in a certificate. > > 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
