Re: [STDS-802-11] 11-23/0048r8

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi Mark,

Yes, minor confusion. I do have an r8 on my laptop but it is the same as r7. I made an r8 anticipating changes after receiving constructive suggestions from the "no" voters during the meeting but nothing actionable was received. Since it would be easier for me to just upload r8 than it would be to change the minutes, I'll just do that.

In any event, I would greatly appreciate *any* comments from the "no" voters (on r8, r7, or r6 for that matter) that are constructive and actionable. I again, request them to enumerate their multiple issues they claim they have with this submission. Please let's work in good faith.

The lack of per-user symmetric credentials (e.g. PSKs or passwords) has been historically addressed by a hack with the old PSK mode of 11s. Effectively, a dictionary attack is launched by the AP to determine which credential the supplicant used. Of course, this means that from the supplicant side it was indistinguishable from a shared credential, the user just entered the PSK/password and that was it, all the work to support the feature was done by the AP. This is not possible with SAE. The security of SAE prevents this dictionary attack. The requirement to use SAE in new greenfield bands (e.g. 6GHz) without an acceptable way of using per-user symmetric credentials is a train wreck waiting to happen. We know this is going to happen. We can prevent it. It's going to require changes in supplicant code, that's just the way it is; the AP can't do it all this time. Again, let's work in good faith to find a way to address this important problem.

regards,

Dan.

"the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." – Marcus Aurelius

On 6/21/23, 4:48 PM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---

Dan/all,

For avoidance of (minor) confusion: The document is 11-23/0044r7 (DCN=44, rev=7 on latest posted version). @Harkins, Dan: Do you perhaps have an r8 that is not posted, with some updates? I see the minutes from May say it is r8, which makes me think Jon believed you had an update that you would post…?

Mark

From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Wednesday, June 21, 2023 2:02 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] 11-23/0048r8

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hello,

At the May Interim meeting in Orlando document 11-23/0048r8 was discussed in REVme. There was some opposition to adopting it, as noted in 11-23/0863r0, and those opposed stated that there were "many open items" that kept them from approving. It was my recollection that the no voters would get back to me with an enumerated list of these many items. I have yet to see this list.

I recall vague statements like, "trust-on-first-use is not the right way to do this" without explaining what would be the right way or what would need to change in order to support the proposal, and also there was an assertion that implementers were not given any guidance on how long to maintain a trusted key and therefore did not know how to write their code but mandates on how STAs manage their state has traditionally been opposed by STA vendors (e.g. PMKSA caching lifetime mandates). So it's not really clear what changes the no voters would like to see or what other open items they see.

Can the no voters please enumerate their reasons for opposing this proposal which solves a legitimate use case with a minimum of change?

thanks,

Dan.

"the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." – Marcus Aurelius

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1