Subject: [T2TRG] Report from breakout on using application credentials to enable network access

From: Mohit Sethi <[email-masked]>
Date: Thu, 13 Apr 2017 11:41:16 +0300

Topic: Use of application credentials for enabling network access (and 
vice-versa).

Participants (15 active): Erik Nordmark (note taker), Mohit Sethi 
(breakout leader), Thorsten Dahm, Donald Eastlake, Behcet Sarikaya, 
Demir Rakanovic, Phillip Hallam-Baker, Grace Lewis, Ludwig Seitz, 
Muhhamad Sajjad, Jari Arkko, Laurent Toutain, Hitoshi Asaeda, Francesca 
Palombini, Stephen Kraiman.

Summary and Conclusions from breakout:

1. It can be useful to enable network access for IoT devices using 
application credentials: This leads to less configuration work for the 
user of a new IoT device which is especially beneficial since the 
devices often have limited UI. Think of a new IoT toothbrush that you 
have just purchased. You bring it home and register it with the 
manufacturer (by reading a serial number/public key/scanning QR code 
etc.). It would be nice if the manufacturer can then tell the Access 
Point (AP) at the 
users home to enable limited Internet connectivity for the device.

2. Interesting to investigate if we can reverse the direction of 
enabling network-access: Instead of adding software and hardware 
complexity in the devices itself, it would make sense to simply put the 
dumb IoT devices at the desired location and then enable access from a 
server which is more resourceful.

3. Isolation: It would also be smart to put the IoT devices in separate 
VLANs. When the device is authenticated as an IoT device it should be 
put in its separate VLAN so that it has limited connectivity to only a 
couple of services (such as calling home for software update etc).

4. Scaling this to 1000s or 10k devices can be challenge. This also 
relates to the fact that enterprise scenarios are very different from 
the home scenarios. Enterprises may not want to delegate network access 
authentication to an external third party (such as the IoT device 
manufacturer).

5. Revoking network access should be secure and simple. For example, if 
one of the IoT devices is lost or sold, it shouldn't require you to 
change the network-access credentials for all the devices.

Possible Research work: Can we use existing protocols 
(802.1x/RADIUS/DIAMETER) for enabling such network access based on 
application credentials.

--Mohit

PS: Participants from the breakout are welcome to correct if there are 
errors or there is something I missed. Comments from the group are welcome.

---

From: Dan García Carrillo <[email-masked]>
Date: Fri, 14 Apr 2017 00:45:28 +0200

Dear all: 

Regarding the topic of  network access for IoT devices.
We are currently working on that, using RADIUS and EAP. Concretely, we are using CoAP to transport EAP messages. The proposal is in draft-marin-ace-wg-coap-eap. 

We have a functional prototype of the protocol for Contiki O.S. and we have performed some tests comparing the performance to PANATIKI's implementation of the PANA protocol for Contiki O.S shown in this article. http://www.mdpi.com/1424-8220/16/3/358

We are currently working on the concept of CoAP relay and proxy for network access authentication. 

Questions are welcome.
Best Regards,
Dan.

>> De: Mohit Sethi <[email-masked] <mailto:[email-masked]>>
>> Fecha: 13 de abril de 2017, 10:41:16 CEST
>> Para: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> Asunto: [T2TRG] Report from breakout on using application credentials to enable network access
>> 
>> Topic: Use of application credentials for enabling network access (and vice-versa).
>> 
>> Participants (15 active): Erik Nordmark (note taker), Mohit Sethi (breakout leader), Thorsten Dahm, Donald Eastlake, Behcet Sarikaya, Demir Rakanovic, Phillip Hallam-Baker, Grace Lewis, Ludwig Seitz, Muhhamad Sajjad, Jari Arkko, Laurent Toutain, Hitoshi Asaeda, Francesca Palombini, Stephen Kraiman.
>> 
>> 1. It can be useful to enable network access for IoT devices using application credentials: This leads to less configuration work for the user of a new IoT device which is especially beneficial since the devices often have limited UI. Think of a new IoT toothbrush that you have just purchased. You bring it home and register it with the manufacturer (by reading a serial number/public key/scanning QR code etc.). It would be nice if the manufacturer can then tell the Access Point (AP) at the users home to enable limited Internet connectivity for the device.
>> 
>> 2. Interesting to investigate if we can reverse the direction of enabling network-access: Instead of adding software and hardware complexity in the devices itself, it would make sense to simply put the dumb IoT devices at the desired location and then enable access from a server which is more resourceful.
>> 
>> 3. Isolation: It would also be smart to put the IoT devices in separate VLANs. When the device is authenticated as an IoT device it should be put in its separate VLAN so that it has limited connectivity to only a couple of services (such as calling home for software update etc).
>> 
>> 4. Scaling this to 1000s or 10k devices can be challenge. This also relates to the fact that enterprise scenarios are very different from the home scenarios. Enterprises may not want to delegate network access authentication to an external third party (such as the IoT device manufacturer).
>> 
>> 5. Revoking network access should be secure and simple. For example, if one of the IoT devices is lost or sold, it shouldn't require you to change the network-access credentials for all the devices.
>> 
>> 
>> Possible Research work: Can we use existing protocols (802.1x/RADIUS/DIAMETER) for enabling such network access based on application credentials.
>> 
>> --Mohit
>> 
>> PS: Participants from the breakout are welcome to correct if there are errors or there is something I missed. Comments from the group are welcome.
>> 
>> _______________________________________________
>> T2TRG mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/t2trg <https://www.irtf.org/mailman/listinfo/t2trg>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Apr 2017 13:55:58 +0200

