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

Re: [STDS-802-11-TGM] Resolutions for some comments on 11me/D1.0 (LB258)



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
CID 1840 is on the list of remaining open comments, so a comment on that one here (assuming we don't get to CID 1840 in the current slot and this comes up tomorrow morning when there is a conflict with TGbh): the proposed requirement of Key Mic bit being set to 0 in all EAPOL-Key request frames is not correct. That might be the case when an AEAD cipher is used, but this bit is set to 1 whenever an AEAD cipher is not used since EAPOL-Key request frames are sent only when there is a valid PTK in place and the Key MIC field does indeed contain a MIC (for non-AEAD cases). As such, this comment should not be accepted as-is or with the changes proposed in 353r7. At minimum, the new paragraph describing the Key MIC Present bit being set to 0 needs to be modified to cover the non-AEAD cipher case.

- Jouni


On Tue, Sep 13, 2022 at 12:52 AM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:
Copying the reflector.

Everyone,

We have enough CIDs to discuss at this stage of LB 258 comment resolution that we will not be re-considering resolved CIDs. 

Commenters can enter comments on the next LB.

Cheers,

Mike



On Mon, Sep 12, 2022 at 4:50 PM Jouni Malinen <jkmalinen@xxxxxxxxx> wrote:
Hmph.. I checked some of the CIDs in the doc against that list and those matched the list in your email, so I continued without cross-checking every CID.. Anyway, if these resolutions have already been approved, I have no issues returning to the topic once D2.0 is out.

- Jouni


On Mon, Sep 12, 2022 at 11:37 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Hello Jouni,

 

Thanks for the review.

 

Your comments are not on the new resolutions for review this week, though.

In fact, I think we have already motioned the following resolutions:

 

CID 1637:

 

REVISED

 

At 238.62 change “The protection on each Self-protected Action frame is provided by the protocol that uses the

frame.” to “The protection on each Self-protected Action frame is optionally provided by the protocol that uses the frame.”

 

At 1965.50 change “NOTE—In Self-protected Action frames, the MIC element and the Authenticated Mesh Peering Exchange element are present after the Action field when the frame is protected (see 9.3.3.13 (Action frame format)).” to “NOTE—A Self-protected Action frame is not necessarily protected.  When it is, the MIC element and the Authenticated Mesh Peering Exchange element are present after the Action field (see 9.3.3.13 (Action frame format)).”

 

CID 1881:

 

REVISED

 

Make the changes shown under “Proposed changes” for CID 1881 in <this document>, which make the changes proposed by the commenter, with minor editorial tweaks.

 

CID 1273..:

 

REVISED

 

Make the changes shown under “Proposed changes” for CID 1273 et al. in <this document>.

 

So not sure how to proceed here.  Maybe raise comments on D2.0?

 

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: Jouni Malinen <jkmalinen@xxxxxxxxx>
Sent: Monday, 12 September 2022 09:48
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Resolutions for some comments on 11me/D1.0 (LB258)

 

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

CID 1637: I'm not really convinced that we need to add a NOTE saying "A Self-protected Action frame is not necessarily protected." That seems to make this more confusing than not having the sentence there. In other words, I'd probably vote against that resolution. I don't have a better resolution to propose for this apart from likely being willing to support the comment getting rejected.

 

CID 1881: The changes to 12.4.8.6.3 are inconvenient to review since they are against the old version of those subclause and do not include things like fixing the case of SAE_HASH_TO_ELEMENT in the Status code field. I think I can support many of the changes proposed here, but I want to make sure this does not end up deleting some of the earlier (and IMHO, more important) fixes. Ideally, I'd like to see a redline against the current draft, but I do understand this means more work. I'm also not in favor of the "the password identifier, if any" as a replacement to "checking whether a password identifier is present". It is not clear that "the password identifier" is referencing the optionally present element in the received frame. That followed by "If a password identifier is present" feels confusing. Maybe "if included" instead of "if any" could be somewhat clearer.

 

CID 1273..: "except a Supplicant with which it is currently performing a 4-way handshake, in which case if it has not yet transmitted message 3 it may deliver the GTK in that message instead, or otherwise it shall initiate the group key handshake after the end of the 4-way handshake" feels a bit unclear for that initiation of a group key handshake.. Is that clear enough to be understood that this specific case of the group key handshake is just with this specific Supplicant and not the other ones? Maybe something like ".. with this Supplicant" at the end could clarify this(?).

 

 

On Fri, Sep 9, 2022 at 12:02 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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

I have uploaded 22/0353r7.  This contains resolutions for CIDs 2079, 2095/1368,

1414, 2010/1653, 1777/1776, 1837/1836, 1838, 1840, 1486, 1674, 1951, 1984, 1987,

2047, 1926, based on the directions last week, plus the updated resolutions for

CIDs 2187, 1985/1986/1535/1419/1536 based on the recent reflector discussions.

 

To help optimise the discussions next week, please review this and tell me ASAP

if you have any corrections or other comments.

 

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

 


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


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