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

Re: [STDS-802-11-TGBP] PDT security: PMK generation 11-26/1552r7 review request

Hi Mike,

 

Thanks for your comments! Please see my response below.

 

1) Assuming this text aligns with the baseline, a PMK is a PSK so I'm confused by what you are describing in clause 18.2. If you mean "the generation of a PMK based on a shared secret" I could understand that. 

 

Yes, it is actually a shared secret. I will change the subclause title to what you suggested “PMK Generation based on a shared secret”.

 

2) I haven't been involved much in TGbp, but I would expect that there could be a mode where you use a unique PSK per non-AP AMP(?) STA. 

 

Yes, a unique PSK (shared secret) per non-AP AMP STA. It is not like WPA2 that uses a PSK between an AP and all associated STAs. If the use of “PSK” term causes confusion, I will change it to “STA-specific secret” or something like that.

 

3) PMK is a product of a mutual authentication protocol. I would expect this clause would describe the authentication protocol and PMK generation would be described as part of the exchange. 

 

Yes, the idea is to authenticate the AMP AP and the non-AP AMP STA then generate a PMK between them. The authentication protocol is based on the shared secret.

 

4) In the baseline, the PMK is a product of the authentication that is used to generate the PTK. I don't have issues with multiple mechanisms to generate a PMK, but really those mechanisms should be mapped to different AKMs. I could think of three possible AKMs: 1) PMK = PSK; 2) PMK based on a shared secret; and 3) (to align with your contribution) PMK based on a modifier.

 

As I explained to you during our brief conversation in the meeting gap, we will address the AKM names later. At this moment, my goal is to get current document reaching consensus for Draft 1.0 deadline.

 

Thanks,

 

Hui

 

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, September 16, 2026 2:37 PM
To: Luo Hui (ES ICW ENG WFS) <Hui.Luo@xxxxxxxxxxxx>
Cc: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBP] PDT security: PMK generation 11-26/1552r7 review request

 

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.

 

Hi Hui,

 

Thanks for this. I reviewed this contribution and I have a number of comments.

 

1) Assuming this text aligns with the baseline, a PMK is a PSK so I'm confused by what you are describing in clause 18.2. If you mean "the generation of a PMK based on a shared secret" I could understand that. 

 

2) I haven't been involved much in TGbp, but I would expect that there could be a mode where you use a unique PSK per non-AP AMP(?) STA. 

 

3) PMK is a product of a mutual authentication protocol. I would expect this clause would describe the authentication protocol and PMK generation would be described as part of the exchange. 

 

4) In the baseline, the PMK is a product of the authentication that is used to generate the PTK. I don't have issues with multiple mechanisms to generate a PMK, but really those mechanisms should be mapped to different AKMs. I could think of three possible AKMs: 1) PMK = PSK; 2) PMK based on a shared secret; and 3) (to align with your contribution) PMK based on a modifier.

 

In the end, I think this contribution needs a lot of work.

 

Cheers,

 

Mike

 

On Wed, Sep 16, 2026 at 7:16 AM Hui Luo <0000594db8d8d1cb-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Dear All,

 

Please review PDT security document on PMK generation https://mentor.ieee.org/802.11/dcn/26/11-26-1552-07-00bp-pdt-amp-security-pmk-generation.docx. I incorporated all comments received so far. The main changes are listed below.

 

  1. Enabling PMK generation/updating protocol to proceed into the secure communication mode, which means all types of AMP frames that need to be protected are encrypted and/or authenticated with a MIC after the protocol finished successfully.
  2. Updating the write-up of 12.18.2.2 by removing the reference to “a special AP”.
  3. Changing the AEAD cipher’s nonce input description from “uplink PN” and “downlink PN” to “uplink PN and uplink indication” and “downlink PN and downlink indication”, such that we do not need to indicate uplink/downlink using the MSB of PN, and more direction-related details could be included in “uplink indication” and “downlink indication” later.
  4. Adding GTK delivery.
  5. Removing the format-related description such as “AAD data starts from where to where, encrypted data is placed where, etc.”

 

Your quick review and comments will be highly appreciated!

 

Thanks,

 

Hui

 

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

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