Hi Inga, >--------- Original Message --------- >Sender : Stotland, Inga <inga.stotland@xxxxxxxxx> >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@xxxxxxxxxxx >> > > > >> > > 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
