Subject: [Iot-onboarding] EduRoam for IoT

From: sandoche Balakrichenan <[email-masked]>
Date: Mon, 9 Dec 2019 15:54:13 +0100

Dear all,

I am sure that you might have all heard about EduRoam 
(https://www.eduroam.org/how/).

We are in discussion with some academic partners to develop a platform 
similar to EduRoam for IoT, initially for Research purposes.

The idea initially is to have IoT devices (e.g. LoRa devices) 
authenticated in visited networks based on its identifier. For example, 
a LoRa end-device which has established authentication in its home 
network (e.g. in University A) should be able to connect to a gateway 
and Network Server in a visited network (e.g. In University B) with the 
same security credentials.

This is not a new idea. We can see that there have been related works at 
the IETF, WBA alliance etc.

The purpose of this mail is to check if this topic falls under the 
charter of the IoT-Onboarding discussion and could be discussed in this 
mailing list.

If otherwise, thanks for your suggestions, contacts, feedback personally 
to me and Guillaume in cc regarding the topic.

Sandoche.

---

From: Dan Garcia <[email-masked]>
Date: Mon, 9 Dec 2019 16:28:10 +0100

Dear Sandoche, all,

I think this is an interesting topic. In fact, we started some years ago 
(for my PhD) a work specifically related to that task as well as some 
related work in the area, which I put next.

We designed and developed an EAP lower layer based on CoAP with 
integration with AAA, with the constraints of IoT in mind. We have 
compared it with a current standard (PANA).

  * Here is the draft -
    https://datatracker.ietf.org/doc/draft-marin-ace-wg-coap-eap/

  * Here is the detail design and comparison with PANA  -
    https://www.mdpi.com/1424-8220/16/3/358

  * Here is a re-desing when we started working on LP-WAN where we
    tested on a real LoRa network with IMT Atlantique -
    https://www.mdpi.com/1424-8220/17/11/2646

  * Here is the design, implementation and validation of the
    Intermediaries - alike to the PANA Relay - with three different CoAP
    intermediaries (CoAP proxy, CoAP relay and CoAP stateless proxy)
    compared with PANA - https://ieeexplore.ieee.org/document/8467302

  * We also worked on an extension of LoRaWAN to support AAA with RADIUS
    (https://tools.ietf.org/html/draft-garcia-radext-radius-lorawan-03)
    and DIAMETER
    (https://tools.ietf.org/html/draft-garcia-dime-diameter-lorawan-00)

We are working on this topic and we are interested on following up on it 
if.

Best Regards,

Dan.

On 09/12/2019 15:54, sandoche Balakrichenan wrote:
> authenticated in visited networks based on its identifier. For 
> example, a LoRa end-device which has established authentication in its 
> home network (e.g. in University A) should be able to connect to a 
> gateway and Network Server in a visited network (e.g. In University B) 
> with the same security credentials.
>
> This is not a new idea. We can see that there have been related works 
> at the IETF, WBA alliance etc.
>
> charter of the IoT-Onboarding discussion and could be discussed in 
> this mailing list.
>
> If otherwise, thanks for your suggestions, contacts, feedback 
> personally to me and Guillaume in cc regarding the topic.
>
> Sandoche.
>
-- 
Firma Correo 
=================================================================
	*Dan García Carrillo
Computer Science PhD
Tlf.: +34 902 570 121
E-mail: [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 enviar un correo electrónico a 
[email-masked] 
<mailto:[email-masked]?subject=Derechos Ley Protección de Datos>, 
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: Eliot Lear <[email-masked]>
Date: Mon, 9 Dec 2019 16:34:20 +0100

Hi Sandoche

I think what you are aiming for is a LoRa-enabled router that can do a radius transaction that has the appropriate federated wrapper, such as PEAP/EAP-TLS.  Will the LoRa device know its home network?

Eliot

> On 9 Dec 2019, at 15:54, sandoche Balakrichenan <[email-masked]> wrote:
> 
> Dear all,
> 
> I am sure that you might have all heard about EduRoam (https://www.eduroam.org/how/).
> 
> We are in discussion with some academic partners to develop a platform similar to EduRoam for IoT, initially for Research purposes.
> 
> The idea initially is to have IoT devices (e.g. LoRa devices) authenticated in visited networks based on its identifier. For example, a LoRa end-device which has established authentication in its home network (e.g. in University A) should be able to connect to a gateway and Network Server in a visited network (e.g. In University B) with the same security credentials.
> 
> This is not a new idea. We can see that there have been related works at the IETF, WBA alliance etc.
> 
> The purpose of this mail is to check if this topic falls under the charter of the IoT-Onboarding discussion and could be discussed in this mailing list.
> 
> If otherwise, thanks for your suggestions, contacts, feedback personally to me and Guillaume in cc regarding the topic.
> 
> Sandoche.
> 
> --
> Iot-onboarding mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-onboarding

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Dec 2019 12:45:10 -0500

Eliot Lear <[email-masked]> wrote:
    > I think what you are aiming for is a LoRa-enabled router that can do a
    > radius transaction that has the appropriate federated wrapper, such as
    > PEAP/EAP-TLS.  Will the LoRa device know its home network?

At bytes/day?

I don't think that it is network onboarding, but application onboarding that
is desired.

To repost what I posted to the RIPE IoT list:

My colleagues at CIRALabs did something that might be similar to what you
want, as it deals with the connection/onboarding to the *application* server,
not the network itself, which is assumed to be managed by the Telco:

https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/master/CIRA%20Labs%20-%20Secure%20IoT%20Registry%202019-11-14.pdf

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Mon, 9 Dec 2019 19:27:18 +0100

I think you’re right that EAP-TLS is a little on the heavy side.  Even EAP is challenging.  A microEAP may be required.  It depends on whether you think LoRA is going to IP.  If not, then I agree with Michael and CIRA’s approach.

> On 9 Dec 2019, at 18:45, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: sandoche Balakrichenan <[email-masked]>
Date: Mon, 9 Dec 2019 22:22:09 +0100

On 09/12/2019 16:34, Eliot Lear wrote:
> Hi Sandoche
>
> I think what you are aiming for is a LoRa-enabled router that can do a radius transaction that has the appropriate federated wrapper, such as PEAP/EAP-TLS.
Exactly. Only addition is that the solution, if possible, should be 
generic and not LoRaWAN specific.
> Will the LoRa device know its home network?
LoRa was mentioned since it could be one IoT network that I am familiar 
with and could be tested as a PoC.
Sandoche.

---

From: sandoche Balakrichenan <[email-masked]>
Date: Mon, 9 Dec 2019 22:40:19 +0100

>      > PEAP/EAP-TLS.  Will the LoRa device know its home network?

==> Absolutely.

Alternatives could be : 
https://datatracker.ietf.org/doc/draft-aura-eap-noob/?include_text=1

and evolving standards from the LAKE WG 
(https://datatracker.ietf.org/wg/lake/about/) using a PKI

> I don't think that it is network onboarding, but application onboarding that
==> Application onboarding is for the LoRaWAN scenario.

Don't we have the need for network onboarding for other IoT networks?

The objective is to come with a generic solution, if possible.

Sandoche.

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 10 Dec 2019 13:36:13 +0100

Dear Sandoche:

> El 9 dic 2019, a las 22:40, sandoche Balakrichenan <[email-masked]> escribió:
> 
> 
> Alternatives could be : https://datatracker.ietf.org/doc/draft-aura-eap-noob/?include_text=1

When you use EAP you need an EAP lower-layer to transport EAP between IoT device and the network. As you mention, you would like a generic solution, which means that EAP lower-layer should operate in any link-layer. PANA (https://tools.ietf.org/html/rfc5191) provides that. Also CoAP-EAP (https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-06, https://www.mdpi.com/1424-8220/16/3/358) provides that feature, since it is an EAP lower-layer based on CoAP.

Best Regards.
> 
> and evolving standards from the LAKE WG (https://datatracker.ietf.org/wg/lake/about/) using a PKI
> 
>> 

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: sandoche Balakrichenan <[email-masked]>
Date: Tue, 10 Dec 2019 13:39:52 +0100

Dear Rafa,

Thanks for the input.

We have collected some information based on feedback from different 
people and mailing lists. We will try to prepare a brief document based 
on these inputs and come back to the mailing list.

Sandoche.

On 10/12/2019 13:36, Rafa Marin-Lopez wrote:
> Dear Sandoche:
>
>> El 9 dic 2019, a las 22:40, sandoche Balakrichenan 
>> <[email-masked] 
>> <mailto:[email-masked]>> escribió:
>>
>>
>>> Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
>>>     > I think what you are aiming for is a LoRa-enabled router that 
>>> can do a
>>>     > radius transaction that has the appropriate federated wrapper, 
>>> such as
>>>     > PEAP/EAP-TLS.  Will the LoRa device know its home network?
>>>
>>> At bytes/day?
>>
>> ==> Absolutely.
>>
>> Alternatives could be : 
> When you use EAP you need an EAP lower-layer to transport EAP between 
> IoT device and the network. As you mention, you would like a generic 
> solution, which means that EAP lower-layer should operate in any 
> link-layer. PANA (https://tools.ietf.org/html/rfc5191) provides that. 
> Also CoAP-EAP 
> (https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-06, 
> https://www.mdpi.com/1424-8220/16/3/358) provides that feature, since 
> it is an EAP lower-layer based on CoAP.
>
>
> Best Regards.
>>
>> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 10 Dec 2019 13:31:33 +0000

Hi Sandoche,

I was involved in the development of EAP-NOOB during the early days. 
Back then, we had received a request from Rhys Smith and Josh Howlett 
(from JISC who are involved with eduroam in the UK) for adding roaming 
support.

EAP-NOOB does support roaming. Please look at: 
https://tools.ietf.org/html/draft-aura-eap-noob-07#appendix-D for more 
information. If you have some requirements that are not met, please feel 
free to suggest them to the EMU working group 
(https://datatracker.ietf.org/wg/emu/about/).

I don't know the specific limitations of LoRaWAN. Our colleague, Eduardo 
(in CC), from the University of Murcia has worked on a light-weight 
implementation of EAP-NOOB in Contiki. I am sure he can provide you some 
pointers.

--Mohit

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Dec 2019 10:01:14 -0500

> The objective is to come with a generic solution, if possible.

Then, I think that you want a BRSKI based system, if you want to address a
large number of context.  I am skeptical that this can include LoRA.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: sandoche Balakrichenan <[email-masked]>
Date: Tue, 10 Dec 2019 16:37:34 +0100

Hi Mohit,

Thanks for your inputs. I did come across your draft on EAP-NOOB during 
the literature search on this topic.

Myselves and Guillaume has been busy in collecting inputs regarding 
roaming for IoT from different quarters. We will compile it and come up 
with a basic use-case document to the group.

We were thinking of LoRaWAN, since it seems to be the most resource 
constrained network in the IoT domain. If we are successful in that, 
then it should mostly work with all other IoT networks.

Our objective is to have a generic solution, and not just oriented for 
LoRaWAN.

Sandoche.

---

From: sandoche Balakrichenan <[email-masked]>
Date: Tue, 10 Dec 2019 16:38:37 +0100

> large number of context.  I am skeptical that this can include LoRA.
+1

BRSKI is a promising reference. We will dig further into it for the 
IoTRoam use-case.

Sandoche.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 10 Dec 2019 16:05:34 +0000

> On Dec 10, 2019, at 10:38 AM, sandoche Balakrichenan <[email-masked]> wrote:
> 
> 
> BRSKI is a promising reference. We will dig further into it for the IoTRoam use-case.
> 
> Sandoche.

You may also be interested in SZTP (RFC 8572).

Kent

---

From: Eduardo Ingles UM <[email-masked]>
Date: Tue, 10 Dec 2019 17:10:17 +0100

Dear Sandoche, all,

Together with my colleagues, we have implemented EAP-NOOB and CoAP-EAP 
on Zolertia Firefly motes. This is the GitHub link: 
https://github.com/eduingles/coap-eap-noob

The implementation of CoAP-EAP as EAP Lower Layer is based on the 
previous work of my colleagues at the University of Murcia Rafa Marin 
Lopez and Dan Garcia Carrillo (GitHub link: 
https://github.com/eduingles/coap-eap-controller ).

Here is a demonstration video of EAP-NOOB with Firefly motes and 
out-of-band communication with blinking lights:
https://youtu.be/rPuFKoihl5E

Best regards.

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

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

---

From: sandoche Balakrichenan <[email-masked]>
Date: Tue, 10 Dec 2019 17:22:58 +0100

> You may also be interested in SZTP (RFC 8572).

Hi Kent,

Thanks for the reference. Will have a look at the RFC.

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 11 Dec 2019 10:03:27 +0000

Hi Michael,

On 12/10/19 5:01 PM, Michael Richardson wrote:

I would like to understand the reasoning behind this statement.

I believe that EAP is better suited for a large number of contexts:

- There are more than 52 methods to choose from. Depending on the type of credentials, you can choose from: certificates (EAP-TLS), PSK (EAP-PSK or EAP-TLS-PSK that John, Owen, and I plan to work on), one-time-password (EAP-POTP), password (EAP-pwd), SIM cards (EAP-AKA`) and so on. You can even combine different credentials such as certificates for the outer tunnel and passwords inside (EAP-PEAP/EAP-FAST/EAP-TEAP).
- EAP standard has been around for over a decade and is stable.
- Several implementations exist (including a few open source).
- Roaming and federation is natively supported in the EAP architecture. It has been widely deployed and tested (eg. eduroam).
- Can work a variety of lower-layers such as UDP (PANA), IEEE 802.11 (EAPOL), CoAP (with CoAP-EAP: https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-06)

I gave a cursory look at BRSKI draft the and found references to unauthenticated TLS, TCP, CoAP, HTTP, CDDL. I am certainly not one of those folks who would use the excuse of small devices or limited bandwidth for poor security (see section 9 of RFC 8387 https://tools.ietf.org/html/rfc8387#section-9). However, this seems a bit excessive (at least for Sandoche but probably for many others).

--Mohit

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Thu, 12 Dec 2019 10:26:48 +0100

Hi Mohit:

I fully agree with your e-mail.

Some other comments inline.

> El 11 dic 2019, a las 11:03, Mohit Sethi M <mohit.m.sethi=[email-masked]> escribió:
> 
> Hi Michael,
> 
>> sandoche Balakrichenan <[email-masked]> <mailto:[email-masked]> wrote:
I would like to understand it as well. As a note, we already tested and got some experimental results using CoAP-EAP (with EAP-PSK as proof-of-concept but any other method can be used, such as EAP-NOOB, EAP-AKA’, etc...). 

Please refer to: https://www.mdpi.com/1424-8220/17/11/2646 
> - Can work a variety of lower-layers such as UDP (PANA), IEEE 802.11 (EAPOL), CoAP (with CoAP-EAP:https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-06 <https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-06>)
> 
This summary is great. +1

Best Regards.

> I gave a cursory look at BRSKI draft the and found references to unauthenticated TLS, TCP, CoAP, HTTP, CDDL. I am certainly not one of those folks who would use the excuse of small devices or limited bandwidth for poor security (see section 9 of RFC 8387 https://tools.ietf.org/html/rfc8387#section-9 <https://tools.ietf.org/html/rfc8387#section-9>). However, this seems a bit excessive (at least for Sandoche but probably for many others). 
> 
> --Mohit
> 
>> 
>> --
>> ]     [email-masked] <mailto:[email-masked]>  http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on rails    [
>> 
>> 
>> 
> --

---

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Dec 2019 16:51:52 +0000

> You may also be interested in SZTP (RFC 8572).

On second consideration, RFC 8572 is likely too heavyweight for extreme constrained-device scenarios.

Even if using mDNS and binary COAP/DTLS, it would still be about 5K of data transfer.

Kent