From: Johannes Berg <johannes@sipsolutions.net>
To: Jouni Malinen <jouni@codeaurora.org>
Cc: Arend van Spriel <arend.vanspriel@broadcom.com>,
Srinivas Dasari <dasaris@codeaurora.org>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] ieee80211: Increase the PMK maximum length to 64 bytes
Date: Sat, 10 Feb 2018 21:26:36 +0100 [thread overview]
Message-ID: <1518294396.2029.3.camel@sipsolutions.net> (raw)
In-Reply-To: <20180210103217.GA12147@jouni.qca.qualcomm.com>
On Sat, 2018-02-10 at 12:32 +0200, Jouni Malinen wrote:
>
> > Yeah I'm concerned about this too - and regardless of that issue, we
> > probably need those drivers that do support it to advertise support for
> > the new curves, and then allow the longer PMK length only for those that do?
>
> Please note that some drivers may not support even the current
> PMK_MAX_LEN (48) value. In fact, most of the cfg80211 cases using
> NL80211_ATTR_PMK are separately enforcing shorter lengths (32 or that
> 48), so this change in PMK_MAX_LEN definition does not actually have any
> impact for many of the existing cases.
Ok. If the drivers are checking/don't care then we can deal without
extra feature bits or something, IMHO, at least with respect to this
specific issue of length checks.
> The only place where it does make
> a difference is NL80211_CMD_SET_PMKSA and NL80211_ATTR_PMK was added for
> that command with FILS authentication in mind in the first place (and
> that would not get a 64 octet value from wpa_supplicant at least).
Ok.
> It turns out that there are no known use of PMK with DPP authentication
> at the moment in any driver, so for now, I think I'll just make
> wpa_supplicant skip addition of the NL80211_ATTR_PMK if the PMK is
> longer than 48 octets. This should take care of the most immediate need,
Fair enough.
> but it would be good to prepare for the possibility of there being a
> driver/firmware that would like to offload roaming and 4-way handshake
> with DPP APs and do that using this PMK value from DPP network
> introduction rather than offloading network introduction. For that to
> work, PMK_MAX_LEN needs to be increased.
So let's do the patch anyway? I mean ... it's one patch or the other,
so doesn't really make a huge difference?
> So DPP works just fine with most drivers even with the 64 octet PMK (as
> long as that wpa_supplicant change goes in) when there is no requirement
> of offloading 4-way handshake.
Right.
> As far as driver support for various PMK lengths is concerned, how
> should that be advertised? The limits can be different for each
> particular use of NL80211_ATTR_PMK (NL80211_CMD_CONNECT,
> NL80211_CMD_ASSOCIATE, NL80211_START_AP, NL80211_CMD_SET_PMKSA (for
> FILS), NL80211_CMD_SET_PMKSA (for DPP), NL80211_CMD_SET_PMKSA (for
> something else), NL80211_CMD_SET_PMK).
Yeah, that seems somewhat problematic? Though I'd hope they're kinda
all the same limits?
Perhaps we rather need something like "DPP supported" vs. "long PMK
supported" since just "long PMK" doesn't really say anything about the
supported curves?
johannes
prev parent reply other threads:[~2018-02-10 20:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 16:20 [PATCH v2] ieee80211: Increase the PMK maximum length to 64 bytes Srinivas Dasari
2018-02-07 19:35 ` Arend van Spriel
2018-02-07 20:21 ` Johannes Berg
2018-02-10 10:32 ` Jouni Malinen
2018-02-10 20:26 ` Johannes Berg [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=1518294396.2029.3.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=arend.vanspriel@broadcom.com \
--cc=dasaris@codeaurora.org \
--cc=jouni@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
/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 NNTP newsgroup(s).