On Mar 9, 2020, at 9:03 AM, John Mattsson <[email protected]> wrote: > > Thanks for you many good suggestions. I tried to address all your comments > and include all your suggestions in a recent commit to github. > > - I did not include an identity section as I did not see how it would fit > with the structure of RFC 5216 that the draft reuses. Instead I expanded the > identity sections in the resumption and privacy sections and added a new > paragraph on identity in Section 2.1. This aligns well with RFC 5216.
It's possible to update the document format. When the RADEXT WG did RFC 7542 (NAI), the entire layout was re-done. My reasons for wanting a separate section on identities is that it's important, and many people get it wrong. Calling it out in a separate section shows people that identities are important *independent* of resumption, protocol negotiation, certificates, etc > - The text on encrypted usernames (like 3GPP SUCI) where updated to > illustrate that they are intended to be NAIs, not opaque blobs. Thanks. > - I added an explanation on how to derive a anonymous NAI from a NAI in the > certificate subject name. I did not want to talk about common name as the > certificate may contain a subjectAltName which is not common name (I think). Sure. > 2.1. Overview of the EAP-TLS Conversation > > ... > > It is RECOMMENDED to use a NAIs in the Identity Response [RFC7542] as > such identities are routable. While opaque blobs are allowed by > [RFC3748] such identities are NOT RECOMMENDED as they are not > routable and should only be considered in local deployments where the > EAP Peer, EAP authenticator, and EAP Server all belong to the same > network. An anonymous NAIs MAY be derived from the subject name in > the TLS client certificate by removing the username from a NAI. *which* NAI? Perhaps: When certificates use NAIs for the subject name, an anonymous NAI SHOULD be derived from the subject name by removing the username portion. > The > subject name in client certificates typically contains an identity > with a routable domain such as an email address. The email address may not be routable. Perhaps: The subject name in client certificates typically contains an identity such as an email address, which is already in the NAI format. > 2.1.6. Resumption > > ... > > It is RECOMMENDED to use a 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. What happens when this recommendation isn't followed? Without explanation, such recommendations convey little information to the reader. i.e. if this recommendation is not followed, then in practice, resumption is likely to be impossible. And perhaps re-iterate "It is RECOMMENDED to use the same anonymous NAI in the resumption, as was used in the original full authentication" > The TLS PSK identity is typically derived be the TLS > implementation and may be an opaque blob without a routable realm. > The TLS PSK identity is therefore in general unsuitable for deriving > a NAI to use in the Identity Response. OK. > 2.1.7. Privacy > > ... > > 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. Following [RFC7542], > it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but > other constructions such as a fixed username (e.g. anonymous@realm) > or an encrypted username (e.g. YmVuZGVy@realm) are allowed. Note > that the NAI MUST be a UTF-8 string as defined by the grammar in > Section 2.2 of [RFC7542]. That looks good, thanks. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
