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. > > 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.
The current text already says this in 2.1.7: "EAP-TLS peer and server implementations supporting TLS 1.3 or higher MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username in cleartext in the Identity Response. It is RECOMMENDED to use anonymous NAIs, but other privacy-friendly identities (e.g. encrypted usernames) MAY be used." While identities MAY be derived from the certificate, they can also be configured by the user. As a co-author, I don't think we should over-prescribe only one way of doing it. --Mohit > > 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
