Subject: Re: [Emu] Questions about EAP-NOOB

From: Aura Tuomas <[email-masked]>
Date: Wed, 6 Mar 2019 12:23:30 +0000

Hi Dan and Rafa,

Thank you for the questions!

Yes, the Initial Exchange in EAP-NOOB always ends in EAP-Failure.  Then, we give some time for the user to transfer the OOB message. After the OOB step, the peer tries again and the Completion Exchange ends in EAP-Success.

Yes, the out-of-band (OOB) message is cryptographically bound to the ECHD result. That, is the message authentication code (Hoob) in the OOB message takes the ECDH output as one of its inputs.

Our current implementation opportunistically tries all the W-Fi network that support WPA2-Enterprise. It definitely would be better to advertise the capability for EAP-NOOB in IEEE 802.11u, or even advertise the domain of the EAP-NOOB server. I think it will take some time before the 802.11 APs start to support EAP-NOOB in that way, though, and we want the protocol to work with existing Wi-Fi networks.

The realm used by the peer is initially “eap-noob.net”. The server can assign another realm in Initial Exchange. The main purpose for assigning another realm is that the peer can later use it for roaming in access networks that have AAA routing set up for the assigned realm.

We have only tested EAP-NOOB on Wi-Fi: https://github.com/tuomaura/eap-noob. It can be used on any networks that support EAP and where the user-assisted OOB authentication methods makes sense from the user experience perspective.

Regards,
Tuomas

From: Emu <[email-masked]> On Behalf Of Dan Garcia
Sent: Monday, 28 January, 2019 13:39
To: [email-masked]
Subject: [Emu] Questions about EAP-NOOB
Importance: High

Dear Toumas, Mohit,

We have been discussing EAP NOOB draft we would like to ask some questions about it. It is a very interesting approach related to IoT.

In EAP-NOOB as first step the EAP authenticator starts the authenction (e.g. the AP), eap-noob happens but it seems there will be a EAP failure , is this correct?
Assuming it is, if you send an EAP failure, will the EAP method still continue? How would this work? Since we are waiting, we assume, from an EAP success, or an alternative way of confirmation that the authentication has been completed.

It seems that the user gets something from the IoT device this something is due to the ECDH, right?

Regarding the discovery of the EAP authenticator. The AP should announce what are the available domains to where it is connected ( a solution based on the AAA infraestructure ?) Could this information be provided to the AP using IEEE 802.11u?

Related to this, what would be the realm provided by the EAP peer to the authenticator?

Another question would be which are the main radio technologies where EAP NOOB is expected to be used. Are you planning to support 802.15.4, WIFI, etc? In this line, do you have any EAP-NOOB implementation in Contiki?

Thank you in advance.
Best Regards.
Dan and Rafa.

--
=================================================================

Dan Garcia Carrillo, Ph.D.
Doctorado Industrial (MINECO)
E-mail: [email-masked]<mailto:[email-masked]>

Odin Solutions, S.L.
Polígono Industrial Oeste
C/ Perú, 5, 3º, Oficina 12
30820 - Alcantarilla (Murcia) - Spain
Tlf.: +34 902 570 121
Web: www.odins.es<http://www.odins.es>
=================================================================

AVISO LEGAL: La información contenida en este correo electrónico, y en su caso en los documentos adjuntos, es información privilegiada para uso exclusivo de la persona y/o personas a las que va dirigido. No está permitido el acceso a este mensaje a cualquier otra persona distinta a los indicados. Si usted no es uno de los destinatarios, cualquier duplicación, reproducción, distribución, así como cualquier uso de la información contenida en él o cualquiera otra acción u omisión tomada en relación con el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor notifíquelo al remitente y proceda a la eliminación de este correo electrónico, así como de sus adjuntos si los hubiere.

