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

2020-12-13 Thread Aura Tuomas 
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  On Behalf Of Alan DeKok
Sent: torstai 3. joulukuuta 2020 15:23
To: Joseph Salowey 
Cc: EMU WG 
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  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

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

2020-12-09 Thread Eduardo Ingles (UM) 

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/ 




___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


--
Eduardo Inglés Sánchez
eduardo.ing...@um.es

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

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

2020-12-03 Thread Alan DeKok 



> On Nov 21, 2020, at 6:31 PM, Joseph Salowey  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

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

2020-12-03 Thread Dan Garcia 

Hello all,

I have read the draft and I think it is useful tool to have within the 
EAP framework. I support its publication.


Regards,
Dan

El 03/12/2020 a las 9:22, Aleksi Peltonen escribió:


I think the draft is ready. I was involved in the formal modeling of 
the protocol with both ProVerif and mCRL2. All issues discovered from 
the modeling phase have been addressed in the current draft. I am also 
working on modeling other protocols, including EAP methods, and will 
share my results when they are published.


Best regards,
Aleksi

On 22/11/2020 01:31, Joseph Salowey 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.


Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ 




___
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
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

2020-12-03 Thread Aleksi Peltonen 
I think the draft is ready. I was involved in the formal modeling of the 
protocol with both ProVerif and mCRL2. All issues discovered from the 
modeling phase have been addressed in the current draft. I am also 
working on modeling other protocols, including EAP methods, and will 
share my results when they are published.


Best regards,
Aleksi

On 22/11/2020 01:31, Joseph Salowey 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.


Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/


___
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

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

2020-11-21 Thread Joseph Salowey 
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/
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu