Hi Marco, Thanks for your mail. My comments inline: On 10/12/2019 08:30, Marco Hogewoning wrote:
For the record: writing in this more in personal capacity/curiosity here. But of course also happy to explore if and how RIPE NCC could assist here.
On 9 Dec 2019, at 18:43, sandoche Balakrichenan <sandoche.balakrichenan@afnic.fr> wrote:
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. I can see use case of such a mechanism, also outside of the educational spheres.
However it is not entirely clear on the interworking with LoRa. ==> LoRaWAN was an example. The objective is to have a generic universal solution for IoT.
It's been a while since I last looked at it, but as I understood in LoRaWan (and similar systems), the network layer authentication is more a matter of L2 filtering/forwarding.
I welcome anyone with more current knowledge to correct me here, but the flow as I always understood it:
- Device broadcasts a packet - One or more gateways pick it from the airwaves (ISM, usually 863-870) - The gateway looks at L2 MAC address and if it recognises the vendor/application prefix, forwards it into an IP tunnel to some central processing hub. - The hub then either forwards the payload to the "real home" or in smaller scale operations just makes it available for local processing (API call to pick-up the data payload).
In that context, to me the authentication part becomes a matter of "do I know these macs"/"Am I showing courtesy of forwarding".
The other half is then based on encryption, where you usually see two layers: The first around the entire payload (inc application protocol) that is common to vendor/application and known to the "known" network nodes. And further down a device or user specific certificate to wrap the actual data and keep it private.
If this model is still valid, I am sort of curious on what part you envision becoming part of some federated setup?
==> AFAIK, the model you explained is valid. In Eduroam scenario, when a user connects to a visited network using the EduRoam SSID with his/her login/password, the local RADIUS server at the visited network will forward the user credentials securely to the user's home RADIUS server where they are verified and validated. My initial understanding for IoTroaming similar to EduRoam should be like OpenID (https://en.wikipedia.org/wiki/OpenID). If I try to relate with LoRaWAN example, an End-device with an AppKey and NwkKey should be able to establish connection to its App Server or Join Server via NS2(Visited Network) if it has an agreement with NS1 (Home Network).
Of course other methods exists, like NB-IOT which sits very close to "traditional" GSM roaming and the way SMS are handled. Products like Sigfox in turn seem to just send every packet back home and deal with it there.
More general, sounds a bit like a similar structure the Things Network (http://thethingsnetwork.org) is operating.
==> I think you are referring to https://www.packetbroker.org/ I felt that Packetbroker is like Internet peering, i.e. packet routing to the destination. There is no authentication mechanism. The need for research scenario is like IoT devices from an University Network could be re-used in another network without a need to re-configure the security credentials. This could also be evolved for other use-cases.
Maybe worth liaising with them, if only to learn a bit more? Think I still know a few people there, if you need introductions.
==> I will send a mail to Johan (Things network).
MarcoH