Re: [STDS-802-11-TGBP] Request for comments on protected security indica

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

Hi Amichai,

Thanks for your quick response!

I fully understand your desire to have a simple implementation on non-AP AMP STA, and these SPs are adjusted to deliver what you want.

First of all, there is no security parameters negotiation in SP1154. The STA dictates what it wants for security. The AP takes the STA’s implementation and works with the STA. The only thing different from your single-security-solution-for-all-11bp-devices idea is that it is too difficult to demand different STAs for different uses to converge to a single security solution. For example, do we want to exclude the entire 11bp standard-compliant devices from bidding government projects that demand 256-bit encryption? The answer is surely no. Then do we want to force all STAs to implement 256-bit encryption even if they do not need it? The answer is also no. So it is probably the most plausible idea to let a STA dictate the security solution and indicate its security parameters for the AP to work with the STA. That’s exactly suggested by SP1154.

In SP0942, there is no forced short ID assignment by the AP. On the contrary, the only chance for the AP to assign short ID to a STA is when the AP has to do it in order to enable 1:1 communication or for privacy protection if demanded by the STA. If the STA has a self-generated short ID and if the AP learns this short ID through an inventory process or by any other way, the AP won’t do short ID assignment. Even if the STA’s short ID has collision, the AP won’t do short ID assignment either if the AP does not need to communicate with the STA. Only when the AP initiates a 1:1 communication with the STA but the STA has a short ID that is owned by another STA in communication with the AP, the AP will do a short ID assignment in an optional field of the first protocol frame to the STA.

Please let me know if you still have concerns with the above explanation.

Thanks,

Hui

From: Amichai Sanderovich <amichai.sanderovich@xxxxxxxxxx>
Sent: Tuesday, June 16, 2026 3:44 AM
To: Luo Hui (CSS ICW ENG WFS) <Hui.Luo@xxxxxxxxxxxx>; STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx
Subject: FW: Request for comments on protected security indication SP and short ID assignment SP

Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide to help you identify Phishing email.

Hello Hui Luo,

Please see inline below our comments/concerns on the added SPs.

Best Regards

Amichai

From: Hui Luo <0000594db8d8d1cb-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, June 4, 2026 10:52 AM
To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBP] Request for 11bp 6/9 teleconference

Hi Bo,

I cannot dial in 6/9 11bp teleconference due to WFA Boston meeting conflict. Please postpone my 11-26/1137 presentation to the next 11bp teleconference. It would be better if you can swap the order of 11-26/1137 and 11-26/1154 so that I can present 11-26/1154 earlier.

Additionally, could you put the following SFD SPs in MAC queue?

SP11-26/1154 SP1

Do you agree to add the following text in the TGbp SFD --- 802.11bp shall specify a protected security parameters indication method by including a STASecurityParameters field in the first AMP uplink frame of all secure AMP communications protocols, such that a non-AP AMP STA can indicate its security parameters (cipher algorithm, MIC algorithm, key sizes, etc.) to an AMP AP for carrying out the secure communication protocol.

Note: This does not apply to mono-static backscatter non-AP AMP STAs.

Reference: 11-26/1154, 11-26/0855, 11-25/2106

Even in legacy specification such variance does not exist. For AMP even more so

We rely on basic default behavior that does not require capability exchange of any kind

having a parameter exchange and also securing this exchange significantly complicates implementation,

SP11-26/0942 SP1

Do you agree to add the following text in the TGbp SFD --- 802.11bp shall specify a short ID assignment method embedded in the first downlink AMP frame in 1:1 AMP communication by the following?

If an AMP AP knows the long ID of a non-AP AMP STA and if one of the following conditions is met: (1) the non-AP AMP STA does not have a short ID but needs one for the 1:1 communication, (2) the non-AP AMP STA has a short ID in collision with another non-AP AMP STA and needs to be fixed, or (3) the non-AP AMP STA’s short ID should be changed for privacy reason, the AMP AP includes an “AMPSTAShortIDAssignment” field in the first downlink AMP frame of the 1:1 AMP communication session with the non-AP AMP STA, where the “AMPSTAShortIDAssignment” contains the non-AP AMP STA’s long ID or the (truncated) hash value of the long ID with the rest of the frame, and a short ID assigned to the non-AP AMP STA.

We think this approach makes sense only for non-secured unicast communication without MAC address. This is not agreed yet, and we are not sure it is required (unicast w.o. MAC address).

We assume that short ID when it is needed, is self assigned by the non-AP STA. By switching assignment responsibility we complicate the implementation

If the non-AP AMP STA has NVRAM and saved the assigned short ID in NVRAM, it includes an “AMPSTAShortIDSaved” field in the first uplink AMP frame in case of no security requirement, or in the second uplink AMP frame after the non-AP AMP STA authenticates the AMP AP by verifying the MIC of the second downlink AMP frame.

This approach requires multiple frame exchanges in order for assigning short ID, which is something we’d like to avoid.

In case the “AMPSTAShortIDAssignment” is included in the first downlink AMP frame of a 1:1 secure AMP communication session, the non-AP AMP STA includes the “AMPSTAShortIDAssignment” in MIC calculation for the first uplink AMP frame, and the AMP AP includes it in MIC calculation when verifying the MIC of the first uplink AMP frame.

We prefer that MIC is not calculated on fields that do not exist in the transmitted frame containing the MIC. It complicates the implementation.

If the AMP AP receives the AMPSTAShortIDSaved, it creates a profile for the non-AP AMP STA, saves <non-AP AMP STA’s long ID, assigned short ID in NVRAM> in the profile, and uses the assigned short ID in future communications with the non-AP AMP STA without including the “AMPSTAShortIDAssignment” field in the first downlink AMP frame.

Note: the above protocol does not apply to mono-static backscatter non-AP AMP STAs.

Reference: 11-26/0942, 11-25/2106

Thanks,

Hui Luo

Infineon Technologies

From: Luo Hui (CSS ICW ENG WFS)
Sent: Monday, June 1, 2026 10:07 PM
To: 'sun.bo1@xxxxxxxxxxxxxxxx' <sun.bo1@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBP] reminder of TGbp TC on May 26

Hi Bo,

Could you add the following technical contribution to the MAC/security queue?

11-26/1137, “Improvements on identity privacy and anti-tracking privacy for secure inventory”

Thanks,

Hui Luo

Infineon Technologies

From: sun.bo1@xxxxxxxxxxxxxxxx <sun.bo1@xxxxxxxxxxxxxxxx>
Sent: Monday, May 25, 2026 12:14 PM
To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBP] reminder of TGbp TC on May 26

Hello, all,

A tentative agenda for the coming TC is uploaded to the server, with focus on the pending SPs and one PDT proposal.

https://mentor.ieee.org/802.11/dcn/26/11-26-1112-00-00bp-tg-bp-tc-agenda-till-jul-2026.pptx

Best Regards,

Original

From: 孙波

To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx>;

Date: 2026年05月22日 17:55

Subject: [STDS-802-11-TGBP] reminder of TGbp TC on May 26

Hello, all,

I hope you have a safe travel back.

As annonced during the May interim week, we have planned several TGbp TCs till Jul plenay session and the next coming TC will be on May 26.

The current TGbp submission list is empty but we do have lots of pending SFD SPs. So the TC agenda will consist of both pending SFD SPs and potential submissions including both PDT proposals and techn contributions.

If you have submissions for the coming or following TCs, please announce your submission request to the reflector, so that I can setup the agenda for coming TCs. Thanks!

Best Regards,

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

Re: [STDS-802-11-TGBP] Request for comments on protected security indication SP and short ID assignment SP