Regarding OOB authentication method & action for Mesh provisioner

Regarding OOB authentication method & action for Mesh provisioner

[Anupam Roy]

Hello,
  Regarding remote node provisioning, currently, it seems 'meshd' is choosing Provisioning method & actions internally, based on remote node's capabilities.
  
  - Choosing Method :-  /* Parse OOB Options, prefer static, then out, then in */
  - Choosing Action:-  Based on high bit set in the action octet:  u16_high_bit(l_get_be16(data + 6)), in case of OUT OOB or  u16_high_bit(l_get_be16(data + 9)) in case of IN OOB

Is the above preference for choosing Authentication Method, based on some pre-defined security level? If yes, can such security levels can be made available to application for configuration?

Also, I would like to know, whether there is any plan to Request external provisioning Agent to choose Provisioning method & specific action?
The reason being, some *application* may be interested in a particular Security level & Authentication action, depending on its own I/O capabilities.
 

BR,
-Anupam Roy

BR,
-Anupam Roy

Re: Regarding OOB authentication method & action for Mesh provisioner

[Michał Lowas-Rzechonek]

Hi,

On 03/02, Anupam Roy wrote:
> Also, I would like to know, whether there is any plan to Request
> external provisioning Agent to choose Provisioning method & specific
> action?  The reason being, some *application* may be interested in a
> particular Security level & Authentication action, depending on its
> own I/O capabilities.

For the record, we also need this is functionality. One of the possible
scenarios is having a provisioner who doesn't have a reliable Internet
connection and might want to fall back to (less secure) OOB actions if
it cannot obtain OOB public key.

We've been planning to send a patch implementing a D-Bus API for that,
but it's not ready yet :(

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

RE: Re: Regarding OOB authentication method & action for Mesh provisioner

[Anupam Roy]

Hi Michal,
 
>--------- Original Message ---------
>Sender : Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
>Date : 2020-03-02 19:52 (GMT+5:30)
>Title : Re: Regarding OOB authentication method & action for Mesh provisioner
> 
>Hi,
> 
>On 03/02, Anupam Roy wrote:
>> Also, I would like to know, whether there is any plan to Request
>> external provisioning Agent to choose Provisioning method & specific
>> action?  The reason being, some *application* may be interested in a
>> particular Security level & Authentication action, depending on its
>> own I/O capabilities.
> 
>For the record, we also need this is functionality. One of the possible
>scenarios is having a provisioner who doesn't have a reliable Internet
>connection and might want to fall back to (less secure) OOB actions if
>it cannot obtain OOB public key.
> 
>We've been planning to send a patch implementing a D-Bus API for that,
>but it's not ready yet :(

Okay, that would be nice & and will it allow application to choose both a) "OOB Pub Key(With/Without)" as well as  b)"OOB Auth Methods(IN/OUT/Static/No OOB) & Actions(Blink/Beep/Vibrate/Num/alpha etc.)"?

> 
>regards
>-- 

>Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
>Silvair https://protect2.fireeye.com/url?k=bcd496bf-e1422fc8-bcd51df0-0cc47a312ab0-f5d986cca20e804f&u=http://silvair.com/
>Jasnogórska 44, 31-358 Krakow, POLAND

Re: Re: Regarding OOB authentication method & action for Mesh provisioner

[Gix, Brian]

On Mon, 2020-03-02 at 20:25 +0530, Anupam Roy wrote:
> Hi Michal,
>  
> > --------- Original Message ---------
> > Sender : Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
> > Date : 2020-03-02 19:52 (GMT+5:30)
> > Title : Re: Regarding OOB authentication method & action for Mesh provisioner
> > 
> > Hi,
> > 
> > On 03/02, Anupam Roy wrote:
> > > Also, I would like to know, whether there is any plan to Request
> > > external provisioning Agent to choose Provisioning method & specific
> > > action?  The reason being, some *application* may be interested in a
> > > particular Security level & Authentication action, depending on its
> > > own I/O capabilities.
> > 
> > For the record, we also need this is functionality. One of the possible
> > scenarios is having a provisioner who doesn't have a reliable Internet
> > connection and might want to fall back to (less secure) OOB actions if
> > it cannot obtain OOB public key.
> > 
> > We've been planning to send a patch implementing a D-Bus API for that,
> > but it's not ready yet :(
> 
> Okay, that would be nice & and will it allow application to choose both a) "OOB Pub Key(With/Without)" as
> well as  b)"OOB Auth Methods(IN/OUT/Static/No OOB) & Actions(Blink/Beep/Vibrate/Num/alpha etc.)"?

The original plan for this was that an Agent defines it's Capabilities d-bus properties to indicate the OOB
methodologies it is willing to support *for that session*. If you *sometimes* want to support "static-oob" or
"public-oob" (for instance, to do a Certificate lookup via a WAN) then for that session, those capabilities
should be included in the Agent's Capabilities array...   and if the WAN is offline, and Certificates can't be
retrieved, then leave that capability out.

Otherwise, yes...  The *initiator* daemon then looks at the capabilities of the remote unprovisioned device,
and the capabilities of the local agent, and chooses the highest security method that can be supported between
the two devices.  But the list of available methods is still under the control of the App.

> 
> > regards
> > -- 
> > Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
> > Silvair 
> > https://protect2.fireeye.com/url?k=bcd496bf-e1422fc8-bcd51df0-0cc47a312ab0-f5d986cca20e804f&u=http://silvair.com/
> > Jasnogórska 44, 31-358 Krakow, POLAND

Re: Re: Regarding OOB authentication method & action for Mesh provisioner

[Stotland, Inga]

Hi,

