Wireless Daemon for Linux
 help / color / mirror / Atom feed
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: Tue, 24 Oct 2023 10:03:51 -0500	[thread overview]
Message-ID: <a34bf8b9-45aa-4466-aa63-7f85d3f1ad81@gmail.com> (raw)
In-Reply-To: <f5d4ec5f-a7c2-4dc5-853d-d65ae1b72c93@gmail.com>

Hi James,

>>
>> Fair enough, lets explore whether we can provide this via some agent API.
> 
> Reading more about the identifier being used to distinguish a "plurality of 
> devices" this is what I'm thinking as far as the agent interaction:
> 
> It would make sense (on the configurator side) to query an agent _after_ the 
> enrollee sends the PKEX exchange request. That way the configurator can look up 
> the identifier/code, somewhat the same as RequestUserPassword.

Possible.  But isn't the main use case to share the code and initiate on both 
sides independently?

So..
ConfiguratorEnrollee(code, identifier)
StartEnrollee(code, identifier)

> 
> I don't see much benefit of using an agent in StartEnrollee(), and would rather 
> pass via the DBus arguments for simplicity. Adding an agent for this doesn't 
> really gain us anything, it just adds complexity. The caller of the API can 
> still change the code/id for each call it makes to StartEnrollee() as it sees fit.

Okay, sounds fair.

> 
> So something like:
> 
> StartConfigurator()
>      ... waits for PKEX exchange request ...
>      -> RX PKEX exchange request
>          if (id)
>              Agent.RequestUserPassword(id)
>          else
>              Agent.RequestPassphrase()
> 
> (And if we want "SharedCode" Agent APIs, that's fine, these just fit the need)
> 
> The one caveat here is the timing since the PKEX exchange response must come 
> within 200ms, which isn't possible for a human user. A human configurator would 
> need to establish the code/id completely ahead of time.
Well, that's why it says to retransmit 5 times.  But even then, that isn't 
enough time for a human to process this.  Hence my point above, that the 
use-case seems geared towards both sides entering the shared code without any 
'trigger' from the peer.

What you propose here is using the Agent, but only for as a way to machine 
generated a response.  Sounds like maybe:

StartConfigurator(object shared_code_agent_path)?

Regards,
-Denis


  reply	other threads:[~2023-10-24 15:03 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
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 [this message]
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=a34bf8b9-45aa-4466-aa63-7f85d3f1ad81@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