Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[hono-dev] Extend Registration API

Hi,

during the last weeks I have been thinking a lot about the way device identity
finds its way into Hono.
The Registration API provides means to register a device ID for a tenant.
However, there is no way of storing any additional meta data about the device,
which, so far did not pose a problem at all.

I am currently working on a simple LWM2M protocol adapter based on Eclipse
Leshan. In doing so, I realized that some of the protocol adapters might actually
have a need not only for determining if a device actually exists but also for
finding out which identifier the device is registered under in Hono, given only
the identity the device has been authenticated as using the device's specific
transport protocol.

An example based on LWM2M:
When a device connects to a LWM2M server using CoAP over DTLS (the UDP version of
TLS), it usually authenticates to the server using a pre-shared key based cipher
suite. For that purpose the LWM2M server and the device share a "secret" (the
key) that belongs to the device's identity (an arbitrary byte array) and which is
used during the DTLS handshake to prove that both peers have the same secret for
that identity. Once the handshake is done an encrypted UDP based channel is
established and the client registers with the LWM2M server under its LWM2M
"endpoint name" using a specific CoAP message. The LWM2M server now needs to make
sure that the authenticated identity (from the DTLS layer) "belongs" to the
endpoint name the device registers with. The LWM2M server therefore needs a
registry mapping identities from the DTLS layer to endpoint names.
After the device has registered and later sends notifications about sensor
readings, the LWM2M protocol adapter needs a way of figuring out which identity
in Hono the device's endpoint name should be mapped to. Again, a registry for
mapping device identities is needed.

The same problem occurs with almost any other Protocol Adapter that authenticates
a client as part of the (D)TLS handshake (be it X.509 certificates or
RawPublicKeys or PSK).

In order to provide for such a mapping facility I would like to extend Hono's
Registration API with the option of registering (multiple) alternative identities
for a device, including the alternative identity's "type", e.g. "X.509 subject
name" or "PSK identity" or "RawPublicKey hash" etc.

This way, protocol adapters can use Hono's Registration API not only to register
devices but also to determine the (multiple) identities the device is known under
(in different contexts).

So, the LWM2M protocol adapter could ask Hono (in RESTful meta language):

GET /registration/DEFAULT_TENANT/IMEI354354364?id-type=LWM2M

and Hono could e.g. respond with

{
 "deviceId": "4711",
 "lwm2M-ep": "IMEI354354364",
 "psk-identity": "A023F56B10"
}

where "deviceId" is the identity the device has been registered under in Hono
originally.

The protocol adapter can then use this information to match the PSK identity with
the endpoint name and also determine

WDYT?
-- 
Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

Back to the top