Hi Kai,
I think that your idea is fine. I agree with you.
Just one concern ...
We know that the connection between device and protocol adapter is encrypted in this case but ... what about the connection between protocol adapter and Hono in terms of registration API.
I guess that between adapter and Hono no sensible information are exchanged but just identities (i.e. pre shared keys are always only on adapter and device) so no need for encrypted connection.
Is my understanding right ?
Thanks,
Paolo.
Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor
> From: Kai.Hudalla@xxxxxxxxxxxx
> To: hono-dev@xxxxxxxxxxx
> Date: Tue, 4 Oct 2016 07:03:59 +0000
> Subject: [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
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev