Hello,
So having re-examined my proposal, specifically
|
Non-AP STA MFPC |
Non-AP STA MFPR |
Non-AP STA action |
AP MFPC |
AP MFPR |
AP action |
PMF used? |
|
0 |
0 |
The STA may associate with the AP |
0 |
0 |
The AP may accept associations from the STA |
No |
|
1 |
0 |
The STA may associate with the AP |
0 |
0 |
The AP may accept associations from the STA |
No |
|
0 |
0 |
The STA may associate with the AP |
1 |
0 |
The AP may accept associations from the STA |
No |
|
1 |
0 or 1 |
The STA may associate with the AP |
1 |
0 or 1 |
The AP may accept associations from the STA |
Yes |
|
1 |
1 |
The STA shall not associate with the AP |
0 |
0 |
N/A |
N/A |
|
0 |
0 |
The STA should not associate with the AP (see
NOTE) |
1 |
1 |
The AP shall reject associations from
the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION |
N/A |
|
0 |
1 |
The STA shall not use this combination |
|
|
|
N/A |
|
|
|
|
0 |
1 |
The AP shall not use this combination |
N/A |
|
NOTE—STAs conformant with a previous revision of this standard might not ascribe a meaning to the MFPC and MFPR subfields. |
||||||
in the light of the discussion today.
I think it meets all of the
key requirements discussed:
- Does not impose requirements on a STA (AP or not) that conforms
to a revision of the 802.11 spec before 802.11w was approved
(I've highlighted this in cyan)
- Ensures that if a pre-802.11w STA attempts to associate with an
AP that requires MFP, the association will be denied (I've highlighted
this in yellow).
There are no situations in which there could be
doubt as to whether PMF will be used on a link
As discussed, it does not attempt to define AP behaviour in the
face of a
nonconformant STA, i.e. a non-AP STA that has MFPR = 1
and attempts to associate with an AP that has MFPC = 0, or a STA
(AP or not) that sets MFPC = 0 and MFPR = 1.
I remain unconvinced
but persuadable that in this case we should define such behaviour.
During the call there was a suggestion that the STA's policy might
differ from what the STA advertises in the RSN capabilities.
I
don't think that's the case: the policy (in the MIB) and what is
advertised are directly linked:
— Bit 6: MFPR. A STA sets this bit to 1 to advertise that protection of robust Management frames is
mandatory. A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is
true and dot11RSNAUnprotectedManagementFramesAllowed is false; otherwise it sets this bit to 0.
If a STA sets this bit to 1, then that STA only allows RSNAs with STAs that provide Management
Frame Protection.
— Bit 7: MFPC . A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is
true to advertise that protection of robust Management frames is enabled.
I suppose we should add "; otherwise it sets this bit to 0" to the
MFPC one, though.
Finally, I
unwithdraw my withdrawal of my support for the notion that
the MFPR bit from the non-AP STA doesn't really matter over the air.
As can be seen in the table above (I've highlighted this in green),
given the only permissible combinations, the use of PMF ends up only
depending on the MFPC at both sides; it is not dependent on the MFPR
setting at the non-AP STA.
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:
Mark Rison
Sent: Monday, 26 April 2021 07:05
To: 'Thomas Derham' <thomas.derham@xxxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] 11me/D0.0 CID 587 (MFPC/MFPR horror)
Hello Thomas,
If the non-AP STA has PMF enabled (i.e. MFPC=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=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
I don't think the STA is allowed to associate in this case:
Here are my latest ideas on how to present this.
Note I've reordered
the columns.
The row above becomes a "N/A" for the AP, since it's
a "shall not" at the notional initiator (the STA).
|
Non-AP STA MFPC |
Non-AP STA MFPR |
Non-AP STA action |
AP MFPC |
AP MFPR |
AP action |
PMF used? |
|
0 |
0 |
The STA may associate with the AP |
0 |
0 |
The AP may accept associations from the STA |
No |
|
1 |
0 |
The STA may associate with the AP |
0 |
0 |
The AP may accept associations from the STA |
No |
|
0 |
0 |
The STA may associate with the AP |
1 |
0 |
The AP may accept associations from the STA |
No |
|
1 |
0 or 1 |
The STA may associate with the AP |
1 |
0 or 1 |
The AP may accept associations from the STA |
Yes |
|
1 |
1 |
The STA shall not associate with the AP |
0 |
0 |
N/A |
N/A |
|
0 |
0 |
The STA should not associate with the AP (see NOTE) |
1 |
1 |
The AP shall reject associations from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION |
N/A |
|
0 |
1 |
The STA shall not use this combination |
|
|
|
N/A |
|
|
|
|
0 |
1 |
The AP shall not use this combination |
N/A |
|
NOTE—STAs conformant with a previous revision of this standard might not ascribe a meaning to the MFPC and MFPR subfields. |
||||||
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: Monday, 26 April 2021 03:13
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)
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