On Mon, 2020-03-02 at 16:56 +0000, Gix, Brian wrote:
> On Mon, 2020-03-02 at 20:25 +0530, Anupam Roy wrote:
> > Hi Michal,
> >  
> > > --------- Original Message ---------
> > > Sender : Michał Lowas-Rzechonek <
> > > michal.lowas-rzechonek@silvair.com
> > > >
> > > Date : 2020-03-02 19:52 (GMT+5:30)
> > > Title : Re: Regarding OOB authentication method & action for Mesh
> > > provisioner
> > > 
> > > Hi,
> > > 
> > > On 03/02, Anupam Roy wrote:
> > > > Also, I would like to know, whether there is any plan to
> > > > Request
> > > > external provisioning Agent to choose Provisioning method &
> > > > specific
> > > > action?  The reason being, some *application* may be interested
> > > > in a
> > > > particular Security level & Authentication action, depending on
> > > > its
> > > > own I/O capabilities.
> > > 
> > > For the record, we also need this is functionality. One of the
> > > possible
> > > scenarios is having a provisioner who doesn't have a reliable
> > > Internet
> > > connection and might want to fall back to (less secure) OOB
> > > actions if
> > > it cannot obtain OOB public key.
> > > 
> > > We've been planning to send a patch implementing a D-Bus API for
> > > that,
> > > but it's not ready yet :(
> > 
> > Okay, that would be nice & and will it allow application to choose
> > both a) "OOB Pub Key(With/Without)" as
> > well as  b)"OOB Auth Methods(IN/OUT/Static/No OOB) &
> > Actions(Blink/Beep/Vibrate/Num/alpha etc.)"?
> 
> The original plan for this was that an Agent defines it's
> Capabilities d-bus properties to indicate the OOB
> methodologies it is willing to support *for that session*. If you
> *sometimes* want to support "static-oob" or
> "public-oob" (for instance, to do a Certificate lookup via a WAN)
> then for that session, those capabilities
> should be included in the Agent's Capabilities array...   and if the
> WAN is offline, and Certificates can't be
> retrieved, then leave that capability out.
> 
> Otherwise, yes...  The *initiator* daemon then looks at the
> capabilities of the remote unprovisioned device,
> and the capabilities of the local agent, and chooses the highest
> security method that can be supported between
> the two devices.  But the list of available methods is still under
> the control of the App.
> 

The daemon indeed is missing the dynamic acquisition of the
provisioner's agent capabilities. I think there is no need for a new D-
Bus method, the current API is sufficient. What is needed, is to add
call for GetProperty() request of "Capabilities" on the Agent interface
(in agent.c) prior to sending provisioning invite (in prov-initiator.c, 
before or in prov_init_open())

Regards,

Inga

Re: Re: Regarding OOB authentication method & action for Mesh provisioner

[Gix, Brian]

Hi Inga, and all,
On Mon, 2020-03-02 at 17:15 +0000, Stotland, Inga wrote:
> Hi,
> 
> On Mon, 2020-03-02 at 16:56 +0000, Gix, Brian wrote:
> > On Mon, 2020-03-02 at 20:25 +0530, Anupam Roy wrote:
> > > Hi Michal,
> > >  
> > > > --------- Original Message ---------
> > > > Sender : Michał Lowas-Rzechonek <
> > > > michal.lowas-rzechonek@silvair.com
> > > > Date : 2020-03-02 19:52 (GMT+5:30)
> > > > Title : Re: Regarding OOB authentication method & action for Mesh
> > > > provisioner
> > > > 
> > > > Hi,
> > > > 
> > > > On 03/02, Anupam Roy wrote:
> > > > > Also, I would like to know, whether there is any plan to
> > > > > Request
> > > > > external provisioning Agent to choose Provisioning method &
> > > > > specific
> > > > > action?  The reason being, some *application* may be interested
> > > > > in a
> > > > > particular Security level & Authentication action, depending on
> > > > > its
> > > > > own I/O capabilities.
> > > > 
> > > > For the record, we also need this is functionality. One of the
> > > > possible
> > > > scenarios is having a provisioner who doesn't have a reliable
> > > > Internet
> > > > connection and might want to fall back to (less secure) OOB
> > > > actions if
> > > > it cannot obtain OOB public key.
> > > > 
> > > > We've been planning to send a patch implementing a D-Bus API for
> > > > that,
> > > > but it's not ready yet :(
> > > 
> > > Okay, that would be nice & and will it allow application to choose
> > > both a) "OOB Pub Key(With/Without)" as
> > > well as  b)"OOB Auth Methods(IN/OUT/Static/No OOB) &
> > > Actions(Blink/Beep/Vibrate/Num/alpha etc.)"?
> > 
> > The original plan for this was that an Agent defines it's
> > Capabilities d-bus properties to indicate the OOB
> > methodologies it is willing to support *for that session*. If you
> > *sometimes* want to support "static-oob" or
> > "public-oob" (for instance, to do a Certificate lookup via a WAN)
> > then for that session, those capabilities
> > should be included in the Agent's Capabilities array...   and if the
> > WAN is offline, and Certificates can't be
> > retrieved, then leave that capability out.
> > 
> > Otherwise, yes...  The *initiator* daemon then looks at the
> > capabilities of the remote unprovisioned device,
> > and the capabilities of the local agent, and chooses the highest
> > security method that can be supported between
> > the two devices.  But the list of available methods is still under
> > the control of the App.
> > 
> 
> The daemon indeed is missing the dynamic acquisition of the
> provisioner's agent capabilities. I think there is no need for a new D-
> Bus method, the current API is sufficient. What is needed, is to add
> call for GetProperty() request of "Capabilities" on the Agent interface
> (in agent.c) prior to sending provisioning invite (in prov-initiator.c, 
> before or in prov_init_open())

Yes, after talking with Inga, this is absolutely correct:  I think we have everything in our existing API to
support full control by the Provisioner App as to what OOB methodology gets used...  But the functionality in
the prov-initator.c to use it is currently missing. 


