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. > > 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
