Re: [STDS-802-11-TGBN] MAPC PASN PDT(11-25/1049)

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

Hi Jay,

Thanks for the update.

Please see my further inline comment below (BLUE).

Regards,

Arik

From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: יום ג 29 יולי 2025 12:12
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] MAPC PASN PDT(11-25/1049)

Hi Arik,

Thanks for the comments. See my response inline in red font, and the relevant changes are in R5(in attachment).

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: ArikKlein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx>

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

Date: 2025年07月29日 16:56

Subject: Re: [STDS-802-11-TGBN] MAPC PASN PDT(11-25/1049)

Hi Jay,

Thanks for sharing R4.

Here some further comments.

1. Still, the updates in clause 11.3.4 are irrelevant since they are all related to the MLME-AUTHENTICATE.request primitive and MLME-AUTHENTICATE.response primitive – which are irrelevant in the case of MAPC Authentication.

<Jay> remove the relevant change.

a. I suggest to add a new subclause under 37.7.1 (MAPC unified framework) for the MAPC Authentication and define the new MLME primitives that the SME should use when it required the invocation of the MAPC Authentication frames.

<Jay> Tranditionally, all the security schemes and security amendment will be in subclause 12, I perfer we should follow the baseline writing style without breaking 802.11 skeleton.

Regarding the the new MLME primitive, we could address it next round as Mike suggest I remove it in the last mail.

2. In addition, in 12.XX.1 General, you mention that “ The three Authentication frames are exchanged by two UHR APs “ – it should be MAPC Authentication frame. Please revise.

a. Need to apply this comment throughout the entire document (i.e. other instances of Authentication frame)

<Jay> Should be done thoughout the PDT, please double check.

3. In the following sentence “SAE AKMP 00-0F-AC:8 or 00-0F-AC: 24 can be used as the Base AKMP if Base AKMP is present “ – what do you mean by “if Base AKMP is present “?

<Jay>In the first MAPC PASN frame, the initiating AP may indicate the Base AKMP in RSNE for RSNA authentication. It follows the baseline behavior, please check PASN and EDPKE( in clause 12.16.9 )

[AK] According to 12.13.3.2 PASN frame construction and processing, it clearly states:
“Upon receiving the first PASN frame, the AP:…..
— Verifies the public key as specified in 5.6.2.3 of NIST SP 800-56A R2. If verification fails, the

processing status is set to INVALID_PUBLIC_KEY. Verifies that a PMKSA named via a PMKID

in the RSNE exists for the specified base AKMP, or the base AKMP is set to PASN AKMP or base

AKMP data exists in the frame to allow a PMK to be established. If base AKMP is equal to PASN

AKMP, verifies that dot11NoAuthPASNActivated is set to true. Otherwise processing status is set

to REFUSED”
That means, that the base AKMP is always included in the PASN frames: if authentication is applied – the base AKMP shall point out for the PMKSA that is used. Otherwise (i.e. dot11NoAuthPASNActivated is set to true ) the base AKMP should be set for PASN AKMP.

Therefore, there is no case where the base AKMP is not present in the PASN frame. Please revise the relevant sentence above.
P.S. you may also see it in Figure 12-59 that base AKMP is present in all PASN frames where the keys are established.

2. In the following sentence: “ The entity of MAPC requesting AP is used instead of non-AP STA “ is unclear – consider revising it to “ The functionalities of the non-AP STA defined in 12.13 should be done by the MAPC requesting AP”.

<Jay> done, please check.

Regards,

Arik

From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: יום ג 29 יולי 2025 09:45
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] MAPC PASN PDT(11-25/1049)

Hi Mike,

Thanks for the further comment. The change in clause 6 is removed in R4(see it in the attachment), please continue to review it.

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: MMontemurro <montemurro.michael@xxxxxxxxx>

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

Date: 2025年07月29日 15:20

Subject: Re: [STDS-802-11-TGBN] MAPC PASN PDT(11-25/1049)

Hello Jay,

Thanks for this. I think the document looks mostly good. However you no longer need the changes to the MLME-Authenticate primitives since the authentication frame body is carried in MAPC Negotiation Request/Response frames. You can delete the Clause 6 changes.

Cheers,

Mike

On Tue, Jul 29, 2025 at 9:08 AM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:

Hi All,

Based on the comments from Mike, I update the PDT to R3(see it in the attachment), welcome the further comments.

Hi Alfred,

Could you help put the following SP to the MAC agenda?

SP on 25/1049r3 PDT MAC MAPC PASN .



Thanks

Best Regards

Jay Yang (杨志杰)



Original

From: 杨志杰

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

Date: 2025年07月27日 20:57

Subject: [STDS-802-11-TGBN] MAPC PASN PDT(11-25/1049)

Dear all,

The MAPC PASN PDT is updated to R2 now(https://mentor.ieee.org/802.11/dcn/25/11-25-1049-02-00bn-pdt-mac-mapc-pasn-part-1.docx) based on the online/offline feedback in Espoo.

Welcome the further comment and suggestion via the reflector or F2F talk in Madrid.

Thanks

Best Regards

Jay Yang (杨志杰)



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

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

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