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

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

Hi Jay,

With respect to the text you quote in green, I believe the requirement is that the MAPC Negotiation Request/Response information be protected. That does not necessarily mean that the entire frame needs to be cryptographically encapsulated using CCMP or GCMP. The output of any authentication protocol in 802.11 is a PMK which can be used to generate a PTK.  You do not need to perform the 4-way handshake if that's what you mean by "decoupling". 

Any PMK should be available to create keys (a PTK if you want to call it) to protect MAPC Request/Response frames). 

I have no intention of running an SP on my contribution on the reflector. We need to have text for the TGbn draft and in my opinion at this point, running more straw polls is  counter productive.

Cheers,

Mike




On Wed, Jul 23, 2025 at 3:40 PM <yang.zhijie@xxxxxxxxxx> wrote:
Hi Mike,


As communicated to you offline, the text should provide the encapsulation of the authentication protocol in MAPC Negotaition Request/Response frames, and the protection of the MAPC elements as part of the same protocol. 
<Jay>Regarding this suggestion, it's NOT aligned with the passed motion, the passed motion says the protection is for the whole frame, not the single elements(see the highlight part).

[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.


Regarding your comments during the call,  the authentication frames between two APs have already been applied in mesh network(MBSS), you should attack MBSS in the baseline first. 



Also, please kindly think about the following technical issues on your proposal I mentioned before:

The proposed generic authentication in MAPC Negotiation frames will involve all the current exist authentication protocol, some security protocol, like SAE, FILS, etc. don't work without any change.  For SAE, you need to add additional change to generate PTK, for FILS, you need to decouple the association procedure first. That's, based on the direction your proposal, we need many changes to complete MAPC security. It's not a simple way, IMHO.

I recalled you also prepare a contribution to ellabrate your proposal in the MAC queue. I suggest you to share your ideas before I ran the SP(e.g. tell Alfred you want jump to queue), and see how other members feeling on this. If your proposal get majority support, we could go with your proposal. Otherwise, I will work aligned the passed motion, and move forward. Hope such suggestion also work for you.



Thanks


Best Regards


Jay Yang (杨志杰)



Original
From: MMontemurro <montemurro.michael@xxxxxxxxx>  
Date:  2025年07月23日 22:11  
Subject: Re: [STDS-802-11-TGBN] PDT MAPC PASN (11-25/1049r0)  
Hi Jay, 

PASN is an authentication protocol that is part of the RSN security framework.

I don't have issues with the motion, I have issues with the proposed text you have provided. 

As communicated to you offline, the text should provide the encapsulation of the authentication protocol in MAPC Negotaition Request/Response frames, and the protection of the MAPC elements as part of the same protocol. 

At this point, I'm not focused on the TGbn bureaucracy and motions that do not produce text for the draft, I would like to see the text in the draft of the amendment. 

Cheers,

Mike

On Wed, Jul 23, 2025 at 10:03 AM <yang.zhijie@xxxxxxxxxx> wrote:
Hi Mike,

Thanks for your admitting that the proposed PDT is aligned with the passed motion. Based on that, I don't see any reason to block the task group job.

1) Please remember PASN is just a security framework, we could further extend it with "PASN with X" as the baseline did, or we could define some new base AKM to meet some new requirement in the future, it's extensible indeed.
 2) Regarding to your second questions, as authentication frames between two APs has already been applied in MBSS, you should attack MBSS in the baseline first. 

I ask the techanical issue on encapsulating PASN in MAPC Negotiation frames you proposed several times, but I don't get any positive feedback till now, so I don't know how to consider your comments:

1) Do 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. 

2) How to protect the MAPC agreement within three PASN  frames?


Again, we don't have a motion to say encapsulating a generic authentication in MAPC Negotiation frames, some sucurity protocol, like SAE, FILS, etc. can't be applied to MAPC framework.That's, encapsulating SAE or FILS don't work.  For SAE, you need to add additional change to generate PTK, for FILS, you need to decouple the association procedure first. That's, based on the direction your proposal, we need additional year to complete MAPC security. It's not simple way, IMHO.

Thanks

Best Regards

Jay Yang (杨志杰)


Original
From: MMontemurro <montemurro.michael@xxxxxxxxx>      
To: 杨志杰10343608;      
Date:      2025年07月23日 21:33          
Subject: Re: [STDS-802-11-TGBN] PDT MAPC PASN (11-25/1049r0)      
Hi Jay, 
As I said earlier, I do not support the text you propose for the following reasons:

1) Although it does align with the motion, the protocol you specify is not extensible.
2) I am concerned that by using authentication frames for MAPC, we are opening up a new attack surface for infrastructure networks.

Assuming in your reference, you are referring to EDP from IEEE 802.11bi, if you encapsulate authentication frames in MAPC Negotiation frames, you can leverage EDP without changing the draft. However I'd note that privacy is not a requirement for MAPC negotiation.

I have given similar feedback to you after you initially proposed this text and you essentially have ignored it. I'm really just suggesting a more extensible (and simpler) way to incorporate authentication for MAPC. 

At this point, I cannot support your proposed text changes.

Cheers,

Mike



On Tue, Jul 22, 2025 at 11:57 PM <yang.zhijie@xxxxxxxxxx> wrote:
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>
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;
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>
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: 杨志杰
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


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