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

Re: [STDS-802-11-TGBN] Updates to MAPC Security Protocol

Hi Jay,

Thanks for your comments.

The contritribution simplifies MAPC security negotiation by leveraging existing Authentication methods. It is extensible and works with any authentication method that generates a PMKSA/PTKSA as part of authentication. Of course because this is MAPC, there is some mapping required between the requesting AP and the responding AP to the parameters that are bound in the key derivation.

What exactly is the security issue if you apply 802.1X over authentication frames to MAPC security negotiation? If there is an issue, I can update my contribution to address it.

You imply that there is an association procedure (by that, I assume that you mean an exchange of Association Request and Association Response frames) in my contribution. I assure you there is not.

The objective of my contribution is to leverage existing authentication methods already defined in the baseline to be used for MAPC authentication, over MAPC Negotiation frames. 

Cheers,

Mike


On Thu, Mar 5, 2026 at 6:50 PM <yang.zhijie@xxxxxxxxxx> wrote:

Hi Mike,


Thanks for the efforts on this pdt . 


I just provide some high level comments here.

For PASN , as we discussed before, it's designed for the infrastructure network case at the very beginning, which can't meet the special requirement of MAPC . To avoid the over load of traditional PASN protocol, we add MAPC PASN procedure, in which each difference points is very carefully to clarify compared with the basic PASN protocol.  

It doesn't work at all as you did in the pdt : strike it out totally but just leave some MAC address clarification.


For 802.1X authentication, there are only two authentication frames exchange during PTKSA derivation phase, which will cause additional security issue if you apply to MAPC case directly.  We should change it to three authentication frames exchange in MAPC case as I did my PDT 25/1860r6.

Aslo , this is no association procedure in MAPC , but it seems there is based on in your pdt .


I don't see any additional use case covered by EPPKE , I don't understand why you want to introduce it to MAPC security. Just make the SPEC being more complicated.





Thanks


Best Regards


Jay Yang (杨志杰)



Original
From: MMontemurro <montemurro.michael@xxxxxxxxx>
Date: 2026年03月05日 22:56
Subject: Re: [STDS-802-11-TGBN] Updates to MAPC Security Protocol
Hi all,

Thank you very much for your review and comments provided offline. I've addressed all the techical comments on the contribution that I've received and posted an updated document here:

Cheers,

Mike

On Mon, Mar 2, 2026 at 9:39 AM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:
Hi all,

I posted the following document which updates and simplifies MAPC Security Negotiation and addresses 22 CIDs . 


Cheers,

Mike

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