Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02

From: Alan DeKok <[email-masked]>
Date: Thu, 3 Dec 2020 08:23:20 -0500

> On Nov 21, 2020, at 6:31 PM, Joseph Salowey <[email-masked]> 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=[email-masked])
  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.

---

From: "Eduardo Ingles (UM)" <[email-masked]>
Date: Wed, 9 Dec 2020 11:53:27 +0100

Hi all,

I have worked with EAP-NOOB and implemented a constrained version for 
Contiki (https://github.com/eduingles/coap-eap-noob). I exposed some 
issues on the list such as adding support for P-256 and clarifying the 
text on waiting exchange and the authors have addressed my issues. The 
draft now has P-256 as one of the curves. I support it and I think it is 
ready for publication.

Best regards,
Eduardo Inglés

El 22/11/2020 a las 0:31, Joseph Salowey escribió:
> 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.
>
> Thanks,
>
> Joe
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ 
> <https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/>
>
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

-- 
Eduardo Inglés Sánchez
[email-masked]

Department of Information and Communication Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain

---

From: Aura Tuomas <[email-masked]>
Date: Sun, 13 Dec 2020 20:10:46 +0000

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 <[email-masked]> On Behalf Of Alan DeKok
Sent: torstai 3. joulukuuta 2020 15:23
To: Joseph Salowey <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02
Importance: High

NITs:

  Appendix E says:

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 13 Dec 2020 17:19:56 -0500

> 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…

  That's a better approach, thanks.

  Alan DeKok.