Re: [STDS-802-11-TGM] REVme CC35 CID 224

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

It's not a limitation, it's a suggestion.

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: Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: Thursday, 11 November 2021 17:54
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] REVme CC35 CID 224

On 11/11/21, 9:50 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

> What's a "weak algorithm"?

I suggest you make a comment on this in D1.0. My proposed resolution

doesn't touch this text, it merely suggests using the same cipher suite

as on the link to the AP.

And as we discussed (and as documented below in the 1.1.1.* items) there is no justification for that limitation.

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

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: Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: Thursday, 11 November 2021 17:39
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] REVme CC35 CID 224

What's a "weak algorithm"? And there lies a giant rathole which we should all avoid.

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 11/11/21, 9:28 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hello Mike,

> This comment was discussed on May 12 and the recommendation was to reject the comment with the reason.

The recommendation from whom and with what reason? The minutes are

compatible with my recollections, which are that I was to come up

with a proposal (which I have done, as you say in 21/0829r7):

2.6.6 CID 224 (SEC)

1.1.1.1 Review Comment

1.1.1.2 Review discussion in submission.

1.1.1.2.1 There is nothing inherently wrong with using a smaller key. It depends on what the TDLS conversation is going to be consisting of. In fact, one might argue the other way around—a longer key protected by an exchange using a smaller key—but that’s if one wants to argue the point which it does not seem useful to do. If we wanted to start making recommendations on ciphers it should involve how the key was generated—i.e. don’t use EAP-TLS with a TLS version less than 1.2 and do (EC)DHE for key generation, make sure you use the appropriate hash algorithms, etc—but for people that get hung up on that we have the Suite B ciphers.

1.1.1.3 Proposed Resolution: Reject, aside from Suite B ciphersuites and AKMs, 802.11 does not restrict what ciphers can be used and we shouldn’t start with TDLS.

1.1.1.4 Discussion on which cipher should be used and when it should be used.

1.1.1.5 Support for reject due to not clear what change should be made.

1.1.1.6 Discussion on a recommendation for which ciphersuites should be used.

1.1.1.7 Possibly a note could be added to help clarify this.

1.1.1.8 Assign CID to Mark RISON – More work needed.

My proposal includes a discussion section:

It is odd that security is required if security is used on the link to the AP, i.e. the TDLS link is expected to be secure, but there are no requirements, recommendations or even suggestions on the strength of this security (apart from the bottom-of-the-barrel prohibition on WEP and TKIP), i.e. the TDLS link can be less secure than the link to the AP.

In practice, if a given pairwise cipher suite is suitable for the link to the AP, it would typically be suitable for the TDLS link too. This should at least be hinted at.

For reference, the wording (in 12.7.8.1) is:

If any security method (pre-RSNA or RSNA) is enabled on the connection between a STA and the AP, the STA shall require that the TPK security protocol complete successfully before using a direct link. If no security method is enabled on the connection between a STA and the AP, the STA shall not use the TPK security protocol on the direct link. A STA may refuse to set up a TDLS link when the protection on the STA link to the AP is secured with a weak algorithm or when the link between the STA and the AP is not using any security.

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: Thursday, 11 November 2021 16:04
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] REVme CC35 CID 224

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hi all,

CID 224 is scheduled on the REVme agenda for Friday's session. The comment is given below.

This comment was discussed on May 12 and the recommendation was to reject the comment with the reason. There have been no alternative resolutions proposed however there appears to be a proposed revised resolution in document 11-21/829r7:

Option 1:

REJECTED. Aside from Suite B ciphersuites and AKMs, the 802.11 standard does not restrict which ciphers can be negotiated during security association establishment and there is no need to do so with TDLS.

Option 2

REVISED
In 12.7.8.4.2 TPK handshake message 1, after the para starting "The pairwise cipher suite list field indicating" add
“NOTE—The TDLS initiator STA might indicate the same pairwise cipher suite as used on the connection between the STA and the AP.”
and after the sentence starting "If none of the pairwise cipher suites are acceptable" add
“NOTE—The TDLS responder STA might only accept the same pairwise cipher suite as used on the connection between the STA and the AP.”
In 12.7.8.4.3 TPK handshake message 2 after the sentence starting "Include a pairwise cipher suite" add
“NOTE—The TDLS responder STA might select the same pairwise cipher suite as used on the connection between the STA and the AP.”

My personal preference is to go with Option 1 since the pairwise cipher may be different between the AP and the TDLS initiator/responder STA.

Cheers,

Mike

REVme SEC adhoc comments

224

12.7.8.4

There are no constraints on the cipher to use with TDLS, other than not using WEP or TKIP. Some recommendations should be given, specifically that it should be at least as strong as the cipher used with the AP

After the sentence starting "The pairwise cipher suite list field indicating " in 12.7.8.4.2 TPK handshake message 1 add "A pairwise cipher suite of key size smaller than that used on the connection between the STA and the AP should not be used." and after the sentence starting "If none of the pairwise cipher suites are acceptable" add "The TDLS responder STA should ignore any pairwise cipher suites of key size smaller than that used on the connection between the STA and the AP, and should reject the TDLS Setup Request frame
with status code STATUS_INVALID_PAIRWISE_CIPHER if all the pairwise cipher suites are such.". In 12.7.8.4.3 TPK handshake message 2 after the sentence starting "Include a pairwise cipher suite" add "A pairwise cipher suite of key size smaller than that used on the connection between the STA and the AP should not be used."

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