From: James Prestwood <prestwoj@gmail.com>
To: Denis Kenzior <denkenz@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH] RFC: PKEX support for DPP
Date: Fri, 6 Oct 2023 09:14:14 -0700 [thread overview]
Message-ID: <c54e631d-5b39-4630-bb75-cf810839b1d4@gmail.com> (raw)
In-Reply-To: <50060562-b877-e087-82a6-c526779c1038@gmail.com>
On 10/6/23 7:55 AM, Denis Kenzior wrote:
> Hi James,
>
> On 10/5/23 07:30, 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).
>>
>> This only documents the DBus API for now to get an idea of how
>> and where this module would live. The current plan is to keep
>> it in dpp.c. This module is getting rather large but all the
>> infrastructure exists for offchannel/frame callbacks and
>> state so it makes sense to keep it there. The plan is to add
>> some additional states to dpp for PKEX which would happen
>> prior to AUTHENTICATION and allow the PRESENCE state to be
>> skipped.
>>
>
> Sounds good.
>
>> PKEX would be used via the two DBus APIs. PkexConfigure would
>> start listening and wait for an Enrollee to send a PKEX
>> exchange request. The enrollee would be started with PkexEnroll
>> and initiate the exchange. PKEX would proceed and once done
>> DPP Authentication would start using the boostrapping keys
>> exchanged.
>
> I would really like to avoid camel case abbreviations in APIs. Also, we
> like to use more easily understood terminology in our APIs whenever
> possible. For example, SignalStrength not RSSI, SimpleConfiguration not
> WSC, etc. Also, this is very different in feel compared to the rest of
> DeviceProvisioning Methods.
>
> Perhaps this should be moved to its own interface, something like
> SharedCodeDeviceProvisioning.
Sounds good.
>
>>
>> For convenience/security the PKEX key could be specified in the
>> IWD provisioning file (part of the Security group). This would
>
> Why don't you just make this the default and drop the dictionary
> parameters.
>
>> allow IWD to encrypt it and avoid the need for some other entity
>> to store the key in order to call PkexConfigure (e.g. if not
>> initiated by a human entering the key).
>> ---
>> doc/device-provisioning-api.txt | 44 +++++++++++++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/doc/device-provisioning-api.txt
>> b/doc/device-provisioning-api.txt
>> index ac204f46..c8b2e4a5 100644
>> --- a/doc/device-provisioning-api.txt
>> +++ b/doc/device-provisioning-api.txt
>> @@ -57,6 +57,50 @@ Methods string StartEnrollee()
>> net.connman.iwd.NotSupported
>> net.connman.iwd.Busy
>> + PkexConfigure(dict args)
>> + The 'args' dictionary (a{sv}) contains parameters for
>> + the PKEX configurer. This can be empty or contain the
>> + following dictionary members:
>> +
>> + string Key - The PKEX key. This is required if not
>> + specified in the network profile already.
>> +
>> + string Identifier - The PKEX key identifier. This is
>> + optional, but if used both the Configurer and enrollee
>> + must use the same value. Can also be specified in the
>> + network profile.
>> +
>> + uint32_t Timeout - A timeout (in seconds) for
>> + configuration. This is optional, but suggested to
>> + prevent a device from indefinitely configuring
>> + enrollees (if Stop() was never called).
>
> I would pick something reasonable (or read it from the provisioning
> file) and drop this from the API entirely.
>
>> +
>> + Possible errors: net.connman.iwd.Busy
>> + net.connman.iwd.NotConnected
>> + net.connman.iwd.InvalidArguments
>> + net.connman.iwd.NotConfigured
>> +
>> + PkexEnroll(dict args)
>> + The 'args' dictionary (a{sv}) contains parameters for
>> + the PKEX enrollee.
>> +
>> + string Key - The PKEX key. This is required and must
>> + match the configurer's key.
>> +
>> + string Identifier - The PKEX key identifier. This is
>> + optional, but if used both the Configurer and enrollee
>
> "configurator"
>
>> + must use the same value.
>> +
>> + array(y) Address - The address of the PKEX listener. If
>> + not specified a broadcast address is used.
>
> array(y)? Nack :)
>
>> +
>> + array(u) Frequencies - A list of frequencies to
>> + discover on. If not specified channel 2, 44, and 149
>> + are used per the DPP spec.
>
> Same here.
>
> I would drop Address and Frequencies from this API. No human is going
> to be entering these via a UI.
The issue I foresee is trying to find configurators since they stay on
the current operating channel which likely isn't 2, 44, or 149 (I
suppose we could have them go offchannel, but I wanted to avoid that).
But I agree, its not something a human would know or want to type in.
Enrollees could instead iterate all supported channels, but that would
take a while (200ms per channel per the spec, and actually the spec
wants 5 retries per channel but I wasn't planning on doing that). But
maybe this is the only way to do it in an automatic way.
One idea I had was to have the enrollee scan first, iterate channels
from nearby APs, if nothing is found repeat. That would likely reduce
the number of frequencies significantly.
>
>> +
>> + Possible errors: net.connman.iwd.Busy
>> + net.connman.iwd.InvalidArguments
>> +
>> Properties boolean Started [readonly]
>> True if DPP is currently active.
>
> Regards,
> -Denis
prev parent reply other threads:[~2023-10-06 16:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 12:30 [PATCH] RFC: PKEX support for DPP James Prestwood
2023-10-06 14:55 ` Denis Kenzior
2023-10-06 16:14 ` James Prestwood [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c54e631d-5b39-4630-bb75-cf810839b1d4@gmail.com \
--to=prestwoj@gmail.com \
--cc=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).