> 
> Regards,
> 
> Inga
> 
> 

Re: Regarding OOB authentication method & action for Mesh provisioner

[michal.lowas-rzechonek]

Hi,

On 03/02, Gix, Brian wrote:
> > The daemon indeed is missing the dynamic acquisition of the
> > provisioner's agent capabilities. I think there is no need for a new
> > D- Bus method, the current API is sufficient. What is needed, is to
> > add call for GetProperty() request of "Capabilities" on the Agent
> > interface (in agent.c) prior to sending provisioning invite (in
> > prov-initiator.c, before or in prov_init_open())
> 
> Yes, after talking with Inga, this is absolutely correct:  I think we
> have everything in our existing API to support full control by the
> Provisioner App as to what OOB methodology gets used...  But the
> functionality in the prov-initator.c to use it is currently missing. 

Ack. Thanks for the explanation, we'll do it this way when we get to it.

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

RE: Re: Re: Regarding OOB authentication method & action for Mesh provisioner

[Anupam Roy]

 Hi Inga,
 
>--------- Original Message ---------
>Sender : Stotland, Inga <inga.stotland@intel.com>
>Date : 2020-03-02 22:45 (GMT+5:30)
>Title : Re: Re: Regarding OOB authentication method & action for Mesh provisioner
> 
>Hi,
> 
>On Mon, 2020-03-02 at 16:56 +0000, Gix, Brian wrote:
>> On Mon, 2020-03-02 at 20:25 +0530, Anupam Roy wrote:
>> > Hi Michal,
>> >  
>> > > --------- Original Message ---------
>> > > Sender : Michał Lowas-Rzechonek <
>> > > michal.lowas-rzechonek@silvair.com
>> > > >
>> > > Date : 2020-03-02 19:52 (GMT+5:30)
>> > > Title : Re: Regarding OOB authentication method & action for Mesh
>> > > provisioner
>> > > 
>> > > Hi,
>> > > 
>> > > On 03/02, Anupam Roy wrote:
>> > > > Also, I would like to know, whether there is any plan to
>> > > > Request
>> > > > external provisioning Agent to choose Provisioning method &
>> > > > specific
>> > > > action?  The reason being, some *application* may be interested
>> > > > in a
>> > > > particular Security level & Authentication action, depending on
>> > > > its
>> > > > own I/O capabilities.
>> > > 
>> > > For the record, we also need this is functionality. One of the
>> > > possible
>> > > scenarios is having a provisioner who doesn't have a reliable
>> > > Internet
>> > > connection and might want to fall back to (less secure) OOB
>> > > actions if
>> > > it cannot obtain OOB public key.
>> > > 
>> > > We've been planning to send a patch implementing a D-Bus API for
>> > > that,
>> > > but it's not ready yet :(
>> > 
>> > Okay, that would be nice & and will it allow application to choose
>> > both a) "OOB Pub Key(With/Without)" as
>> > well as  b)"OOB Auth Methods(IN/OUT/Static/No OOB) &
>> > Actions(Blink/Beep/Vibrate/Num/alpha etc.)"?
>> 
>> The original plan for this was that an Agent defines it's
>> Capabilities d-bus properties to indicate the OOB
>> methodologies it is willing to support *for that session*. If you
>> *sometimes* want to support "static-oob" or
>> "public-oob" (for instance, to do a Certificate lookup via a WAN)
>> then for that session, those capabilities
>> should be included in the Agent's Capabilities array...   and if the
>> WAN is offline, and Certificates can't be
>> retrieved, then leave that capability out.
>> 
>> Otherwise, yes...  The *initiator* daemon then looks at the
>> capabilities of the remote unprovisioned device,
>> and the capabilities of the local agent, and chooses the highest
>> security method that can be supported between
>> the two devices.  But the list of available methods is still under
>> the control of the App.
>> 
> 
>The daemon indeed is missing the dynamic acquisition of the
>provisioner's agent capabilities. I think there is no need for a new D-
>Bus method, the current API is sufficient. What is needed, is to add
>call for GetProperty() request of "Capabilities" on the Agent interface
>(in agent.c) prior to sending provisioning invite (in prov-initiator.c, 
>before or in prov_init_open())
>
Thanks for sharing your inputs. Actually, my point of view was allowing application to choose a particular methodology & action
based on *capabilities* received from the remote unprovisioned device *on runtime* (After receiving capabilities PDU from remote)
It seems, above may not be possible with the approach you have explained.

I think, by exposing agent properties, daemon will surely taking into consideration, the choice of provisioning agent, however,
choosing *final method & action* will still be in control of daemon by this approach, if I am understanding it correctly.
For instance, if both agent & node support OUT OOB with Blink/Beep/Vibrate, then daemon will have to internally decide on a specific *action*, if it choosing OUT OOB.
Also, between OUT/IN/Static OOB, dameon will have to internally decide on a method, may be applying some pre-defined security level? Please let me know if I am missing something. Thank You.

>Regards,
>Inga

Re: Regarding OOB authentication method & action for Mesh provisioner

[Gix, Brian]

Hi Anupam,
On Tue, 2020-03-03 at 14:48 +0530, Anupam Roy wrote:
>  Hi Inga,
> Sender : Stotland, Inga <inga.stotland@intel.com>
> > On Mon, 2020-03-02 at 16:56 +0000, Gix, Brian wrote:
> > > On Mon, 2020-03-02 at 20:25 +0530, Anupam Roy wrote:
> > > > Hi Michal,
> > > > Sender : Michał Lowas-Rzechonek <
> > > > > 
> > > > > On 03/02, Anupam Roy wrote:
> > > > > > Also, I would like to know, whether there is any plan to
> > > > > > Request
> > > > > > external provisioning Agent to choose Provisioning method &
> > > > > > specific
> > > > > > action?  The reason being, some *application* may be interested
> > > > > > in a
> > > > > > particular Security level & Authentication action, depending on
> > > > > > its
> > > > > > own I/O capabilities.
> > > > > 
> > > > > For the record, we also need this is functionality. One of the
> > > > > possible
> > > > > scenarios is having a provisioner who doesn't have a reliable
> > > > > Internet
> > > > > connection and might want to fall back to (less secure) OOB
> > > > > actions if
> > > > > it cannot obtain OOB public key.
> > > > > 
> > > > > We've been planning to send a patch implementing a D-Bus API for
> > > > > that,
> > > > > but it's not ready yet :(
> > > > 
> > > > Okay, that would be nice & and will it allow application to choose
> > > > both a) "OOB Pub Key(With/Without)" as
> > > > well as  b)"OOB Auth Methods(IN/OUT/Static/No OOB) &
> > > > Actions(Blink/Beep/Vibrate/Num/alpha etc.)"?
> > > 
> > > The original plan for this was that an Agent defines it's
> > > Capabilities d-bus properties to indicate the OOB
> > > methodologies it is willing to support *for that session*. If you
> > > *sometimes* want to support "static-oob" or
> > > "public-oob" (for instance, to do a Certificate lookup via a WAN)
> > > then for that session, those capabilities
> > > should be included in the Agent's Capabilities array...   and if the
> > > WAN is offline, and Certificates can't be
> > > retrieved, then leave that capability out.
> > > 
> > > Otherwise, yes...  The *initiator* daemon then looks at the
> > > capabilities of the remote unprovisioned device,
> > > and the capabilities of the local agent, and chooses the highest
> > > security method that can be supported between
> > > the two devices.  But the list of available methods is still under
> > > the control of the App.
> > > 
> > 
> > The daemon indeed is missing the dynamic acquisition of the
> > provisioner's agent capabilities. I think there is no need for a new D-
> > Bus method, the current API is sufficient. What is needed, is to add
> > call for GetProperty() request of "Capabilities" on the Agent interface
> > (in agent.c) prior to sending provisioning invite (in prov-initiator.c, 
> > before or in prov_init_open())
> > 
> Thanks for sharing your inputs. Actually, my point of view was allowing application to choose a particular
> methodology & action
> based on *capabilities* received from the remote unprovisioned device *on runtime* (After receiving
> capabilities PDU from remote)
> It seems, above may not be possible with the approach you have explained.

The provisioning happens pretty fast once the call on the Provisioner is made, and I am not sure what the
advantage would be to deciding *after* receiving remote capabilities, which capabilities *you* support.  As
Michał mentioned, it is true that if you *usually* can support an IP based OOB information exchange, but your
"WiFi is down", that you will want to do manual human OOB entry...  But in that case, remove the capabilities
that require WiFi from your agent capabilities *before* initiating provisioning. 

> 
> I think, by exposing agent properties, daemon will surely taking into consideration, the choice of
> provisioning agent, however,
> choosing *final method & action* will still be in control of daemon by this approach, if I am understanding
> it correctly.
> For instance, if both agent & node support OUT OOB with Blink/Beep/Vibrate, then daemon will have to
> internally decide on a specific *action*, if it choosing OUT OOB.

We may have a misunderstanding of terms here.  The application controls the "agent", and the node (as managed
by the daemon) only supports what the agent tells it to support.  The *remote* device being provisioned is the
only thing that may or may not match specific capabilities on the local agent.  And typically the local
provisioner's support of the various OUT OOB or IN OOB is simplistic on the Provisioner side...  

Most (if not all) remote devices will have only *one* of Blink, Beep, Vibrate, Out Numeric or out Alphabetic. 
Support on the Provisioner will indeed auto select one in the rare case that it supports more than one, and
will select the highest security.  But regardless, on the *Provisioner Side* you will basically just display a
string like:
"Enter the number of times remote device Blinked" for example.  

Same for IN OOB, except the action of the Provisioner will be to display a string like:
"Twist device X times" because the remote device has told us it has something that can be twisted.

For human entered OOB (on either side) we assume that the Provisioner is high functioning (has ability to
display any kind of string, and accept any kind of manual input) and the *if* either device is low functioning
it is the unprovisioned device, which will probably only have a single method of accepting or outputing OOB
data.

Either way, the Unprovisioned Beacon should tell the Provisioner all of the information it needs to know
(especially when combined with information like "My WiFi isn't working") to decide which capabilities to
include in it's agent.

What we don't want is to require an additional human interaction requiring a choice of what to use before
advancing to the input itself. We are trying to keep it to a single interaction.

> Also, between OUT/IN/Static OOB, dameon will have to internally decide on a method, may be applying some pre-
> defined security level? Please let me know if I am missing something. Thank You.

Both the Output Action and Input Action are arranged by value in order of level of security possible:
1. Lowest
	No Input/No Output

2. Still pretty low (random number from 0-9)
	Blink
	Beep
	Vibrate
	Push
	Twist

3. Pretty Good (random number between 0-99999999)
	Input Numeric
	Output Numeric

4. Even Better (random 8 char string incorporating 0-9, a-z, A-Z)
	Input Alphanumeric
	Output Alphanumeric

5. Best (Probably IP network delivered signed certificates or scanned barcodes)
	OOB Public Key
	OOB Static
	

> 
> > Regards,
> > Inga

RE: Re: Regarding OOB authentication method & action for Mesh provisioner

[Anupam Roy]

Hi Brian,

>Hi Anupam,
>On Tue, 2020-03-03 at 14:48 +0530, Anupam Roy wrote:
>>  Hi Inga,
>> Sender : Stotland, Inga <inga.stotland@intel.com>
>> > On Mon, 2020-03-02 at 16:56 +0000, Gix, Brian wrote:
>> > > On Mon, 2020-03-02 at 20:25 +0530, Anupam Roy wrote:
>> > > > Hi Michal,
>> > > > Sender : Michał Lowas-Rzechonek <
>> > > > > 
>> > > > > On 03/02, Anupam Roy wrote:
>> > > > > > Also, I would like to know, whether there is any plan to
>> > > > > > Request
>> > > > > > external provisioning Agent to choose Provisioning method &
>> > > > > > specific
>> > > > > > action?  The reason being, some *application* may be interested
>> > > > > > in a
>> > > > > > particular Security level & Authentication action, depending on
>> > > > > > its
>> > > > > > own I/O capabilities.
>> > > > > 
>> > > > > For the record, we also need this is functionality. One of the
>> > > > > possible
>> > > > > scenarios is having a provisioner who doesn't have a reliable
>> > > > > Internet
>> > > > > connection and might want to fall back to (less secure) OOB
>> > > > > actions if
>> > > > > it cannot obtain OOB public key.
>> > > > > 
>> > > > > We've been planning to send a patch implementing a D-Bus API for
>> > > > > that,
>> > > > > but it's not ready yet :(
>> > > > 
>> > > > Okay, that would be nice & and will it allow application to choose
>> > > > both a) "OOB Pub Key(With/Without)" as
>> > > > well as  b)"OOB Auth Methods(IN/OUT/Static/No OOB) &
>> > > > Actions(Blink/Beep/Vibrate/Num/alpha etc.)"?
>> > > 
>> > > The original plan for this was that an Agent defines it's
>> > > Capabilities d-bus properties to indicate the OOB
>> > > methodologies it is willing to support *for that session*. If you
>> > > *sometimes* want to support "static-oob" or
>> > > "public-oob" (for instance, to do a Certificate lookup via a WAN)
>> > > then for that session, those capabilities
>> > > should be included in the Agent's Capabilities array...   and if the
>> > > WAN is offline, and Certificates can't be
>> > > retrieved, then leave that capability out.
>> > > 
>> > > Otherwise, yes...  The *initiator* daemon then looks at the
>> > > capabilities of the remote unprovisioned device,
>> > > and the capabilities of the local agent, and chooses the highest
>> > > security method that can be supported between
>> > > the two devices.  But the list of available methods is still under
>> > > the control of the App.
>> > > 
>> > 
>> > The daemon indeed is missing the dynamic acquisition of the
>> > provisioner's agent capabilities. I think there is no need for a new D-
>> > Bus method, the current API is sufficient. What is needed, is to add
>> > call for GetProperty() request of "Capabilities" on the Agent interface
>> > (in agent.c) prior to sending provisioning invite (in prov-initiator.c, 
>> > before or in prov_init_open())
>> > 
>> Thanks for sharing your inputs. Actually, my point of view was allowing application to choose a particular
>> methodology & action
>> based on *capabilities* received from the remote unprovisioned device *on runtime* (After receiving
>> capabilities PDU from remote)
>> It seems, above may not be possible with the approach you have explained.
>
>The provisioning happens pretty fast once the call on the Provisioner is made, and I am not sure what the
>advantage would be to deciding *after* receiving remote capabilities, which capabilities *you* support.  As
>Michał mentioned, it is true that if you *usually* can support an IP based OOB information exchange, but your
>"WiFi is down", that you will want to do manual human OOB entry...  But in that case, remove the capabilities
>that require WiFi from your agent capabilities *before* initiating provisioning. 
>
Agreed!

>> 
>> I think, by exposing agent properties, daemon will surely taking into consideration, the choice of
>> provisioning agent, however,
>> choosing *final method & action* will still be in control of daemon by this approach, if I am understanding
>> it correctly.
>> For instance, if both agent & node support OUT OOB with Blink/Beep/Vibrate, then daemon will have to
>> internally decide on a specific *action*, if it choosing OUT OOB.
>
>We may have a misunderstanding of terms here.  The application controls the "agent", and the node (as managed
>by the daemon) only supports what the agent tells it to support.  The *remote* device being provisioned is the
>only thing that may or may not match specific capabilities on the local agent.  And typically the local
>provisioner's support of the various OUT OOB or IN OOB is simplistic on the Provisioner side...  
>
>Most (if not all) remote devices will have only *one* of Blink, Beep, Vibrate, Out Numeric or out Alphabetic. 
>Support on the Provisioner will indeed auto select one in the rare case that it supports more than one, and
>will select the highest security.  But regardless, on the *Provisioner Side* you will basically just display a
>string like:
>"Enter the number of times remote device Blinked" for example.  
>
>Same for IN OOB, except the action of the Provisioner will be to display a string like:
>"Twist device X times" because the remote device has told us it has something that can be twisted.
>
>For human entered OOB (on either side) we assume that the Provisioner is high functioning (has ability to
>display any kind of string, and accept any kind of manual input) and the *if* either device is low functioning
>it is the unprovisioned device, which will probably only have a single method of accepting or outputing OOB
>data.
>
>Either way, the Unprovisioned Beacon should tell the Provisioner all of the information it needs to know
>(especially when combined with information like "My WiFi isn't working") to decide which capabilities to
>include in it's agent.
>
>What we don't want is to require an additional human interaction requiring a choice of what to use before
>advancing to the input itself. We are trying to keep it to a single interaction.
>
Thank you for such detailed explanation. Indeed, avoiding additional Human interaction will be desired to speed up the whole process.

>> Also, between OUT/IN/Static OOB, dameon will have to internally decide on a method, may be applying some pre-
>> defined security level? Please let me know if I am missing something. Thank You.
>
>Both the Output Action and Input Action are arranged by value in order of level of security possible:
>1. Lowest
>	No Input/No Output
>
>2. Still pretty low (random number from 0-9)
>	Blink
>	Beep
>	Vibrate
>	Push
>	Twist
>
>3. Pretty Good (random number between 0-99999999)
>	Input Numeric
>	Output Numeric
>
>4. Even Better (random 8 char string incorporating 0-9, a-z, A-Z)
>	Input Alphanumeric
>	Output Alphanumeric
>
>5. Best (Probably IP network delivered signed certificates or scanned barcodes)
>	OOB Public Key
>	OOB Static
>	
>
Yes, I can understand the OOB security level is already handled well in the daemon.
Thank you very much for your detailed response!
>> 
>> > Regards,
>> > Inga

BR,
-Anupam Roy

RE: RE: Re: Mesh Key Refreshment procedure from Config client

[Anupam Roy]

 
Hi Inga,

>--------- Original Message ---------
>Sender : Anupam Roy <anupam.r@samsung.com> Staff Engineer/Application S/W Group /SRI-Delhi/Samsung Electronics
>Date : 2020-03-27 11:07 (GMT+5:30)
>Title : RE: Re: Mesh Key Refreshment procedure from Config client
> 
>Hi Inga,
> 
>> 
>>Hi Anupam,
>> 
>>On Thu, 2020-03-26 at 20:22 +0530, Anupam Roy wrote:
>>> Hi ,
>>>  Presently, I am trying to check *Key Refreshment Procedure* from Mesh Config client.
>>> 
>>> For checking the operation, I did following steps
>>>  - Create Subnet in Config client at Net index 1
>>>  - Add SubNetKey to Local Node at Net Index 1
>>>  - Add SubNetKey to Remote Node at Net Index 1
>>> 
>> 
>>Please try to add two steps more here:
>>   - Update Subnet 1 (subnet-update command in main menu)
>I missed mentioning above step in my email. Actually, before updating netkey to remote, I did update local subnet.
>But yes, I missed out below step (Updating netkey to local node). Will give it a try now. Much thanks!
>

After updating the Netkey to the local node(config client) and then to the remote node, I monitored the beaconing key used by local config client.
Please note that since, only two netkeys are at presently configured in both the nodes, therefore, the key ID's are 1 (for primary netkey at index 0), 2(For Netkey at index 1) & 3(For new NetKey at index 1).

After NetKey update, The KR phase in both sides are set to 1, but it seems, the new key id (which is 3 in this case) is still *NOT used for beaconing, by the 'Config Client node'
Config Client still keeps on beaconing with key ID 1 & 2. Sharing a bit of logs for your reference.

During NetKey Update-
mesh/cfgmod-server.c:cfg_srv_pkt() CONFIG-SRV-opcode 0x8045 size 18 idx 000
key refresh phase 1: Key ID 3

Beacon Keys after NetKey update on remote Node -
mesh/net-keys.c:snb_timeout() beacon 2 for 1 nodes, period 30, obs 2, exp 3
mesh/net-keys.c:snb_timeout() beacon 1 for 1 nodes, period 20, obs 2, exp 2

Please share your opinion to check the issue further. Thank You
 
>>   - Update NetKey 1 for a local node (switch to config menu)
>> 
>>>  - Update Netkey to remote Node in Net index 1
>>> 
>>> After updating the Netkey, I believe, config client has to either send out SNB with KeyRefreshment(KR) Flag=1 & secured with updated NetKey (i.e by subnet->net_key_upd id)
>>> or send out "Config Key Refresh Phase Set" with transition parameter, set to 2. I could not find the later provision in cfgclient menu.
>>> However, Config Client seems to be not sending out Secure Network Beacon as well. So KR procedure seems to be not progressing at my setup at present.
>>> 
>>> Any hint of what could be missing will be really helpful! Thank You.
>>> 
>> 
>>Best Regards,
>>Inga

BR,
-Anupam Roy

Re: RE: Re: Mesh Key Refreshment procedure from Config client

[Stotland, Inga]

Hi Anupam,

On Fri, 2020-03-27 at 19:17 +0530, Anupam Roy wrote:
>  
> Hi Inga,
> 
> > --------- Original Message ---------
> > Sender : Anupam Roy <
> > anupam.r@samsung.com
> > > Staff Engineer/Application S/W Group /SRI-Delhi/Samsung
> > Electronics
> > Date : 2020-03-27 11:07 (GMT+5:30)
> > Title : RE: Re: Mesh Key Refreshment procedure from Config client
> > 
> > Hi Inga,
> > 
> > > Hi Anupam,
> > > 
> > > On Thu, 2020-03-26 at 20:22 +0530, Anupam Roy wrote:
> > > > Hi ,
> > > >  Presently, I am trying to check *Key Refreshment Procedure*
> > > > from Mesh Config client.
> > > > 
> > > > For checking the operation, I did following steps
> > > >  - Create Subnet in Config client at Net index 1
> > > >  - Add SubNetKey to Local Node at Net Index 1
> > > >  - Add SubNetKey to Remote Node at Net Index 1
> > > > 
> > > 
> > > Please try to add two steps more here:
> > >   - Update Subnet 1 (subnet-update command in main menu)
> > 
> > I missed mentioning above step in my email. Actually, before
> > updating netkey to remote, I did update local subnet.
> > But yes, I missed out below step (Updating netkey to local node).
> > Will give it a try now. Much thanks!
> > 
> 
> After updating the Netkey to the local node(config client) and then
> to the remote node, I monitored the beaconing key used by local
> config client.
> Please note that since, only two netkeys are at presently configured
> in both the nodes, therefore, the key ID's are 1 (for primary netkey
> at index 0), 2(For Netkey at index 1) & 3(For new NetKey at index 1).
> 
> After NetKey update, The KR phase in both sides are set to 1, but it
> seems, the new key id (which is 3 in this case) is still *NOT used
> for beaconing, by the 'Config Client node'
> Config Client still keeps on beaconing with key ID 1 & 2. Sharing a
> bit of logs for your reference.
> 
> During NetKey Update-
> mesh/cfgmod-server.c:cfg_srv_pkt() CONFIG-SRV-opcode 0x8045 size 18
> idx 000
> key refresh phase 1: Key ID 3
> 
> Beacon Keys after NetKey update on remote Node -
> mesh/net-keys.c:snb_timeout() beacon 2 for 1 nodes, period 30, obs 2,
> exp 3
> mesh/net-keys.c:snb_timeout() beacon 1 for 1 nodes, period 20, obs 2,
> exp 2
> 
> Please share your opinion to check the issue further. Thank You

Indeed, there's a missing functionality in mesh-cfgclient tool: key
refresh phase commands.
The patch set  that I posted today should address the issue:
[PATCH BlueZ 1/2] tools/mesh-cfgclient: Save subnet key refresh phase
[PATCH BlueZ 2/2] tools/mesh-cfgclient: Add commands for Key Refresh
Phase

The beaconing will start  updated network key once the Key Refresh
procedure advances to phase 2:
1. "subnet-set_phase <net_index> 2" from the main menu
2. "kr_phase_set <net_index> 2" from  the config menu (sent to either
local or remote node or both).
     The transition to phase 2 can happen either as a result of a
directly setting a phase on a node or by
     detecting a beacon with KR bit set (which, of course assumes that
at least one node got it's phase set
    directly and that that node has beaconing enabled) .

Similar steps to finish Key Refresh procedure: set phase 3 for subnet
and send phase command to node(s)


>  
> > >   - Update NetKey 1 for a local node (switch to config menu)
> > > 
> > > >  - Update Netkey to remote Node in Net index 1
> > > > 
> > > > After updating the Netkey, I believe, config client has to
> > > > either send out SNB with KeyRefreshment(KR) Flag=1 & secured
> > > > with updated NetKey (i.e by subnet->net_key_upd id)
> > > > or send out "Config Key Refresh Phase Set" with transition
> > > > parameter, set to 2. I could not find the later provision in
> > > > cfgclient menu.
> > > > However, Config Client seems to be not sending out Secure
> > > > Network Beacon as well. So KR procedure seems to be not
> > > > progressing at my setup at present.
> > > > 
> > > > Any hint of what could be missing will be really helpful! Thank
> > > > You.
> > > > 
> > > 
> > > Best Regards,
> > > Inga
> 
> BR,
> -Anupam Roy

RE: Re: RE: Re: Mesh Key Refreshment procedure from Config client

[Anupam Roy]

Hi Inga,

>--------- Original Message ---------
>Sender : Stotland, Inga <inga.stotland@intel.com>
>Date : 2020-03-30 11:35 (GMT+5:30)
>Title : Re: RE: Re: Mesh Key Refreshment procedure from Config client
> 
>Hi Anupam,
> 
>On Fri, 2020-03-27 at 19:17 +0530, Anupam Roy wrote:
>>  
>> Hi Inga,
>> 
>> > --------- Original Message ---------
>> > Sender : Anupam Roy <
>> > anupam.r@samsung.com
>> > > Staff Engineer/Application S/W Group /SRI-Delhi/Samsung
>> > Electronics
>> > Date : 2020-03-27 11:07 (GMT+5:30)
>> > Title : RE: Re: Mesh Key Refreshment procedure from Config client
>> > 
>> > Hi Inga,
>> > 
>> > > Hi Anupam,
>> > > 
>> > > On Thu, 2020-03-26 at 20:22 +0530, Anupam Roy wrote:
>> > > > Hi ,
>> > > >  Presently, I am trying to check *Key Refreshment Procedure*
>> > > > from Mesh Config client.
>> > > > 
>> > > > For checking the operation, I did following steps
>> > > >  - Create Subnet in Config client at Net index 1
>> > > >  - Add SubNetKey to Local Node at Net Index 1
>> > > >  - Add SubNetKey to Remote Node at Net Index 1
>> > > > 
>> > > 
>> > > Please try to add two steps more here:
>> > >   - Update Subnet 1 (subnet-update command in main menu)
>> > 
>> > I missed mentioning above step in my email. Actually, before
>> > updating netkey to remote, I did update local subnet.
>> > But yes, I missed out below step (Updating netkey to local node).
>> > Will give it a try now. Much thanks!
>> > 
>> 
>> After updating the Netkey to the local node(config client) and then
>> to the remote node, I monitored the beaconing key used by local
>> config client.
>> Please note that since, only two netkeys are at presently configured
>> in both the nodes, therefore, the key ID's are 1 (for primary netkey
>> at index 0), 2(For Netkey at index 1) & 3(For new NetKey at index 1).
>> 
>> After NetKey update, The KR phase in both sides are set to 1, but it
>> seems, the new key id (which is 3 in this case) is still *NOT used
>> for beaconing, by the 'Config Client node'
>> Config Client still keeps on beaconing with key ID 1 & 2. Sharing a
>> bit of logs for your reference.
>> 
>> During NetKey Update-
>> mesh/cfgmod-server.c:cfg_srv_pkt() CONFIG-SRV-opcode 0x8045 size 18
>> idx 000
>> key refresh phase 1: Key ID 3
>> 
>> Beacon Keys after NetKey update on remote Node -
>> mesh/net-keys.c:snb_timeout() beacon 2 for 1 nodes, period 30, obs 2,
>> exp 3
>> mesh/net-keys.c:snb_timeout() beacon 1 for 1 nodes, period 20, obs 2,
>> exp 2
>> 
>> Please share your opinion to check the issue further. Thank You
> 
>Indeed, there's a missing functionality in mesh-cfgclient tool: key
>refresh phase commands.
>The patch set  that I posted today should address the issue:
>[PATCH BlueZ 1/2] tools/mesh-cfgclient: Save subnet key refresh phase
>[PATCH BlueZ 2/2] tools/mesh-cfgclient: Add commands for Key Refresh
>Phase
> 
>The beaconing will start  updated network key once the Key Refresh
>procedure advances to phase 2:
>1. "subnet-set_phase <net_index> 2" from the main menu
>2. "kr_phase_set <net_index> 2" from  the config menu (sent to either
>local or remote node or both).
>     The transition to phase 2 can happen either as a result of a
>directly setting a phase on a node or by
>     detecting a beacon with KR bit set (which, of course assumes that
>at least one node got it's phase set
>    directly and that that node has beaconing enabled) .
> 
>Similar steps to finish Key Refresh procedure: set phase 3 for subnet
>and send phase command to node(s)
> 
Sure, will try this. Thanks for the update & detailed response.

