Re: [PATCH BlueZ 1/1] mesh: Add APIs for Provisioner and Config Client

[Michal Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>]

Hi,

On 04/05, Stotland, Inga wrote:
> > Imagine an existing network provisioned by someone else, (...)
> > We would like to add a Linux-based device to that network. (...)
> > To achieve that, we need some kind of API that allows provisioning
> > meshd locally, ideally via D-Bus.
>
> To me, this scenario seems to me more like "import the node" rather
> than "provision the device".

Yes, indeed. Having an API to import a complete node into the daemon
would be enough. But note that such an import would need to contain, and
*all* the keys, device key included.

> We could do that with either a new Import(dict cofiguration) method,
> where configuration is a dictionary that contains all the preset
> values (netkeys, uuid, unicast, etc). This method is different from
> Create() since the netkeys are coming from the "outside".

Yes, that would do, but there seem to be some objections to passing keys
over DBus.

> The current approach is to keep all the netkeys and appkeys within the
> daemon without ever exposing them to an application.

Yeah, I know. I just don't think it's practical to assume this, because
of the use cases mentioned earlier in this thread. I strongly feel there
is a need for a centralized database, handled outside of the daemon,
ideally on a some kind of internet server.

> Alternatively, If a node has been created and configured by a third
> party then adding it to the existing meshd management could be
> achieved by transcribing its configuration into a meshd internal
> storage format (which is in json readable form and could be
> potentially exposed as a schema).

That's true, but this would also mean that the storage format becomes an
API.

I don't think this is a good idea, I'd rather allow the daemon to modify
storage format freely (with a proper migration from older versions, of
course). Especially considering that while JSON works for now, I think
in a long run node data should be stored in some kind of transactional
database.

> > Moreover, since the Attach() token already travels through the bus (...)
> Just having the token is not enough: there are some checking
> mechanisms (and I believe they need to be extended) to check the
> validity of the attaching application.

As far as I can see, these checks mostly concern composition data
(elements/models in particular), and this can be easily queried. Mesh
daemon doesn't seem to use any additional secrets besides the token.

So from what I gather, the daemon already depends on the bus being
secure, and I don't see any practical difference between exchange of
tokens and exchange of keys.

> > > Most of your recommendation directly affect the security of the Keys, 
> > > and whether they get passed via D-Bus...  And this is something that I 
> > > would *not* do without the OK from Marcel Holtmann (...)
> > Could you please point me to the relevant thread? I know I'm late to
> > he party and would very much like to catch up, as much as I can.
> This was a verbal discussion I believe.

Oh... Could someone (Brian? Marcel?) please summarize the main points
then? It's hard to argue about arguments I cannot possibly know :(

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND