Hi Alan, 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. - The text on encrypted usernames (like 3GPP SUCI) where updated to illustrate that they are intended to be NAIs, not opaque blobs. - 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). The new suggested paragraphs on identities are shown below. The resumption and privacy section only talks about details specific for resumption and privacy. Cheers, John ---------------------------------- 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. The subject name in client certificates typically contains an identity with a routable domain such as an email address. 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. 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. 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]. ---------------------------------- _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
