[I2nsf] draft-qi-i2nsf-access-network-usecase-00

[Hannes Tschofenig <[e-mail]>]

Following the presentation at the last IETF meeting I read
draft-qi-i2nsf-access-network-usecase-00 with a focus on the mentioned
Internet of Things use cases.

The draft mentions Internet of Things in Section 3 as well but does not
go into the details about the type of security (and configuration)
provisioning.

Since we have been working on various Internet of Things related
scenarios in other working groups (DICE, CORE, LWIG, ACE, etc.) it would
be good to go into more details.

In particular, I would like to understand what is wrong with the
currently developed solution. Maybe they do not provide the
functionality needed or there are other use cases that have not been
covered yet.

I would also suggest to look at the OMA Lightweight Machine-to-Machine
specification since it provides provisioning capabilities and makes use
of the IETF CoAP protocol. It also offers a number of cellular
operator-based scenarios.

The specification can be found at:
http://openmobilealliance.org/about-oma/work-program/m2m-enablers/

At the last IETF meeting my co-worker Michael Koster gave an overview
talk that explained how CoAP, OMA LWM2M, and the IPSO objects fit
together. The slides can be found here:
http://www.slideshare.net/MichaelKoster/ietf91-ad-hoccoaplwm2mipso-41542196

Note also that this provisioning interface is rather generic and allows
various parties to use it - not just network operators but also
application providers.

It might also be worthwhile to note that

* when IoT devices execute network authentication then there is no user
interaction (just a terminology issue since you are writing about users
in your scenario),

* the street lighting deployments I am aware of do not use cellular
technology but rather a multi-hop mesh network based on sub-Ghz IEEE
802.15.4 technology. For this reason it might be useful to go into more
details with regard to the description of the scenario.

* when you use cellular radio technology then you would have the shared
secret for the AKA algorithm already on the smart card and the
credential provisioning happens during the manufacturing time.

* The story about configuring different key lengths is OK but we are
currently working on a profile that tries to reduce the number of
options as much as possible (at least when DTLS/TLS is used in the IoT
context). This work happens in the IETF DICE working group.

* There could potentially be an overlap with the use cases we are
investigating in the ACE working group. Please take a look at the use
case document, which you can find at
http://tools.ietf.org/html/draft-seitz-ace-usecases-02

Ciao
Hannes