Re: [Emu] [Iot-onboarding] On boarding again

[Eliot Lear]

PRs welcome!

> On 7 Mar 2019, at 08:28, Szymon Słupik  wrote:
> 
> Hi Eliot,
> 
> It'd be great to include Bluetooth mesh in here, as (despite sharing the 
> brand and the underlying radio with Bluetooth LE) it is a completely 
> different animal, when it comes to onboarding, authentication, security. I 
> will add some initial bullets for Bluetooth mesh here, hope to do this next 
> week.
> 
> Best
> Szymon Slupik
> President, CTO
> +1-415-696-9111 
> 
> ul. Jasnogórska 44
> 31-358 Kraków
> Poland
> 
> www.silvair.com 
>  
> 
> 
> NOTICE TO RECIPIENT
> We inform you that Silvair sp. z o.o. with its registered office in Cracow 
> (31-358), at Jasnogórska Street 44 is the controller of your personal data. 
> You can find more information about processing personal data and your rights 
> here 
> .
> This e-mail message and any documents accompanying it contain information 
> that belongs to SILVAIR. This e-mail is meant for only the intended recipient 
> of the transmission, and may be a communication privileged by law, 
> confidential and/or otherwise protected from disclosure. If you received this 
> e-mail in error and you are not the intended recipient, any review, use, 
> dissemination, distribution, or copying of this e-mail or attachment is 
> strictly prohibited. Please notify us immediately of the error by return 
> e-mail and please delete this message from your system.
> 
> 
> 
> On Wed, Mar 6, 2019 at 2:32 PM Eliot Lear  > wrote:
> Hi everyone,
> 
> For those who are interested in discussing onboarding, I’ve reserved an hour 
> on Wednesday afternoon (27 Mar) at 14:00 at the IETF in Karlin 3.  Since our 
> last conversation, a few of us put a bit of an inventory together, regarding 
> the mechanisms that are available.  Some of the questions we have Aren’t 
> Quite There Yet, but at least the inventory is coming along.
> 
> Goal of discussion this time around  would a shared understanding of how 
> these mechanisms work, what sort of commonality they have, and to perhaps 
> have some notion of applicability of each.
> 
> For your entertainment, you can take a look at a table… it’s a Github table 
> so you have to scroll a bit- see 
> https://github.com/iot-onboarding/catalog/blob/master/Onboard-Table.md 
> .  
> Feel free to issue PRs.
> 
> Also, feel free to agenda bash on iot-onboard...@ietf.org 
> .
> 
> Eliot
> --
> Iot-onboarding mailing list
> iot-onboard...@ietf.org 
> https://www.ietf.org/mailman/listinfo/iot-onboarding 
> 



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [Iot-onboarding] On boarding again

[Szymon Słupik]

Hi Eliot,

It'd be great to include Bluetooth mesh in here, as (despite sharing the
brand and the underlying radio with Bluetooth LE) it is a completely
different animal, when it comes to onboarding, authentication, security. I
will add some initial bullets for Bluetooth mesh here, hope to do this
next week.

Best

Szymon Slupik
President, CTO
+1-415-696-9111

[image: Silvair]
ul. Jasnogórska 44
31-358 Kraków
Poland

www.silvair.com

[image: Facebook]    [image:
LinkedIn]    [image: Twitter]


NOTICE TO RECIPIENT
We inform you that Silvair sp. z o.o. with its registered office in Cracow
(31-358), at Jasnogórska Street 44 is the controller of your personal data.
You can find more information about processing personal data and your
rights here
.

This e-mail message and any documents accompanying it contain information
that belongs to SILVAIR. This e-mail is meant for only the intended
recipient of the transmission, and may be a communication privileged by
law, confidential and/or otherwise protected from disclosure. If you
received this e-mail in error and you are not the intended recipient, any
review, use, dissemination, distribution, or copying of this e-mail or
attachment is strictly prohibited. Please notify us immediately of the
error by return e-mail and please delete this message from your system.


On Wed, Mar 6, 2019 at 2:32 PM Eliot Lear  wrote:

> Hi everyone,
>
> For those who are interested in discussing onboarding, I’ve reserved an
> hour on Wednesday afternoon (27 Mar) at 14:00 at the IETF in Karlin 3.
> Since our last conversation, a few of us put a bit of an inventory
> together, regarding the mechanisms that are available.  Some of the
> questions we have Aren’t Quite There Yet, but at least the inventory is
> coming along.
>
> Goal of discussion this time around  would a shared understanding of how
> these mechanisms work, what sort of commonality they have, and to perhaps
> have some notion of applicability of each.
>
> For your entertainment, you can take a look at a table… it’s a Github
> table so you have to scroll a bit- see
> https://github.com/iot-onboarding/catalog/blob/master/Onboard-Table.md.
> Feel free to issue PRs.
>
> Also, feel free to agenda bash on iot-onboard...@ietf.org.
>
> Eliot
> --
> Iot-onboarding mailing list
> iot-onboard...@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Notes on session resumption with TLS-based EAP methods

