Re: [PATCH 11/21] doc: PKEX support for DPP

[James Prestwood <prestwoj@gmail.com>]

Hi Denis,

On 10/19/23 7:59 AM, Denis Kenzior wrote:
> Hi James,
> 
> On 10/12/23 15:01, James Prestwood wrote:
>> PKEX is part of the WFA EasyConnect specification and is
>> an additional boostrapping method (like QR codes) for
>> exchanging public keys between a configurator and enrollee.
>>
>> PKEX operates over wifi and requires a key/code be exchanged
>> prior to the protocol. The key is used to encrypt the exchange
>> of the boostrapping information, then DPP authentication is
>> started immediately aftewards.
>>
>> This can be useful for devices which don't have the ability to
>> scan a QR code, or even as a more convenient way to share
>> wireless credentials if the PSK is very secure (i.e. not a
>> human readable string).
>>
>> PKEX would be used via the two DBus APIs on a new interface
>> SharedCodeDeviceProvisioning.
>>
>> StartConfigurator() will start listening and wait for an
>> Enrollee to send a PKEX exchange request.
>>
>> StartEnrollee() will initiate the exchange.
>>
>> PKEX would proceed and once done DPP Authentication will start
>> using the boostrapping keys exchanged.
>> ---
>>   doc/device-provisioning-api.txt | 30 ++++++++++++++++++++++++++++++
>>   1 file changed, 30 insertions(+)
>>
>> diff --git a/doc/device-provisioning-api.txt 
>> b/doc/device-provisioning-api.txt
>> index ac204f46..4c0ecb28 100644
>> --- a/doc/device-provisioning-api.txt
>> +++ b/doc/device-provisioning-api.txt
>> @@ -71,3 +71,33 @@ Properties    boolean Started [readonly]
>>               Indicates the DPP URI. This property is only available
>>               when Started is true.
>> +
>> +
>> +Interface    net.connman.iwd.DeviceProvisioning [Experimental]
> 
> nit: [experimental]
> 
>> +Object path    /net/connman/iwd/{phy0,phy1,...}/{1,2,...}
>> +
>> +        StartConfigurator()
>> +            Start a PKEX configurator. IWD must be currently
>> +            connected to a BSS and have at least the
> 
> To a network?
> 
>> +            [Security].DeviceProvisioningSharedCode option set in
>> +            the network profile. An identifier can be set with
>> +            [Security].DeviceProvisioningIdentifier.
> 
> I would think [DeviceProvisioning] SharedCode and Identifier?
> 
> But I do have to ask, this is used for PSK networks where profiles are 
> rarely touched by the user.  Do you really expect someone to muck around 
> in them?  I wonder if autogenerating such codes / identifiers or an 
> Agent API is more appropriate?

Autogeneration really won't work since both peers have to match.

For my needs the code/key is baked into the device image (i.e. a config 
file) so putting it into the .psk file would work great mainly because 
IWD could encrypt it (by adding "DeviceProvisioning" to the list of 
groups for profile encryption).

But for a human user the shared code does make sense to come from an 
agent, or the StartConfigurator() API itself. The use case here that 
comes to mind is sharing wifi credentials when your PSK is a very secure 
random string and you don't want to have someone type that in.

Could we support both like how we do with PSKs already? If not in the 
config file ask the agent?

> 
>> +
>> +            Possible errors:    net.connman.iwd.Busy
>> +                        net.connman.iwd.NotConnected
>> +                        net.connman.iwd.InvalidArguments
>> +                        net.connman.iwd.NotConfigured
>> +
>> +        StartEnrollee(a{sv} args)
>> +            The 'args' dictionary contains parameters for the PKEX
>> +            enrollee.
>> +
>> +            string Key - The PKEX key. This is required and must
>> +            match the configurer's key.
> 
> Why is this not symmetric with Configurator role?  I assume this should 
> be SharedCode?
> 
>> +
>> +            string Identifier - The PKEX key identifier. This is > 
>> +            optional, but if used both the Configurer and enrollee
> 
> Configurator?
> 
>> +            must use the same value.
>> +
>> +            Possible errors:    net.connman.iwd.Busy
>> +                        net.connman.iwd.InvalidArguments
>> \ No newline at end of file
> 
> Regards,
> -Denis