Asimismo, y en cumplimiento de Ley Orgánica 3/2018 de protección de datos de carácter personal y garantía de los derechos digitales y del Reglamento Europeo RGPD 679/2016 le informamos que sus datos están siendo objeto de tratamiento por parte de ODIN SOLUTIONS, S.L. con N.I.F. B-73.845.893, con la finalidad del mantenimiento y gestión de relaciones comerciales y administrativas. La base jurídica del tratamiento es el cumplimiento de la legislación fiscal, mercantil y contable. No se prevén cesiones y/o transferencias internacionales de datos. Para ejercitar sus derechos puede dirigirse a ODIN SOLUTIONS, S.L., domiciliada en C/ Perú, 5, 3º, Oficina 12, Pol. Ind. Oeste, 30820 Alcantarilla (Murcia), o bien por E-mail a [email-masked]<mailto:[email-masked]>, con el fin de ejercer sus derechos de acceso, rectificación, supresión (derecho al olvido), limitación de tratamiento, portabilidad de los datos, oposición, y a no ser objeto de decisiones automatizadas, indicando como Asunto: ·Derechos Ley Protección de Datos·, y adjuntando fotocopia de su D.N.I.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 6 Mar 2019 07:45:01 -0500

> The realm used by the peer is initially “eap-noob.net”. The server can assign another realm in Initial Exchange. The main purpose for assigning another realm is that the peer can later use it for r…

  This is fine for an initial draft.  I'd avoid implementing anything that uses "eap-noob.net", though.

  The correct domain to use is .arpa:

   https://www.iana.org/domains/arpa

  The controlling document here is RFC 3172.

  It looks like EAP-TEAP-BRSKI requires a similar NAI for provisioning.  So it would best best to coordinate both the name, and the use of it.  Perhaps "provisioning.arpa" could be used as a generic name, and then subdomains within that could be used for particular purposes.

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 6 Mar 2019 14:30:07 +0100

Hi Aura,

Just on this one point:

> On 6 Mar 2019, at 13:23, Aura Tuomas <[email-masked]> wrote:
> 
> 
> The realm used by the peer is initially “eap-noob.net <http://eap-noob.net/>”. The server can assign another realm in Initial Exchange. The main purpose for assigning another realm is that the peer can later use it for roaming in access networks that have AAA routing set up for the assigned realm.
> 

Since this is going to be somewhat common between new mechanisms as a routing function (and it’s a very good idea!), it makes sense for the realm to be properly registered as a protocol parameter.  A few of us had a discussion about this.  The suggestion was made that this should fall under the .ARPA domain, so that it is properly reserved.  I propose that we discuss this a bit in Prague.  (FWIW, I didn’t come up with the .ARPA idea, but I like it).

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 6 Mar 2019 14:30:58 +0100

And indeed it was Alan who I was referring to in my message.  I generally agree with Alan’s thinking below.

Eliot

> On 6 Mar 2019, at 13:45, Alan DeKok <[email-masked]> wrote:
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Aura Tuomas <[email-masked]>
Date: Tue, 12 Mar 2019 08:46:35 +0000

We had intended to transfer "eap-noob.net" to IANA, but replacing this domain with .arpa is equally ok. 

The domain name reservation considerations in section 4.4. of https://tools.ietf.org/html/draft-aura-eap-noob-05#section-4.4 will still be relevant.  

Tuomas

-----Original Message-----
From: Eliot Lear <[email-masked]> 
Sent: Wednesday, 6 March, 2019 15:31
To: Alan DeKok <[email-masked]>
Cc: Aura Tuomas <[email-masked]>; [email-masked]
Subject: Re: [Emu] Questions about EAP-NOOB
Importance: High

Eliot

---

From: Shiva Prasad Thagadur Prakash <[email-masked]>
Date: Mon, 18 Mar 2019 14:36:46 +0000

Hi Tuomas,

See in line.

On ke, 2019-03-06 at 12:23 +0000, Aura Tuomas wrote:
> Yes, the Initial Exchange in EAP-NOOB always ends in EAP-Failure. 
> Then, we give some time for the user to transfer the OOB message.
> After the OOB step, the peer tries again and the Completion Exchange
> ends in EAP-Success.
>  
> Yes, the out-of-band (OOB) message is cryptographically bound to the
> ECHD result. That, is the message authentication code (Hoob) in the
> OOB message takes the ECDH output as one of its inputs.

This statement is not completely true. If you look at the Hoob
calculation specified in the draft https://tools.ietf.org/html/draft-au
ra-eap-noob-05#section-3.3.2:

Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos
      uitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob).

As you can see, the Hoob only confirms the public keys involved in the
ECDHE exchange but not actually use the shared secret derived. Thus, it
does not use the ECDHE output. 