[Arran Cudbard-Bell]

>   The solution to this conundrum is to associate authentication
>   credentials and authorization information with the original
>   authentication.  That information can then be obtained and applied
>   during resumption.
> 
>   There are two ways to make this association.  The first method is via
>   [RFC5077],

'session tickets for TLS versions 1.2 and below, and [RFC 8446] session tickets 
in TLS 1.3.'

I know it's pedantic, but RFC 8446 obsoletes RFC 5077.



>   Any authorization applied during resumption MUST be done using the
>   cached data,

'or data resolved or obtained using that cached data.'

authorization doesn't need to performed in a sandboxed environment with only 
the cached data.



>   * MAC address of the EAP peer * IP address of the EAP peer *
>   Informtion about the ethernet switch to which the EAP peer is
>   connecting
>  * MAC address of the switch
>  * IP address of the switch
>  * switch port used by the EAP peer
>   * Wifi SSID
>   * Information about the ethernet layer used by the EAP peer

* Media-Type

Cross resumption between VPNs and Wired/Wireless infrastructure could be a big 
issue.
It might be worth mentioning that explicitly as I think it'll be a blind spot 
for implementors.

Out of the box, if someone used our EAP server implementation for 
authenticating VPN users
and wired/wireless users, we would allow cross resumption, because the EAP 
server
doesn't allocate session tickets based in different contexts by default.

>   The EAP server also has access to the cached EAP-Response / Identity
>   from the original authentication.
> 
>   None of these fields are authenticated or secured.  As a result, any
>   or all of these fields can change between the original
>   authentication, and resumption.  This change creates a "Time of
>   check, time of use" (TOCTOU) security vulnerability.  A malicious
>   user could supply one set of data during authentication, and a
>   different set of data during resumption.  The malicious user could
>   then obtain different authorization during resumption, potentially
>   leading to them obtaining access that they should not have.
> 
>   When EAP servers make policy decisions based on unauthenticated
>   information, they MUST then add that information to the cached data

maybe 'then it MUST be used in combination with the cached data described above'

Took a couple of readings to understand exactly what you meant there.
The cached data isn't being updated, but it's being used together with the 
unauthenticated
information, right?

The majority of this sounds great though.

-Arran



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Notes on session resumption with TLS-based EAP methods

[John Mattsson]

Thanks for the suggested security consideration Alan! This helps a lot!

I'll will work with updating the draft during the next days. Your suggested 
text look very good at a first readthrough.

Cheers,
John



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

Re: [Emu] Questions about EAP-NOOB

[Eliot Lear]

Hi Aura,

Just on this one point:

> On 6 Mar 2019, at 13:23, Aura Tuomas  wrote:
> 
> 
> 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.
> 

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



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Questions about EAP-NOOB

[Eliot Lear]

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  wrote:
> 
> On Mar 6, 2019, at 7:23 AM, Aura Tuomas  wrote:
>> 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.
> 
>  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.
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] On boarding again

[Eliot Lear]

Hi everyone,

For those who are interested in discussing onboarding, I’ve reserved an hour on 
Wednesday afternoon (27 Mar) at 14:00 at the IETF in Karlin 3.  Since our last 
conversation, a few of us put a bit of an inventory together, regarding the 
mechanisms that are available.  Some of the questions we have Aren’t Quite 
There Yet, but at least the inventory is coming along.

Goal of discussion this time around  would a shared understanding of how these 
mechanisms work, what sort of commonality they have, and to perhaps have some 
notion of applicability of each.

For your entertainment, you can take a look at a table… it’s a Github table so 
you have to scroll a bit- see 
https://github.com/iot-onboarding/catalog/blob/master/Onboard-Table.md 
.  Feel 
free to issue PRs.

Also, feel free to agenda bash on iot-onboard...@ietf.org 
.

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Questions about EAP-NOOB

[Alan DeKok]

On Mar 6, 2019, at 7:23 AM, Aura Tuomas  wrote:
> 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. 

  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.

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

Re: [Emu] Questions about EAP-NOOB

[Aura Tuomas]

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  On Behalf Of Dan Garcia
Sent: Monday, 28 January, 2019 13:39
To: emu@ietf.org
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: dgar...@odins.es

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
=

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 
protecciondeda...@odins.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: