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
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 <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
Hi Michal,
>--------- Original Message ---------
>Sender : Michał Lowas-Rzechonek <[email protected]>
>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 <[email protected]>
>Silvair https://protect2.fireeye.com/url?k=bcd496bf-e1422fc8-bcd51df0-0cc47a312ab0-f5d986cca20e804f&u=http://silvair.com/
>Jasnogórska 44, 31-358 Krakow, POLAND
On Mon, 2020-03-02 at 20:25 +0530, Anupam Roy wrote:
> Hi Michal,
>
> > --------- Original Message ---------
> > Sender : Michał Lowas-Rzechonek <[email protected]>
> > 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 <[email protected]>
> > Silvair
> > https://protect2.fireeye.com/url?k=bcd496bf-e1422fc8-bcd51df0-0cc47a312ab0-f5d986cca20e804f&u=http://silvair.com/
> > Jasnogórska 44, 31-358 Krakow, POLAND
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 <
> > > [email protected]
> > > >
> > > 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
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 <
> > > > [email protected]
> > > > 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
>
>
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 <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND
Hi Inga,
>--------- Original Message ---------
>Sender : Stotland, Inga <[email protected]>
>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 <
>> > > [email protected]
>> > > >
>> > > 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
Hi Anupam,
On Tue, 2020-03-03 at 14:48 +0530, Anupam Roy wrote:
> Hi Inga,
> Sender : Stotland, Inga <[email protected]>
> > 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
Hi Brian,
>Hi Anupam,
>On Tue, 2020-03-03 at 14:48 +0530, Anupam Roy wrote:
>> Hi Inga,
>> Sender : Stotland, Inga <[email protected]>
>> > 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