Re: [hono-dev] Extend Registration API

["Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>]

On Mi, 2016-10-05 at 08:56 +0000, Paolo Patierno wrote:
> 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 ?
> 
The connection between protocol adapters and Hono may or may not be encrypted.
This is up to the administrator of the system to either set it up to use TLS or
not between clients and Hono. That said, my current thinking is in line with
yours, i.e. the shared "secret" (in case of PSK) would NOT be stored in Hono's
registry but only the "identity" the device wants to use for the PSK based TLS
handshake.

This, obviously, raises the question of where to keep such "sensible"
information. Since many other components in an IoT cloud back end would also need
a way to keep their "secrets" (e.g. passwords, tokens etc) it seems feasible to
also have/use a central service for that as well. I have been looking at Vault
[1] for that purpose recently, which looks very promising ...

[1] https://www.vaultproject.io

> Thanks,
> Paolo.
> 
> Paolo Patierno
> Senior Software Engineer (IoT) @ Red Hat
> Microsoft MVP on Windows Embedded & IoT
> Microsoft Azure Advisor 
> 
> Twitter : @ppatierno
> Linkedin : paolopatierno
> Blog : DevExperience
> 
> 
> > 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
> _______________________________________________
> 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