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

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



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

Not speaking as Chair (since I wasn't Chairing at the time), its was pretty clear to me that the last time we discussed this CID on the call, the recommendation was Reject the comment unless YOU come up with an alternative resolution, so the comment was assigned to you.

Neither I nor the TG have heard anything with respect to this comment for 6 months. I had to look in your document to find your proposed alternative resolution before I sent the email to the reflector. 

So we have two alternatives to resolve the CID which I presented in my email which we discussed on today's call. However my personal preference is still to reject the comment.  

Thanks for posting the minutes excerpt and discussion section from your document. We'll discuss and resolve the comment on the call today.

Cheers,

Mike

On Thu, Nov 11, 2021 at 12:28 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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


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