I've come up with the following. Please tell me if you have any
comments or corrections/additions, or can answer the open questions.
Discussion:
As the comments say, because the RSNE in T2 is required to be a copy of the RSNE in T1, the TDLS initiator either doesn’t receive the TDLS responder’s RSN capabilities, or only receives them unprotected (in the TDLS Discovery Response frame).
The proposals above were to just require support for 16 (well, in practice 8 suffice) replay counters and to use heuristics to determine MFP use, but the group expressed on 2023-12-08 a preference for instead requiring the TDLS responder to align with the TDLS initiator’s RSN capabilities, and if this is not acceptable/possible, to abandon the TPK handshake.
Proposed changes:
Do not make the changes proposed in CID 6149 (this is a reversal of the ACCEPTED in motion 119).
Change 12.6.3 RSNA policy selection in an infrastructure BSS as follows:
(#199)TDLS STAs shall use Table 12-6 (Robust management frame selection between TDLS STAs(#199)) and the values of the MFPC and MFPR bits advertised in the RSNE received from the TDLS peer
STA during TDLS discovery or in the RSNEs exchanged in the 3-way handshake with the TDLS peer STA transmitted by the TDLS initiator STA in the TDLS Setup Request frame to determine if a TDLS direct link is allowed, and if so whether management frame
protection is enabled. If either the TDLS initiator STA does not advertise an RSN Capabilities field in anthe RSNE, this shall be treated as if its MFPC and MFPR bits were 0.
A TDLS STA should, in the context of TDLS, set the MFPC bit to 1 if dot11RSNAProtectedManagementFramesActivated is true, and shall set it to 0 unless dot11RSNAProtectedManagementFramesActivated is true. A TDLS initiator STA should, in the context
of TDLS, set the MFPR bit to the same value as it advertised to the AP with which it is associated.(#3056)
NOTE—The MFPR bit from the TDLS initiator STA is ignored by the TDLS responder STA, and (if a TDLS Discovery Response frame is sent) the MFPC and MFPR bits from the TDLS responder STA are ignored by the TDLS
initiator STA, except that a TDLS initiator STA might set its MFPC bit to 0 if the MFPC bit from the TDLS responder STA is 0.
Replace Table 12-6—Robust management frame selection between TDLS STAs(#199) with:
|
TDLS initiator STA MFPC |
TDLS responder STA MFPC (might not be transmitted) |
TDLS initiator STA action |
TDLS responder STA action |
MFP used? |
|
0 |
1 |
The TDLS initiator STA may establish a TDLS direct link with the TDLS responder STA |
The TDLS responder STA may establish a TDLS direct link with the TDLS initiator STA (see NOTE 1) |
No |
|
0 |
0 |
The TDLS responder STA may establish a TDLS direct link with the TDLS initiator STA |
||
|
1 |
1 |
Yes |
||
|
1 |
0 |
See NOTE 2 |
The TDLS responder STA shall reject attempts by the TDLS initiator STA to establish a TDLS direct link with the Status Code ROBUST_MANAGEMENT_ |
N/A |
|
NOTE 1—If the TDLS responder requires MFP, it can cause the TDLS direct link establishment to fail by using the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION in the TDLS Setup Response frame. |
||||
|
NOTE 2—If a TDLS initiator STA has performed TDLS discovery and determined that the TDLS responder STA is not MFPC, it might, if it trusts the authenticity of the TDLS Discovery Response frame, avoid this situation, i.e.
it might set its MFPC bit to 0 and not use MFP. |
||||
OR with (same information, just different layout):
|
TDLS initiator STA MFPC |
TDLS responder STA MFPC (might not be transmitted) |
TDLS initiator STA action |
TDLS responder STA action |
MFP used? |
|
1 |
1 |
The TDLS initiator STA may establish a TDLS direct link with the TDLS responder STA |
The TDLS responder STA may establish a TDLS direct link with the TDLS initiator STA |
Yes |
|
0 |
0 |
No |
||
|
0 |
1 |
The TDLS responder STA may establish a TDLS direct link with the TDLS initiator STA (see NOTE 1) |
||
|
1 |
0 |
See NOTE 2 |
The TDLS responder STA shall reject attempts by the TDLS initiator STA to establish a TDLS direct link with the Status Code ROBUST_MANAGEMENT_ |
N/A |
|
NOTE 1—If the TDLS responder requires MFP, it can cause the TDLS direct link establishment to fail by using the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION in the TDLS Setup Response frame. |
||||
|
NOTE 2—If a TDLS initiator STA has performed TDLS discovery and determined that the TDLS responder STA is not MFPC, it might, if it trusts the authenticity of the TDLS Discovery Response frame, avoid this situation, i.e.
it might set its MFPC bit to 0 and not use MFP. |
||||
Change 12.5.2.4.4 PN and replay detection and 12.5.4.4.4 PN and replay detection as follows:
b) For each PTKSA, (#166)TPKSA, GTKSA, mesh PTKSA, and mesh GTKSA(#239), the (#4212)receiver shall maintain a separate replay counter for each TID, subject to the limitation of the number of supported replay counters
indicated in the RSN Capabilities field (see 9.4.2.23 (RSNE))(#3573). In the case of a TPKSA, this shall for both the TDLS initiator STA and the TDLS responder STA be the number indicated by the TDLS initiator STA in the PTKSA Replay Counter field in the
TDLS Setup Request frame.
NOTE—The number indicated by the TDLS responder STA (if a TDLS Discovery Response frame is sent) is ignored,
as is the GTKSA Replay Counter field in the TDLS Setup Request frame and any TDLS Discovery Response frame[MR1] .
Change 12.7.8.4.2 TPK handshake message 1 as follows:
On reception of message 1, the TDLS responder STA checks whether the RSNE is present. proceeds as follows:
If security is not required on the TDLS direct link (see 12.7.8.1 (General)) and the request includes an
RSNE[MR2] ,
itthe TDLS responder STA shall reject the request with status code SECURITY_DISABLED.
If security is required on the TDLS direct link (see 12.7.8.1 (General)), it checks whether and the request does not includes both an RSNE and
an FTE[MR3] .
If not, the TDLS responder STA shall reject the request with status code INVALID_PARAMETERS.
If the version field of the RSNE is
0[MR4] ,
then the TDLS responder STA shall reject the request with status code UNSUPPORTED_RSNE_VERSION.
Otherwise, the TDLS responder STA processes the message as follows:
<deindent subsequent paras to be at the same level as above>
If (#3488)the RSNE does not indicate (#4225)the single (#3266)AKM 00-0F-AC:7(TPK handshake), the TDLS responder STA shall reject the request with status code STATUS_INVALID_AKMP.
If none of the pairwise cipher suites are acceptable, or pairwise ciphers include[MR5]
(#3056)TKIP, then the TDLS responder STA shall reject the TDLS Setup Request frame request with status code STATUS_INVALID_PAIRWISE_CIPHER.
If the RSN Capabilities field has not been set the subfields
according to the described rules for this message[MR6] ,
then the TDLS responder STA shall rejects the request with status code INVALID_RSNE_CAPABILITIES.
If the number of replay counters indicated by the TDLS initiator STA is not acceptable to the TDLS responder STA at both the TDLS initiator STA and the TDLS responder STA (see 12.5.2.4.4 and 12.5.4.4.4), the
TDLS responder STA shall reject the request with status code
INVALID_RSNE_CAPABILITIES[MR7] .
If the suggested lifetime is unacceptable or below the default value, the TDLS responder STA shall reject the TDLS Setup Request frame request with status code UNACCEPTABLE_LIFETIME.
If the contents of the FTE are not
as per specified for this message[MR8] ,
then the TDLS responder STA shall reject the TDLS Setup Request frame request with status code STATUS_INVALID_FTE.
The TDLS responder STA shall ignore the remaining fields in the RSNE, FTE, and (#1776)TIE[MR9] .
Otherwise, the TDLS responder STA shall respond as specified in 11.20.4 (TDLS direct link establishment(#1356)).
Change 12.7.8.4.3 TPK handshake message 2 as follows:
The TDLS responder STA sends message 2 to the TDLS initiator STA. The TDLS initiator STA shall process message 2 as follows:
On reception of message 2, the TDLS initiator STA proceeds as follows:
If the TDLS initiator STA Address and TDLS responder STA Address of the Link Identifier element do not match those for an outstanding TDLS Setup Request, the TDLS initiator STA shall silently discard the received
TDLS Setup Response frame response.
If the SNonce field of the FTE does not match that of an outstanding request to the TDLS responder STA,
then the TDLS initiator STA shall silently discard the received TDLS Setup Response frame response.
Otherwise, the TDLS initiator STA shall compute the TPK and then validate the MIC in the FTE as specified in MIC calculation procedure for TPK handshake message 2. If invalid, the TDLS initiator STA shall
discard[MR10]
the messageresponse.
If the version of the RSNE is 0 or is greater than the version of the RSNE sent in message 1, then the TDLS initiator STA shall reject the response with status code UNSUPPORTED_RSNE_VERSION.
Otherwise,
<deindent subsequent paras to be at the same level as above>
If the (#3488)Information field of the RSNE, with the exception of the pairwise cipher suite count and pairwise cipher suite list, is not the same as that sent by the TDLS initiator STA in message 1 of this sequence,
then the TDLS initiator STA shall reject the response with status code INVALID_RSNE.
If the pairwise cipher suite count is
other thannot 1, then the TDLS initiator STA shall reject the response with status code STATUS_INVALID_PAIRWISE_CIPHER.
If the selected pairwise cipher suite was not included in the
Initiator’s request, then the TDLS initiator STA shall reject the TDLS Setup Response frame response with status code STATUS_INVALID_PAIRWISE_CIPHER.
If the (#1776)TIE is not the same as that sent in message 1, the TDLS initiator STA shall reject the TDLS Setup Response frame response with status code UNACCEPTABLE_LIFETIME.
If the BSSID in the Link Identifier element is different from the one sent in message 1,
then the TDLS initiator STA shall reject the response with status code NOT_IN_SAME_BSS.
Change 12.7.8.4.4 TPK handshake message 3 as follows:
The TDLS initiator STA sends message 3 to the TDLS responder STA. The TDLS responder STA shall process message 3 as follows:
On reception of message 3, the TDLS responder STA proceeds as follows:
[…]
If any of the above conditions are not met, the TDLS responder STA shall discard the
messageconfirmation.
[…]
If any one of the above conditions are not met, the TDLS responder STA shall discard the
messageconfirmation
Proposed resolution:
REVISED
Make the changes shown under “Proposed changes” for CID 6166, 6150, 6149 in <this document URL>, which make the RSN capabilities specified by the TDLS initiator apply to the TDLS responder too.
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
[MR1]What about the other fields, e.g. Joint Multi-Band RSNA (note 12.6.20.4 Multi-band RSNA with TDLS in
a non-DMG BSS), EKIDIAF, OCVC?
[MR2]or FTE or TIE?
[MR3]and TIE?
[MR4]what if 2?
[MR5]See also CID 6167 on >1 suite
[MR6]What does this mean?
[MR7]Or need new code?
[MR8]What does this mean?
[MR9]What fields is this referring to for TIE and FTE?
[MR10]silently?
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