Alan, thank you for your review! We had not thought about the collisions of uft8-username within the realm. After some discussion, the best solution seemst to be to let the server assign a full NAI instead of just the Realm. This is the only significant change made to the new draft 3.
Tuomas -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok Sent: torstai 3. joulukuuta 2020 15:23 To: Joseph Salowey <j...@salowey.net> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02 Importance: High > On Nov 21, 2020, at 6:31 PM, Joseph Salowey <j...@salowey.net> wrote: > > At IETF 109 meeting there was support for moving EAP-NOOB forward. The > chairs and authors believe the document is ready to progress so this starts > the working group last call for EAP-NOOB [1]. Please review the document > and send comments to the list by December 11, 2020. Statements of support or > opposition are welcome especially if accompanied with reasons for the > position. I support publication of this document. NITs: Section 3.3.1 says "The default realm for the peer is "eap-noob.arpa". But the diagram in 3.2.1 has: (NAI=n...@eap-noob.net) I suggest using "arpa" instead of "net". Section 3.3.1 says "The peer MUST copy the PeerId byte-by- byte from the message where it was allocated, and the server MUST perform a byte-by-byte comparison" It's a little odd to talk about "byte-by-byte". Perhaps just "copy the PeerID", and "the server must verify that the PeerID exactly matches ..." Section 3.3.1 also discusses a "server-assigned realm". But there seems to be no guidance on which realm to use. Since this specification also mandates the use of a particular utf8-username "noob", there is a potential conflict with existing users. It may be useful to suggest the use of a sub-realm, specifically used for EAP-NOOB, e.g. "noob.example.net". Allowing a sub-realm for noob means that administrators can select an otherwise unused realm, and assign it specifically for use with EAP-NOOB. That can cause issues with roaming, however. Roaming systems match on realms, and may not always be capable of matching on variants of realms. So if they allow "example.net", they may not be capable of processing "noob.example.net". RFC 7542 Section 3 "Routing inside of AAA Systems" is silent on this topic, while Eduroam allows sub-realms. My suggestion is that the document should recommend the use of noob-specific sub-realms, and then admit that this might cause issues in some roaming environments. That trade-off is acceptable, I think. Most roaming systems which cannot handle sub-realms will likely not be using EAP-NOOB. Appendix E says: PeerId is provided to the peer by the server and might be a 22-character ASCII string. I think it's best to just refer to Section 3.3.1, for the format of the PeerId. And then note that the construction in Section 3.3.1 is compatible with HTTP, and does not require escaping. 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
