From: "Gix, Brian" <brian.gix@intel.com>
To: "Michał Lowas-Rzechonek" <michal.lowas-rzechonek@silvair.com>
Cc: "linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
"Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions
Date: Mon, 16 Sep 2019 10:55:54 +0000 [thread overview]
Message-ID: <8DD9DDA0-1081-479F-B215-2E815B1A8F27@intel.com> (raw)
In-Reply-To: <20190916095845.htvyalekgr4k2ybt@mlowasrzechonek2133>
Hi Michał,
> On Sep 16, 2019, at 11:58 AM, Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com> wrote:
>
> Hi Brian,
>
>> On 09/15, Brian Gix wrote:
>> DevKey operations require authorization on the part of the applications
>> making the requests. Messages to state changing Servers should use keys
>> from the local Key Database to demonstrate authority.
>
> Alright, so if I understand this correctly:
>
> 1. If the application would like to change Config Server states on the
> local node, it would need to:
> - call ImportRemoteNode, passing the address of a *local* node and
> the device key obtained from provisioner
> - call DevKeySend to a *local* address, with remote flag set to true
> - receive responses via DevKeyMessageReceived from *local* node,
> with remote flag set to true
>
> Essentially this means that talking to a local node using device
> security behaves in the same manner as if the node was a remote one.
>
> 2. If the application would like to implement an external model that
> uses device security, it would:
> - receive DevKeyMessageReceived calls from remote nodes, with remote
> flag set to false
> - send responses by calling DevKeySend to a *remote* address with
> remote flag set to false
>
> This means that calling DevKeySend to a *local* address with remote flag
> false would be forbidden, in order to force the application to use
> ImportRemoteNode first?
I think that is all basically correct. I switched the Boolean bit-sense such that the boolean parameter is “remote” on the send and “local” on the receive.
And most importantly, your last point is an emphatic yes.... you will need to import your own device key to the key ring if you want to talk to your own builtin servers. The one exception will be nodes that have called “Create()” which are generating brand new mesh networks with themselves as unicast 0001.
>
> --
> Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
> Silvair http://silvair.com
> Jasnogórska 44, 31-358 Krakow, POLAND
next prev parent reply other threads:[~2019-09-16 10:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-15 8:14 [PATCH BlueZ 0/1] mesh: Require Dev Key authentication Brian Gix
2019-09-15 8:14 ` [PATCH BlueZ 1/1] mesh: Add local/remote bools to DevKey transactions Brian Gix
2019-09-16 9:58 ` Michał Lowas-Rzechonek
2019-09-16 10:55 ` Gix, Brian [this message]
2019-09-16 11:08 ` Michał Lowas-Rzechonek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8DD9DDA0-1081-479F-B215-2E815B1A8F27@intel.com \
--to=brian.gix@intel.com \
--cc=inga.stotland@intel.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=michal.lowas-rzechonek@silvair.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).