> 
>>  
>> > >   - Update NetKey 1 for a local node (switch to config menu)
>> > > 
>> > > >  - Update Netkey to remote Node in Net index 1
>> > > > 
>> > > > After updating the Netkey, I believe, config client has to
>> > > > either send out SNB with KeyRefreshment(KR) Flag=1 & secured
>> > > > with updated NetKey (i.e by subnet->net_key_upd id)
>> > > > or send out "Config Key Refresh Phase Set" with transition
>> > > > parameter, set to 2. I could not find the later provision in
>> > > > cfgclient menu.
>> > > > However, Config Client seems to be not sending out Secure
>> > > > Network Beacon as well. So KR procedure seems to be not
>> > > > progressing at my setup at present.
>> > > > 
>> > > > Any hint of what could be missing will be really helpful! Thank
>> > > > You.
>> > > > 
>> > > 
>> > > Best Regards,
>> > > Inga
>> 
>> BR,
>> -Anupam Roy
 

RE: Re: Mesh Key Refreshment procedure from Config client

[Anupam Roy]

Hi Inga,

> 
>Hi Anupam,
> 
>On Thu, 2020-03-26 at 20:22 +0530, Anupam Roy wrote:
>> Hi ,
>>  Presently, I am trying to check *Key Refreshment Procedure* from Mesh Config client.
>> 
>> For checking the operation, I did following steps
>>  - Create Subnet in Config client at Net index 1
>>  - Add SubNetKey to Local Node at Net Index 1
>>  - Add SubNetKey to Remote Node at Net Index 1
>> 
> 
>Please try to add two steps more here:
>   - Update Subnet 1 (subnet-update command in main menu)
I missed mentioning above step in my email. Actually, before updating netkey to remote, I did update local subnet.
But yes, I missed out below step (Updating netkey to local node). Will give it a try now. Much thanks!

>   - Update NetKey 1 for a local node (switch to config menu)
> 
>>  - Update Netkey to remote Node in Net index 1
>> 
>> After updating the Netkey, I believe, config client has to either send out SNB with KeyRefreshment(KR) Flag=1 & secured with updated NetKey (i.e by subnet->net_key_upd id)
>> or send out "Config Key Refresh Phase Set" with transition parameter, set to 2. I could not find the later provision in cfgclient menu.
>> However, Config Client seems to be not sending out Secure Network Beacon as well. So KR procedure seems to be not progressing at my setup at present.
>> 
>> Any hint of what could be missing will be really helpful! Thank You.
>> 
> 
>Best Regards,
>Inga
 

Mesh Key Refreshment procedure from Config client

[Anupam Roy]

Hi ,
 Presently, I am trying to check *Key Refreshment Procedure* from Mesh Config client.

For checking the operation, I did following steps
 - Create Subnet in Config client at Net index 1
 - Add SubNetKey to Local Node at Net Index 1
 - Add SubNetKey to Remote Node at Net Index 1
 - Update Netkey to remote Node in Net index 1

After updating the Netkey, I believe, config client has to either send out SNB with KeyRefreshment(KR) Flag=1 & secured with updated NetKey (i.e by subnet->net_key_upd id)
or send out "Config Key Refresh Phase Set" with transition parameter, set to 2. I could not find the later provision in cfgclient menu.
However, Config Client seems to be not sending out Secure Network Beacon as well. So KR procedure seems to be not progressing at my setup at present.

Any hint of what could be missing will be really helpful! Thank You.

BR,
-Anupam Roy

Re: Mesh Key Refreshment procedure from Config client

[Stotland, Inga]

Hi Anupam,

On Thu, 2020-03-26 at 20:22 +0530, Anupam Roy wrote:
> Hi ,
>  Presently, I am trying to check *Key Refreshment Procedure* from Mesh Config client.
> 
> For checking the operation, I did following steps
>  - Create Subnet in Config client at Net index 1
>  - Add SubNetKey to Local Node at Net Index 1
>  - Add SubNetKey to Remote Node at Net Index 1
> 

Please try to add two steps more here:
   - Update Subnet 1 (subnet-update command in main menu)
   - Update NetKey 1 for a local node (switch to config menu)

>  - Update Netkey to remote Node in Net index 1
> 
> After updating the Netkey, I believe, config client has to either send out SNB with KeyRefreshment(KR) Flag=1 & secured with updated NetKey (i.e by subnet->net_key_upd id)
> or send out "Config Key Refresh Phase Set" with transition parameter, set to 2. I could not find the later provision in cfgclient menu.
> However, Config Client seems to be not sending out Secure Network Beacon as well. So KR procedure seems to be not progressing at my setup at present.
> 
> Any hint of what could be missing will be really helpful! Thank You.
> 

Best Regards,
Inga