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

[James Prestwood <prestwoj@gmail.com>]

Hi Denis,

On 10/19/23 11:56 AM, Denis Kenzior wrote:
> Hi James,
> 
>>
>> I guess my question is really how you communicate this to the enrollee.
>>
>> The use case for a human user really comes down to not wanting to type 
>> in a 64 character hex string :) So auto-generating a complex code 
>> doesn't make much sense in this regard.
> 
> Who said anything about a 64 character hex?  I'm thinking more about a 
> 10-12 character complex password like you see the web browser generate.  
> However, I'm pretty sure we need the ability to generate the code every 
> time:
> 
> "If both sides have a user interface, this technique can be used to 
> bootstrap trust by exchanging bootstrapping information including the 
> bootstrapping keys that are to be used for a DPP exchange requiring 
> mutual authentication. This bootstrapping technique shall use a fresh 
> code each time and the same code shall not be used with different Peers."
> 
> Correct me if I'm wrong, but PKEX is no different than regular DPP.  It 
> simply uses a code instead of a QR code for establishing the initial 
> trust channel (giving high degree of confidence to both parties that the 
> exchanged public keys are trusted).  The more complex the code, the 
> better the chance that the code can be trusted (i.e. it wasn't 
> guessed).  It still inherits the same basic attributes, roles, etc.

Yep, its purely a way to securely exchange bootstrapping keys.

> 
> 
>>
>> For a headless device auto-generation just won't work since the 
>> password is baked into the image. I considered generating a single 
>> bootstrapping key and 
> 
> Doesn't this run counter to what PKEX is about?

I don't think it runs counter, it just may not be _exactly_ what the 
spec intended it to be used for. Using the same code isn't any different 
than using the same PSK.

No matter what if your PSK or PKEX code gets compromised your stuck 
re-configuring all your devices. I don't see an issue using a secure but 
static PKEX code. Either way, this isn't really IWD's problem :)

> 
>> bake that into the image (no PKEX) but I question the possibility of 
>> offline 
> 
> With a strong password, probably eons, unless quantum computing is 
> involved.
> 
>> attacks. With PKEX the bootstrapping keys are changed upon each 
>> protocol run so 
> 
> But you're still sharing a PSK in the end?  Why go through all this 
> trouble?

This is a more dynamic way of configuration and allows devices to show 
up in a 'default' state and require zero manual configuration (for 
specific wifi networks). When your talking about 10, 20, 100 devices, 
manually configuring each one takes a lot of time. PKEX provided a 
"hands-off" way of doing it assuming you have other devices in the area 
with credentials.

> 
>> I think there is forward secrecy there. Plus PKEX uses mutual 
>> authentication to 
> 
> WPA3 has forward secrecy as well.  So what are you trying to achieve?

I was just comparing PKEX to using a static pre-shared bootstrapping key 
and fudging it to look like a QR code was scanned. This isn't a good 
idea, hence why I pursued PKEX.

> 
>> prevent someone from coming in and configuring the new devices who 
>> shouldn't be.
>>
> 
> The gold standard is still WPA-Enterprise with EAP-TLS.
> 
> Regards,
> -Denis
>