Re: [hono-dev] Extend Registration API

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

I agree. However, so far we haven't exposed any config properties in Hono server
nor client to configure TLS.

I will create an issue for that.
-- 
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

On Do, 2016-10-06 at 13:15 +0200, Dejan Bosanac wrote:
> Hi Kai,
> 
> the idea of extended registration API sounds good to me and I can see how it
> can be useful in different contexts. 
> 
> As of the question of connection between protocol adapters and hono, I see that
> as internal part of the system, so we should provide different deployment
> options, depending on how trusted is the environment.
> 
> On Wed, Oct 5, 2016 at 11:21 AM, Hudalla Kai (INST/ESY1) <Kai.Hudalla@bosch-si.
> com> wrote:
> > 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
> > _______________________________________________
> > 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
> > 
> 
> 
> -- 
> Regards
> --
> Dejan Bosanac
> about.me/dejanb
> _______________________________________________
> 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