Hi Mohit,

thanks for the writeup.

A few remarks inline:

On 04/13/2017 10:41 AM, Mohit Sethi wrote:
> Point (AP) at the users home to enable limited Internet connectivity for
> the device.

While this would be nice it is almost impossible to deploy.
Since OEMs, device vendors nor network operators have to do their
deployment at the same time to make this happen it is an uphill battle.

Furthermore, neither home users, enterprises, nor industrial IoT
deployments will allow external parties to configure their network.

> server which is more resourceful.

Where would this server be?

Note that the story for network access varies hugely between different
connectivity technologies.

> couple of services (such as calling home for software update etc).

Sounds useful but would require some management overhead, which is most
likely only justified in an enterprise network. I can hardly imagine how
home users configure such an isolation nor what benefits it would give
them (since their networks are rather small).

> authentication to an external third party (such as the IoT device

When you say "this" what do you refer to?

> change the network-access credentials for all the devices.

This is not necessarily a technology challenge since we have all the
necessary mechanisms in place. Unfortunately, many home networks use a
somewhat simplistic credential configuration mechanism with class keys.

> (802.1x/RADIUS/DIAMETER) for enabling such network access based on
I am sure we could work it out but I am less sure there is interest to
deploy it (from an incentive, business model, security, etc. point of
view).

Ciao
Hannes

> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Apr 2017 13:31:15 -0400

Dan García Carrillo <[email-masked]> wrote:
    > Regarding the topic of network access for IoT devices.  We are
    > currently working on that, using RADIUS and EAP. Concretely, we are
    > using CoAP to transport EAP messages. The proposal is in
    > draft-marin-ace-wg-coap-eap.

    > We have a functional prototype of the protocol for Contiki O.S. and we
    > have performed some tests comparing the performance to PANATIKI's
    > implementation of the PANA protocol for Contiki O.S shown in this
    > article. http://www.mdpi.com/1424-8220/16/3/358

What node provides the authenticator function?
Do you have that part in Contiki?  Your document says you run that on a Linux
system using hostapd.

How do you establish the radius shared secret for node A or B,
so that it can help enroll some future node E.  Or must it always go through
pre-established controller C?

If that's an intended limitation, then it can't work for enrolling nodes
in a route-over mesh, only for single-hop networks.

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

---

From: Dan García Carrillo <[email-masked]>
Date: Sat, 15 Apr 2017 13:29:55 +0200

Hi, 

> El 14 abr 2017, a las 19:31, Michael Richardson <[email-masked]> escribió:
> 
> 
In the prototype implementation the Authenticator currently is outside the 6LowPAN. We connect to it with the border router in Contiki.  

> in a route-over mesh, only for single-hop networks.

Are you asking if we support the joining through an intermediary? If that is the case, we are currently working on that with a CoAP relay and CoAP proxy. The authentication is always with the Controller, through the intermediary (that is previously authenticated and shares key material with the Controller), and it would be no problem in a multi-hop network.

Regards,
Dan

---

From: Dan García Carrillo <[email-masked]>
Date: Sat, 15 Apr 2017 13:29:55 +0200

Hi, 

 

Regards,
Dan