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

[Anupam Roy <anupam.r@samsung.com>]

 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