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

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

Hi Mike,

Thanks for the further comment.

You also commit that 11bn group only agree to use PASN for MAPC authentication based on the passed motion. Whether 11bn group agree other authentication mechanism rely on the additional motion.

I stress many times in this mail thread, the door is still open, anyone can propose any additional solution in the future. But we can't reflect some potential solutions into PDT if there is no relevant motion to support it.

Actually, we don't have word in the passed motion to say encapsulating PASN protocol into the MAPC negotiation, I don't think it will work as the current PASN protocol only have 3 authentication frames, I suspect you propose to couple public action frame with the protected dual of public action frame into one procedure, if that's ture, it will cause additional complicated.

Anyway, let's make it simpler as EDPKE protocol did, which is very good example, just add some clarification on the difference based on current PASN protocol to achieve our target.

Again, the current PDT is quite closed aligned with the passed motion, let's move forward step by step. It's great appreciated if you can support TGbn task group job.

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月22日 21:09

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

Hi Jay,

First of all, the motion defines a procedure to use PASN for MAPC authentication. It does not exclude any other authentication mechanism.

Secondly, encapsulating authentication protocol content in MAPC negotiation does work and is actually simpler to specify and makes MAPC negotiation agnostic to the authentication protocol.

Cheers,

Mike

On Mon, Jul 21, 2025 at 8:12 PM <yang.zhijie@xxxxxxxxxx> wrote:

Hi Mike,

Thanks for the further comment, we do have the following motioned to say using PASN to generated keys for the protected dual of action frames. The current PDT is aligned with the passed motion, we need move forward based on 11bn group agreement.

[Motion #428]
• TGbn defines a procedure based on pre-association security negotiation (PASN ) or uses PASN with necessary extensions to derive the key(s) needed for the protected version of individually addressed MAPC Negotiation Request frame and MAPC Negotiation Response frame exchanged between two APs as part of MAPC operation.

That's fine if you can propose other solution, but it's better we have another motion to support your proposal, I'm happy to help to convey your coming SP/motion to the PDT if there is any.

The door is still open, I never say the PASN protocol is the only solution one, welcome the group member share more thoughts on this. But I can't add anything relevant 802.1X to the PDT until the group agree on another motion.

As I mentioned before,we really do some seriously study on your proposal, but we found encapsulating the PASN protocol within the MAPC Negotiation Request/Response frames doesn't work, I suspect you also agree on this. Therefore, we have to drop this direction, and to have the simple one as the PDT shows.

Some members have more thoughts on 802.1X protocol to apply in MAPC authentication scheme, I believe your proposal will cause more technical challenges, we need more discussions before we talking any action on this.

I appreciate if you can support TGbn group job and make some progress.

Thanks

Best Regards

Jay Yang (杨志杰)

Original
From: MMontemurro <montemurro.michael@xxxxxxxxx>
To: 杨志杰10343608;
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;
Date: 2025年07月22日 03:16
Subject: Re: [STDS-802-11-TGBN] PDT MAPC PASN (11-25/1049r0)
Hi Jay,
My issue is I'm not sure we agree on what was actually motioned. I agree that there is an agreement to use PASN . I don't agree that the use of PASN is exclusive. For instance, I can identify deployment requirements were it would be more appropriate to use IEEE 802.1X authentication for instance (centralizing authorization for MAPC establishment, for example).

For this reason, I think we should make the protocol more generic and encapsulate the contents of an authentication frame rather than define a specific authentication protocol for this purpose.

I have two issues:
1) A MAPC connection is between two peer APs that are operating BSS(s) and use a separate discovery process. To differentiate MAPC establishment from infrastructure connections, the authentication protocol should be encapsulated within the MAPC Negotiation Request/Response frames.
2) I have no issues with using PASN for authentication. However I think the authentication protocol for MAPC should be generic enough to use any authentication prrotocol (including 802.1X).

At this point, I cannot support the text you are proposing but I believe it is possible to address my comments by modifying the contribution. I will not be in Helsinki and would like to discuss this offline so that we can come to an agreement on the updates to your contribution.

Thanks,

Mike

On Mon, Jul 21, 2025 at 2:53 PM <yang.zhijie@xxxxxxxxxx> wrote:
Hi Mike,

Thanks for the response.

First, the current PDT is aligned with the passed motion,it will be good if you can point out any technical issue on current revision.

I'm happy to reconsider your comment if you can address the following technical issue:
If I recalled correctly, you propose to encapsulate PASN frame body into action frame,the problem is that the 2-PASN frame can't be included into the protected dual of action MGMT frames as the A-pub must be disclosed outside, therefore, I don't know how to protect the MAPC agreement within three PASN frames.

No worry, we could continue the discussion via reflector or F2F talk in any session.

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月21日 22:47
Subject: Re: [STDS-802-11-TGBN] PDT MAPC PASN (11-25/1049r0)
Hi Jay,
I reviewed your contribution and the document does not include changes with respect to comments that we provided you offline.

Unfortunately, I will not be in Helsinki and was wondering if you could address our comments in a revised version.

We would be happy to discuss the document with you in Madrid.

Cheers,

Mike

On Fri, Jul 18, 2025 at 9:52 PM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:
Hi All,

MAPC PASN PDT is updated to R1 now based on some offline feedback (see it in the attachment), welcome the further comments.

Thanks

Best Regards

Jay Yang (杨志杰)

Original
From: 杨志杰
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;
Date: 2025年07月01日 15:17
Subject: [STDS-802-11-TGBN] PDT MAPC PASN (11-25/1049r0)
Hi Alfred,

Could you help put MAPC PASN PDT(11-25/1049r0 https://mentor.ieee.org/802.11/dcn/25/11-25-1049-00-00bn-pdt-mac-mapc-pasn-part-1.docx) to the MAC agenda?

Dear MAPC TTTs ,

MAPC PASN PDT is ready now, please help review it, and welcome your valuable comments.

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

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