| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Mark
>> If MFPC=1 at the non-AP STA, then the STA is in full control:it can set MFPR=1 and then refuse to associate with an AP that does not set MFPC=1, or it can set MFPR=0 and then associate with any AP that doesn't signal the invalid MFPC+MFPR combination.
Thanks. Yes agree, and that is essentially my point - the differences in behavior you mention above are both local policy decisions at the non-AP STA.
If the non-AP STA has PMF enabled (i.e. MFPC=1), and the STA chooses to associate with a given AP, then it might as well always set MFPR=0 - the value is essentially irrelevant to the protocol. Specifically:
- If the peer AP has MFPC=1 then assoc succeeds and PMF is negotiated (no matter whether STA’s MFPR was 0 or 1)
- If the peer AP has MFPC=0 and the STA decided to associate (presumably because its local policy allows a non-PMF association), then:
- If STA set MFPR=0 (which would be consistent with its local policy of allowing non-PMF associations), assoc succeeds and PMF is not negotiated
- If STA set MFPR=1 (which would seem to contradict its local policy), assoc might or might not succeed (depending how ’no action’ is interpreted) and PMF is not negotiated
Thanks
Thomas
On Apr 24, 2021, at 3:28 AM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:
The original motivation of the comment was to clarify whether or not there is any meaning, from a protocol perspective, in how the non-AP STA sets MFPR iff the non-AP STA sets MFPC=1.
But to answer that question, we first need to agree/clarify what behaviors the current standard requires (on the AP) with respect to the MFPR value (from the STA).
Of course, other related clarifications could be beneficial too.
I'm not sure what you mean by "how the non-AP STA sets MFPR iff the non-AP STA sets MFPC=1".
If MFPC=1 at the non-AP STA, then the STA is in full control:
it can set MFPR=1 and then refuse to associate with an AP that does
not set MFPC=1, or it can set MFPR=0 and then associate with any AP
that doesn't signal the invalid MFPC+MFPR combination. In all cases
PMF is used iff MFPC=1 on both sides.
>> On what basis do you say "cannot be expected" here? It seems to me
that the 802.11-2020 spec does in fact expect exactly that.
The current standard says “No action”. I don’t know whether that means “take no action when the association request [with the invalid PMF configuration] is received” (and therefore do not respond), or whether it means “take no action based on the values of the PMF bits” (and therefore, in terms of responding to the association request, do whatever you were planning to do regardless of MFP values), or something else.
In any case, I assume the intent when this table was introduced was not to retrospectively add new requirements on legacy STAs.
OK. As I said initially I do agree "No action" is unclear, and anyway
I can't work out the logic behind which combinations are "No action"
(the first in the table makes sense from the perspective of an AP
that conforms to the standard prior to 802.11w, but the second does
not, and some situations where a STA that conforms to the standard
prior to 802.11w should similarly result in "No action" don't
(e.g. 1100)).
Would some "should"s do the trick?
That seems potentially one reasonable option for discussion.
OK, how about this (I'm leaning towards the "N/A" option in the
"[or N/A?]" cells, since I don't think we're in the business of
defining the behaviour for non-compliant devices or their peers;
in fact maybe all the rows with "shall not use" should just become
one big "Reserved")?
AP MFPC
AP MFPR
STA MFPC
STA MFPR
Non-AP STA action
AP action
PMF used?
0
0
0
0
The STA may associate with the AP
The AP may accept associations from the STA
No
0
0
1
0
The STA may associate with the AP
The AP may accept associations from the STA
No
1
0
0
0
The STA may associate with the AP
The AP may accept associations from the STA
No
1
0 or 1
1
0 or 1
The STA may associate with the AP
The AP may accept associations from the STA
Yes
0
0
1
1
The STA shall not associate with the AP
The AP should reject associations from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION (see NOTE) [or N/A?]
N/A
1
1
0
0
The STA should not associate with the AP (see NOTE)
The AP shall reject associations from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION
N/A
0 or 1
0 or 1
0
1
The STA shall not use this combination
N/A
N/A
0
1
0
0
The STA should not associate with the AP (see NOTE)[or N/A?]
The AP shall not use this combination
N/A
0
1
0 or 1
0 or 1
(not 0 if
STA MFPC
also 0)
The STA shall not associate with the AP [or N/A?]
The AP shall not use this combination
N/A
NOTE—STAs conformant with previous revisions of this standard might not ascribe a meaning to the MFPC and MFPR subfields.
Similarly, here is what Table 12-6—Robust management frame selection in an IBSS
might say. Per some other comments, this table should be extended to apply to
TDLS (and maybe also PBSS and MBSS?) -- though TDLS postdates PMF so shouldn't
need the waiver (ditto PBSS). Same N/A and "shall not use" considerations as above.
STA MFPC
STA MFPR
Peer STA MFPC
Peer STA MFPR
STA action
Peer STA action
PMF used?
0
0
0
0
The STA may exchange data with the peer STA
The peer STA may exchange data with the STA
No
0
0
1
0
The STA may exchange data with the peer STA
The peer STA may exchange data with the STA
No
1
0
0
0
The STA may exchange data with the peer STA
The peer STA may exchange data with the STA
No
1
0 or 1
1
0 or 1
The STA may exchange data with the peer STA
The peer STA may exchange data with the STA
Yes
1
1
0
0
The STA shall not exchange data nor establish a security association with the peer STA
The peer STA should not exchange data with the STA and should reject security association attempts from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION (see NOTE) [or N/A?]
N/A
0
0
1
1
The STA should not exchange data nor establish a security association with the peer STA (see NOTE)
The peer STA shall not exchange data with the STA and shall reject security association attempts from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION
N/A
0
1
0 or 1
0 or 1
The STA shall not use this combination
N/A
N/A
0
0
0
1
The STA should not exchange data nor establish a security association with the peer STA (see NOTE) [or N/A?]
The peer STA shall not use this combination
N/A
0 or 1
0 or 1
(not 0 if
STA MFPC
also 0)
0
1
The STA shall not exchange data nor establish a security association with the peer STA [or N/A?]
The peer STA shall not use this combination
N/A
NOTE—STAs conformant with previous revisions of this standard might not ascribe a meaning to the MFPC and MFPR subfields.
See also CIDs 199, 200, 202:
CID 199
12.6.3
There is information on how MFP is negotiated for infrastructure BSS (Table 12-5--Robust management frame selection in an infrastructure BSS) and for IBSS (Table 12-6--Robust management frame selection in an IBSS) but not for TDLS. More generally, the use of MFP on a TDLS direct link is lacking (there's just "After receiving aDeauthentication frame or a Disassociation frame from the AP, a Deauthentication frame with Reason Code LEAVING_NETWORK_DEAUTH shall be transmitted via the direct path to all TDLS peer STAs that are in the awake state, if management frame protection has not been negotiated on the TDLS direct link." buried in 11.20.5 TDLS direct-link teardown)
Change "Table 12-6--Robust management frame selection in an IBSS" to "Table 12-6--Robust management frame selection in an IBSS or between TDLS peer STAs". In that table change "The peer STA shall not" to "The STA shall not". At 2598.50 change "An STA" to "A STA" and after that sentence add "A TDLS STA shall use Table 12-6 and the
values of the MFPC and MFPR bits advertised in the RSNEs to determine if it may establish a TDLS link with another a TDLS peer STA."
CID 200
12.6.19
This subclause talks of "associated STA" but MFP can be used with IBSS and TDLS too
Change "associated STA" to "associated or peer STA" throughout this subclause
CID 202
11.20.4
2321.20
"If enabled, management frame protection shall only be used as a required feature (MFPR) in an IBSS." -- what does this mean? It might be trying to say that in an IBSS if you're going to do MFP you have to set MFPR, but that's contradicted by Table 12-6--Robust management frame selection in an IBSS. Even with the "only" (a word that always massively increases the risk of ambiguity) it's not clear what it might be trying to say
Delete the cited sentence
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
Sent: Saturday, 24 April 2021 01:40
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D0.0 CID 587 (MFPC/MFPR horror)
Thanks Mark.
The original motivation of the comment was to clarify whether or not there is any meaning, from a protocol perspective, in how the non-AP STA sets MFPR iff the non-AP STA sets MFPC=1.
But to answer that question, we first need to agree/clarify what behaviors the current standard requires (on the AP) with respect to the MFPR value (from the STA).
Of course, other related clarifications could be beneficial too.
>> On what basis do you say "cannot be expected" here? It seems to me
that the 802.11-2020 spec does in fact expect exactly that.
The current standard says “No action”. I don’t know whether that means “take no action when the association request [with the invalid PMF configuration] is received” (and therefore do not respond), or whether it means “take no action based on the values of the PMF bits” (and therefore, in terms of responding to the association request, do whatever you were planning to do regardless of MFP values), or something else.
In any case, I assume the intent when this table was introduced was not to retrospectively add new requirements on legacy STAs.
Would some "should"s do the trick?
That seems potentially one reasonable option for discussion.
Thanks
-Thomas
On Apr 23, 2021, at 5:06 PM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Ah, now I see what the comment is about!
I think this table needs to be compatible with 802.11 devices that support RSNA but don’t support PMF, and therefore set MFPC=0 and MFPR=0.
Such APs cannot be expected to identify a MFP policy violation made by the STA, and so might or might not accept the (invalid) request from the STA (in row 6).
On what basis do you say "cannot be expected" here? It seems to me
that the 802.11-2020 spec does in fact expect exactly that. So are you
basically proposing a spec change to support devices that don't
comply with the 2020 spec? Or is the argument that MFPC/MFPR was
introduced after the initial RSN Capabilities stuff, and not introduced
in a backward-compatible way?
The same might be true for a STA that does not support MFP and encounters an AP with an invalid policy (final row).
Would some "should"s do the trick?
AP MFPC
AP MFPR
STA MFPC
STA MFPR
STA action
AP action
PMF used?
0
0
0
0
The STA may associate with the AP
The AP may accept associations from the STA
No
0
0
1
0
The STA may associate with the AP
The AP may accept associations from the STA
No
1
0
0
0
The STA may associate with the AP
The AP may accept associations from the STA
No
1
0 or 1
1
0 or 1
The STA may associate with the AP
The AP may accept associations from the STA
Yes
0
0
1
1
The STA shall not associate with the AP
The AP should reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION
[or N/A?]
N/A
1
1
0
0
The STA should not associate with the AP
The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION
N/A
0
0
0
1
The STA shall not use this combination
The AP should reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION [or N/A?]
N/A
0 or 1
0 or 1 (not 0 if AP MFPC also 0)
0
1
The STA shall not use this combination
The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION [or N/A?]
N/A
0
1
0
0
The STA should not associate with the AP
The AP shall not use this combination
N/A
0
1
0 or 1
0 or 1 (not 0 if STA MFPC also 0)
The STA shall not associate with the AP
The AP shall not use this combination
N/A
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Saturday, 24 April 2021 00:12
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D0.0 CID 587 (MFPC/MFPR horror)
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Thanks for this discussion.
I think this table needs to be compatible with 802.11 devices that support RSNA but don’t support PMF, and therefore set MFPC=0 and MFPR=0.
Such APs cannot be expected to identify a MFP policy violation made by the STA, and so might or might not accept the (invalid) request from the STA (in row 6).
The same might be true for a STA that does not support MFP and encounters an AP with an invalid policy (final row).
-Thomas
On Apr 23, 2021, at 3:58 PM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:
> d. Feedback request - Dan Harkins – CID 587
Having looked at 587…
I don't even understand Table 12-5—Robust management frame selection in an infrastructure BSS:
- What does "No action" mean under "AP action"?
That's basically why I'm asking for time. I want to see if there's some consensus about what the behavior should be.
- Why is the AP behaviour not the same for all the "The STA shall not
[try to] associate with the AP" cases, specifically "The AP shall
reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_POLICY_VIOLATION"? At least the ones where the AP
isn't advertising an invalid combination!
Well if you can make the case that they should all be the same then I'd like to hear it.
In fact, if you think you know how the CID should be resolved and what the necessary clarification is I'll be happy to reassign the CID to you. Lemme know.
Well, just thinking aloud, how about:
AP MFPC
AP MFPR
STA MFPC
STA MFPR
STA action
AP action
PMF used?
0
0
0
0
The STA may associate with the AP
The AP may accept associations from the STA
No
0
0
1
0
The STA may associate with the AP
The AP may accept associations from the STA
No
1
0
0
0
The STA may associate with the AP
The AP may accept associations from the STA
No
1
0 or 1
1
0 or 1
The STA may associate with the AP
The AP may accept associations from the STA
Yes
0
0
1
1
The STA shall not associate with the AP
The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION
[or N/A?]
N/A
1
1
0
0
The STA shall not associate with the AP
The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION [or N/A?]
N/A
0 or 1
0 or 1
0
1
The STA shall not use this combination
The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION [or N/A?]
N/A
0
1
0 or 1
0 or 1
The STA shall not associate with the AP
The AP shall not use this combination
N/A
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
- That table covers 13 combinations, so what about the other 3?
I think these are 0001, 0100, 0101 (all invalid at the AP and/or STA).
This is also true for Table 12-6—Robust management frame selection
in an IBSS
So I agree with the comment that there is a need to
"Clarify since it is a frequent source of confusion"!
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Friday, 23 April 2021 19:13
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] Teleconference Reminder: Monday April 26 at 10am ET
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi all,
I just wanted to remind everyone that REVme will meet on Monday at 10am ET. The full agenda doc is posted here:
https://mentor.ieee.org/802.11/dcn/21/11-21-0656-02-000m-april-may-revme-teleconference-agenda.docx
The agenda for the CC35 comment resolutions (the bulk of the meeting) will be:
a Document 11-21/695r0 – Michael Montemurro (Huawei) – CIDs 51-80 (20 min)
b. https://www.ieee802.org/11/email/stds-802-11-tgm/msg02118.html– Mark Rison (Samsung) – CIDs (remaining time to 1hr)
c. Document <> - Edward Au (Huawei) – Editor 2 CIDs
d. Feedback request - Dan Harkins – CID 587
e. Document 11-21/688r0 - Ganesh Venkatesan (Intel) – CIDs <>
Cheers,
Mike
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
--
"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-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
|