However, from my implementation experience, I think this is the correct
way to calculate Hoob since it allows applications to externalize the
generation of random nonce Noob and the corresponding Hoob. This would
allow deployments to choose how often these values are created. For
example, some display devices might refersh the QR code containing Noob
and Hoob every few minutes. 

Regards,
Shiva

>  
>  
> Our current implementation opportunistically tries all the W-Fi
> network that support WPA2-Enterprise. It definitely would be better
> to advertise the capability for EAP-NOOB in IEEE 802.11u, or even
> advertise the domain of the EAP-NOOB server. I think it will take
> some time before the 802.11 APs start to support EAP-NOOB in that
> way, though, and we want the protocol to work with existing Wi-Fi
> networks.
>  
> The realm used by the peer is initially “eap-noob.net”. The server
> can assign another realm in Initial Exchange. The main purpose for
> assigning another realm is that the peer can later use it for roaming
> in access networks that have AAA routing set up for the assigned
> realm.
>  
> We have only tested EAP-NOOB on Wi-Fi: https://github.com/tuomaura/ea
> p-noob. It can be used on any networks that support EAP and where the
> user-assisted OOB authentication methods makes sense from the user
> experience perspective.
>  
> Regards,
> Tuomas
>  
>  
> We have been discussing EAP NOOB draft we would like to ask some
> questions about it. It is a very interesting approach related to
> IoT.  
> 
> 
> In EAP-NOOB as first step the EAP authenticator starts the
> authenction (e.g. the AP), eap-noob happens but it seems there will
> be a EAP failure , is this correct?
> Assuming it is, if you send an EAP failure, will the EAP method still
> continue? How would this work? Since we are waiting, we assume, from
> an EAP success, or an alternative way of confirmation that the
> authentication has been completed.
>  
> Regarding the discovery of the EAP authenticator. The AP should
> announce what are the available domains to where it is connected ( a
> solution based on the AAA infraestructure ?) Could this information
> be provided to the AP using IEEE 802.11u?
>  
> Another question would be which are the main radio technologies where
> EAP NOOB is expected to be used. Are you planning to support
> 802.15.4, WIFI, etc? In this line, do you have any EAP-NOOB
> implementation in Contiki?
>  
>  
>  
> Thank you in advance. 
> Best Regards.
> Dan and Rafa.
> 
> 
> -- 
> E-mail: [email-masked]  
> Web: www.odins.es 
> AVISO LEGAL: La información contenida en este correo electrónico, y
> en su caso en los documentos adjuntos, es información privilegiada
> para uso exclusivo de la persona y/o personas a las que va dirigido.
> No está permitido el acceso a este mensaje a cualquier otra persona
> distinta a los indicados. Si usted no es uno de los destinatarios,
> cualquier duplicación, reproducción, distribución, así como cualquier
> uso de la información contenida en él o cualquiera otra acción u
> omisión tomada en relación con el mismo, está prohibida y puede ser
> ilegal. En dicho caso, por favor notifíquelo al remitente y proceda a
> la eliminación de este correo electrónico, así como de sus adjuntos
> si los hubiere.
> Asimismo, y en cumplimiento de Ley Orgánica 3/2018 de protección de
> datos de carácter personal y garantía de los derechos digitales y del
> Reglamento Europeo RGPD 679/2016 le informamos que sus datos están
> siendo objeto de tratamiento por parte de ODIN SOLUTIONS, S.L. con
> N.I.F. B-73.845.893, con la finalidad del mantenimiento y gestión de
> relaciones comerciales y administrativas. La base jurídica del
> tratamiento es el cumplimiento de la legislación fiscal, mercantil y
> contable. No se prevén cesiones y/o transferencias internacionales de
> datos. Para ejercitar sus derechos puede dirigirse a ODIN SOLUTIONS,
> S.L., domiciliada en C/ Perú, 5, 3º, Oficina 12, Pol. Ind. Oeste,
> 30820 Alcantarilla (Murcia), o bien por E-mail a protecciondedatos@od
> ins.es, con el fin de ejercer sus derechos de acceso, rectificación,
> supresión (derecho al olvido), limitación de tratamiento,
> portabilidad de los datos, oposición, y a no ser objeto de decisiones
> automatizadas, indicando como Asunto: ·Derechos Ley Protección de
> Datos·, y adjuntando fotocopia de su D.N.I.