From: Denis Kenzior <denkenz@gmail.com>
To: James Prestwood <prestwoj@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH 11/21] doc: PKEX support for DPP
Date: Thu, 19 Oct 2023 10:36:08 -0500 [thread overview]
Message-ID: <62d0c420-3bc5-45a8-80c6-c4c59db7ae2c@gmail.com> (raw)
In-Reply-To: <0dd4a4a5-95aa-49c1-be77-e640862c3f82@gmail.com>
Hi James,
>> 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.
>
WPS auto-generates a PIN, can we do the same here?
> 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).
>
Sure, and that's fine since we don't want to bug the user every time this
happens. But we have to provide some way for this to be provided outside of the
user hacking the provisioning file.
> 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.
Exactly.
>
> Could we support both like how we do with PSKs already? If not in the config
> file ask the agent?
Yes, that would be ideal.
Regards,
-Denis
next prev parent reply other threads:[~2023-10-19 15:36 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 20:01 [PATCH 00/21] DPP PKEX Changes James Prestwood
2023-10-12 20:01 ` [PATCH 01/21] crypto: remove label from prf_plus, instead use va_args James Prestwood
2023-10-17 15:18 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 02/21] dpp-util: fix typo "COMMIT_REVEAP_RESPONSE" James Prestwood
2023-10-17 15:19 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 03/21] dpp: rename auth_addr to peer_addr James Prestwood
2023-10-17 15:21 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 04/21] dpp: rename dpp_presence_timeout to be generic James Prestwood
2023-10-17 15:31 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 05/21] dpp: move/store max_roc setting into dpp_create James Prestwood
2023-10-17 15:32 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 06/21] dpp: fix retransmits if on operating channel James Prestwood
2023-10-17 15:36 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 07/21] dpp-util: allow for mutual authentication in i/r_auth James Prestwood
2023-10-19 14:34 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 08/21] dpp-util: allow mutual auth in dpp_derive_ke James Prestwood
2023-10-12 20:01 ` [PATCH 09/21] unit: update test-dpp with API changes James Prestwood
2023-10-12 20:01 ` [PATCH 10/21] offchannel: add support to issue multiple offchannel requests James Prestwood
2023-10-19 14:51 ` Denis Kenzior
2023-10-19 19:35 ` James Prestwood
2023-10-19 19:55 ` Denis Kenzior
2023-10-19 20:05 ` James Prestwood
2023-10-19 21:42 ` Denis Kenzior
2023-10-19 21:47 ` James Prestwood
2023-10-20 19:10 ` James Prestwood
2023-10-12 20:01 ` [PATCH 11/21] doc: PKEX support for DPP James Prestwood
2023-10-19 14:59 ` Denis Kenzior
2023-10-19 15:23 ` James Prestwood
2023-10-19 15:36 ` Denis Kenzior [this message]
2023-10-19 15:45 ` James Prestwood
2023-10-19 16:17 ` Denis Kenzior
2023-10-19 16:42 ` James Prestwood
2023-10-19 18:56 ` Denis Kenzior
2023-10-19 20:00 ` James Prestwood
2023-10-19 21:47 ` Denis Kenzior
2023-10-19 22:22 ` James Prestwood
2023-10-19 23:12 ` Denis Kenzior
2023-10-23 13:49 ` James Prestwood
2023-10-24 14:40 ` Denis Kenzior
2023-10-24 12:05 ` James Prestwood
2023-10-24 15:03 ` Denis Kenzior
2023-10-24 15:19 ` James Prestwood
2023-10-25 2:46 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 12/21] dpp-util: add crypto for PKEX James Prestwood
2023-10-19 15:13 ` Denis Kenzior
2023-10-19 15:27 ` James Prestwood
2023-10-12 20:01 ` [PATCH 13/21] dpp-util: add __DPP_STATUS_MAX James Prestwood
2023-10-19 15:16 ` Denis Kenzior
2023-10-23 12:35 ` James Prestwood
2023-10-12 20:01 ` [PATCH 14/21] dpp: support mutual authentication James Prestwood
2023-10-12 20:01 ` [PATCH 15/21] dpp: allow enrollee to be authentication initiator James Prestwood
2023-10-12 20:01 ` [PATCH 16/21] dbus: add SharedCodeDeviceProvisioning interface definition James Prestwood
2023-10-12 20:01 ` [PATCH 17/21] dpp: initial version of PKEX enrollee support James Prestwood
2023-10-12 20:01 ` [PATCH 18/21] dpp: initial version of PKEX configurator support James Prestwood
2023-10-12 20:01 ` [PATCH 19/21] auto-t: add utils for wpa_supplicant PKEX James Prestwood
2023-10-12 20:01 ` [PATCH 20/21] auto-t: add APIs for PKEX James Prestwood
2023-10-12 20:01 ` [PATCH 21/21] auto-t: add DPP PKEX tests James Prestwood
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=62d0c420-3bc5-45a8-80c6-c4c59db7ae2c@gmail.com \
--to=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=prestwoj@gmail.com \
/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