Re: [STDS-802-11] Solicit feedback for document 11-25/260

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

I second and also support using the same key and longer key lengths.

Commonly used algorithms such as AES support only keys of lengths 128, 192 and 256 bits - see FIPS 197 AES ((https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf)) for example. Many use AES as block cipher within them - see GCM/GMAC https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf, CMAC https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf

Below 128 bits and lower than 128 bits of security strength are not recommended for future - See https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf for recommendations that suggest at least 128 bits

On Tue, Mar 11, 2025 at 11:53 AM L. S. <lsun2005@xxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi,

I support the use of same key for control and unicast data/management frames
With smaller size keys, AP still requires additional secure storage of these keys. I also don't understand why we would use a weaker key for control protection than data.

Thanks!

On Tue, Mar 11, 2025 at 11:40 AM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Thomas,

If using the single TK is to avoid hardware requirements on APs, a compromise could be to use a smaller TK for control frame protection. I have no issues with specifying the cipher suite family, in this case, GMAC/GCMP, but there are no issues with using a smaller key.

Cheers,

Mike

On Tue, Mar 11, 2025 at 11:33 AM Thomas Derham <thomas.derham@xxxxxxxxxxxx> wrote:
Hi Mike

Regarding your item (2), we also provided some discussion on this in slide 3 of 1897r0 on Mentor.

The main benefit we see of using TK for both purposes is to avoid additional hardware requirements on APs from storage of an additional key corresponding to each STA. Noting that control frame integrity validation needs to be performed in real-time, similar to decryption of data frames.

We should not use the same key with different cipher suite families. Since we are using GMAC-256 for control frame integrity protection and GCMP-256 (the same family) for pairwise encryption, the same TK can be used.

Thanks
Thomas

On Mar 11, 2025 at 11:07:09, M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Po-kai,

Thanks for presenting this contribution in 11mf.

Here are my personal technical comments on the proposal:
1) The proposed size of the MIC and the PN in protected control frames is in the order of the size of the content of the control frame. Given these frames are transmitted frequently and at lower data rates, they will consume significant medium time. Please consider reducing the size of the frame, by at least, truncating the MIC.

2) Personally, I'm not comfortable using the same TK for data confidentiality and control frame protection. A new TK should be derived for control frame protection given that the purpose is not data confidentiality.

3) Another point that I'd like to echo from Dan is that I don't believe there should be a requirement to use GCMP-256 for control frame encryption. I think we need to be more flexible with cipher suite negotiations.

Cheers,

Mike

On Tue, Mar 11, 2025 at 8:46 AM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi,

                I presented document 11-25/260 in revmf session yesterday and I am working on addressing the comments received during the presentation.

              As instructed, I send this email to see if there are further feedbacks for the document.

              Please let me know if you have further feedbacks.

Best,

Po-Kai

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1