Re: [Emu] draft-aura-eap-noob-08 NAI

2020-04-24 Thread Mohit Sethi M
Hi Eliot,

On 4/24/20 4:22 PM, Eliot Lear wrote:

Hi Mohit



On 24 Apr 2020, at 15:02, Mohit Sethi M 

 wrote:

Hi Max,

Tuomas can give you a definite answer. My understanding is that error
1001 should be sent by the server if the received identity does not
follow the requirements of draft-aura-eap-noob. Besides, implementing
the stricter checks of this draft is easier than validating the ABNF of
RFC7542 (after which you would anyways need to verify compliance with
this draft).

And you are right. The absence of server-assigned realm in Figure 2 is
probably an editorial oversight. However, I wouldn't call the optional
server assigned realm as RESERVED_DOMAIN. If anything, I would call
eap-noob.net as a reserved/special use domain.



There are all manner of reasons not to use eap-noob.net.  I think we talked to 
the IAB about this at some point and they were comfortable with something in 
.ARPA, but we’d need to reconfirm.  This is a small matter that should be 
cleared up with a few email exchanges.

Absolutely. Using something in .arpa makes perfect sense. But until that is 
allocated, implementations need a temporary placeholder. The current text in 
section 3.3.1 of the draft even says 
(https://tools.ietf.org/html/draft-aura-eap-noob-08#section-3.3.1):

The default realm for the peer is "eap-noob.net" (.arpa domain TBA).

--Mohit



Eliot
___
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] draft-aura-eap-noob-08 NAI

2020-04-24 Thread Eliot Lear
Hi Mohit

> On 24 Apr 2020, at 15:02, Mohit Sethi M 
>  wrote:
> 
> Hi Max,
> 
> Tuomas can give you a definite answer. My understanding is that error 
> 1001 should be sent by the server if the received identity does not 
> follow the requirements of draft-aura-eap-noob. Besides, implementing 
> the stricter checks of this draft is easier than validating the ABNF of 
> RFC7542 (after which you would anyways need to verify compliance with 
> this draft).
> 
> And you are right. The absence of server-assigned realm in Figure 2 is 
> probably an editorial oversight. However, I wouldn't call the optional 
> server assigned realm as RESERVED_DOMAIN. If anything, I would call 
> eap-noob.net as a reserved/special use domain.

There are all manner of reasons not to use eap-noob.net.  I think we talked to 
the IAB about this at some point and they were comfortable with something in 
.ARPA, but we’d need to reconfirm.  This is a small matter that should be 
cleared up with a few email exchanges.

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


Re: [Emu] draft-aura-eap-noob-08 NAI

2020-04-24 Thread Mohit Sethi M
Hi Max,

Tuomas can give you a definite answer. My understanding is that error 
1001 should be sent by the server if the received identity does not 
follow the requirements of draft-aura-eap-noob. Besides, implementing 
the stricter checks of this draft is easier than validating the ABNF of 
RFC7542 (after which you would anyways need to verify compliance with 
this draft).

And you are right. The absence of server-assigned realm in Figure 2 is 
probably an editorial oversight. However, I wouldn't call the optional 
server assigned realm as RESERVED_DOMAIN. If anything, I would call 
eap-noob.net as a reserved/special use domain.

--Mohit

On 4/22/20 12:29 PM, Max Crone wrote:
> While implementing EAP-NOOB, I found the explanation on the Invalid 
> NAI (error code 1001) in the draft to be unclear.
>
> The document formulates it as follows:
> >   If the NAI structure is invalid, the server SHOULD send the error
> >   code 1001 to the peer.
>
> However, does this mean that the EAP-NOOB server should verify that 
> the NAI follows the formal syntax as specified in RFC 7542, or should 
> it verify that the NAI follows the specification of EAP-NOOB, i.e., it 
> is of the form "noob@{eap-noob.net||RESERVED_DOMAIN}". I think this 
> section could be formulated more clearly to address these concerns.
>
> On that note, Figure 2 seems to be incomplete. The 
> EAP-Response/Identity specifies the NAI parameter to be 
> "n...@eap-noob.net", while the specification also has the option of 
> configuring this to a reserved domain. In that case, the NAI should 
> not use the default realm anymore. Currently, this is not reflected in 
> the figure.
>
> If anything remains unclear, I am open for discussion.
>
> ~Max Crone
>
> ___
> 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] Poll for virtual interim

2020-04-24 Thread Mohit Sethi M
Dear all,

Reminder: please respond to the poll for a potential virtual interim in 
May: https://doodle.com/poll/vxy5vc4g3cnegpdr

Joe and Mohit

On 4/20/20 2:11 AM, Mohit Sethi M wrote:
> Dear all,
>
> We did not have a face-to-face meeting in Vancouver for IETF 107. At
> this point, the IETF 108 meeting in Madrid is also uncertain.
>
> We are therefore considering a virtual interim meeting for EMU during
> middle/end of May 2020. Here are some proposed dates and time slots:
> https://doodle.com/poll/vxy5vc4g3cnegpdr
>
> Please indicate your availability!
>
> Joe and Mohit
>
> ___
> 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 Call For adoption of draft-aura-eap-noob-08.txt

2020-04-24 Thread Aleksi Peltonen
I support adoption of this draft. I have verified previous versions of 
the protocol with both mCRL2 (safety and liveness properties) and 
ProVerif (security properties). I am planning on updating the models as 
the specification evolves after adoption.


- Aleksi

On 18/04/2020 23:13, Joseph Salowey wrote:
This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a 
working group item.  This draft has been discussed in several IETF 
meetings and would be the starting point for the working group 
deliverable for an EAP method based on "mutual authentication between 
a peer and a server that is based on an out-of-band channel."  Please 
review the draft and indicate whether you support adoption or not by 
May 4, 2020.

Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-aura-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