All of lore.kernel.org
 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: Thu, 19 Oct 2023 18:12:10 -0500	[thread overview]
Message-ID: <f812bdcd-219e-4e0d-8816-46015bd7cdab@gmail.com> (raw)
In-Reply-To: <7de9faab-5863-48f5-8de6-28e1b543d2b8@gmail.com>

Hi James,

> 
> My comparison to the PSK is that there is no difference in guessing the PSK vs 
> PKEX key. Both equally compromise you.
> 

I'm with you :)

> I'm not sure that quote specifically is mandating the PKEX exchange use a 
> different password every time, just that an exchange will tell you _if_ you 
> guessed the password correctly. But you are right that the DPP spec wants a 
> different PW to be used each time.

I'll need to do a bit more spelunking in the relevant specifications to see if 
we have a bit more leeway, but ...

The draft RFC is pretty explicit, it does not mandate 'every time', but close 
enough:

"Implementations SHALL maintain a counter of unsuccessful exchanges
    for each password in order to defend against repeated active attacks
    to determine the password.  This counter SHALL be set to zero when a
    password is provisioned and incremented each time PKEX finishes
    unsuccessfully for that password.  When the counter reaches a value
    of five (5) the password SHALL be irretrievably removed from the
    implementation."

The DPP spec is a bit more permissive in that it says 'If both sides have a user 
interface'.  But I think the intent is for the shared code to be regenerated on 
each attempt.

> 
> "shall use a fresh code each time and the same code shall not be used with 
> different Peers"
> 
> So we don't have to put it in the config file if you don't want to. 
> Auto-generation just won't work for my purposes since I have no way of sharing 
> that on a headless device, so if that's a must I'd have to do some thinking...

Fair enough, lets explore whether we can provide this via some agent API.

> 
> I'm fine with it as an argument to the StartConfigurator API. An agent could 
> work but we've also got the optional identifier to think about. I'd prefer to 
> use the existing agent API for getting a passphrase rather than a new method.
> 

But the identifier is not supposed to be secret?

Regards,
-Denis

  reply	other threads:[~2023-10-19 23:12 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 [this message]
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=f812bdcd-219e-4e0d-8816-46015bd7cdab@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.