On Jan 7, 2020, at 4:10 AM, Mohit Sethi M <mohit.m.se...@ericsson.com> wrote: > 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.
I believe that the recommendations should be stronger. They should also include text explaining why the anonymous NAI is strongly recommended. The above text makes it sound like using opaque blobs for identities is not substantially different from using anonymous NAIs. The reality is that anonymous NAIs are substantially better than opaque blobs. e.g. Anonymous NAIs are routable, opaque blobs are not. Further, "encrypted usernames" MUST be encoded in UTF-8 as printable characters, otherwise they will not be compatible with RADIUS or Diameter. If this document is going to suggest that encrypting identities is OK, then it must explain how to create inter-operable implementations. The reader should be informed as to the pros and cons of each use-case. When the document says "you can do A or B", the reader has no idea *why* one would be chose over the other. The reader has no idea *how* to make that choice. Which means that implementors end up choosing the wrong thing, After going over the possible use-cases, I believe the anonymous NAIs should always be used. The only situation where they're not necessary is where the authentication is known to be site-local. i.e. the EAP supplicant and authenticator are both in the same network. In all other situations, there is no down-side to using anonymous NAIs, and there are major benefits to using them. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
