Hi Brian, >Hi Anupam, >On Tue, 2020-03-03 at 14:48 +0530, Anupam Roy wrote: >> Hi Inga, >> Sender : Stotland, Inga <inga.stotland@xxxxxxxxx> >> > 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
