Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Jay, Thank you for your email. I don’t see the need for developing a complex protocol (i.e., defining virtual APs to derive a key for the link between APs). >> Anyway, I hear some members said they don't like the mesh protocol, and we could define a new MAPC security procedure to allow inter-vendor authentication,
let's walk on this direction if no one object it. What mechanism do you have in mind ?
From: yang.zhijie@xxxxxxxxxx <yang.zhijie@xxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Abhi , Thanks for the response. There is some misunderstanding on your side, let's try to clarify in the reflector. If your look at the following figure captured from my contribution, the L-AP(or mesh STA in the SP) only own MAPC discovery and MAPC authentication function, once the trust link is setup
between two mesh STAs , AP1 and AP2 can generate the PTK and exchange the GTK , and protect the following MAPC frame exchange. Again, the procedure of MAPC negotiation and MAPC transmission is still between two UHR APs , not between two mesh STAs . This framework
allow the two APs are configured with the same credential information(to reuse SAE(authentication using a password)) without disclosing their infrastructure credential information to each other. As Mike suggested before, the mesh protocol allow the mesh STA to authentication with multiple mesh STAs , that's why we try to reuse some of the useful mesh procedure. Anyway, I hear some members said they don't like the mesh protocol, and we could define a new MAPC security procedure to allow inter-vendor authentication, let's walk on this direction
if no one object it. Thanks Best Regards Jay Yang (杨志杰)
Original From: AbhishekPatil <appatil@xxxxxxxxxxxxxxxx> To: 杨志杰10343608;STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
<STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>; Date: 2025年02月25日
06:21 Subject: RE: [STDS-802-11-TGBN] Your PPT on MAP protection Hi Mike, Jay, Xiaofei , In 11s mesh, two mesh STAs perform mesh peering - which is a form of loose association between them. The peering is directional, and each party need to initiate it. The AID that is assigned is used (amongst
other things) for traffic indication (via TIM IE in each STA’s Beacon frame). So, in some sense, it is AP/client relationship (based on the direction). In MAPC , APs negotiate the terms of coordination for one or more flavors of MAPC . The intention of AP ID is to identify the AP during the coordination TXOP (i.e., triggering). Therefore, MAPC negotiation
must not be equated to performing associating or peering. Let’s not mix them or try to force fit MAPC negotiations into 11s peering framework. Regards, Abhi From: Jay Yang <yang.zhijie@xxxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Mike, Thanks for the clarification, that's why I propose to define a light Mesh STA concept, as we don't need all the functionality of the current mesh STA. Hi Xiaofei , As the mesh protocol already define the mesh discovery procedure, we can insert some MAPC relevant IEs into the message exchanged in the discovery procedure(also, strip out the unnecessary
part). On the other hand, MAP discovery procedure is invisible to the client, define a light probe request/reponse or Beacon via the mesh discovery procedure can void the overhead issue. Hope the above explaination can address you concern, and welcome the further comments. A clean revision of SP text: Do you agree to define light mesh STA with the following: 1) a modified mesh procedures to support MAPC discovery and support MAPC authentication(including PTK generation and GTK exchange) . Note1: It's TBD to reuse or modify the AMPE or PASN protocol. Note2: Other functionalities are TBD .
Thanks Best Regards Jay Yang (杨志杰)
Original From: MMontemurro <montemurro.michael@xxxxxxxxx> Date: 2025年02月12日
03:19 Subject: Re: [STDS-802-11-TGBN] Your PPT on MAP protection Hi Xiaofei , The pieces of mesh that I was referring to were peering messages (Open/Confirm/Close) along with group key behavior (to protect MAP). We could also strip out fields/elements of peering messages that we don't need. This would be work TBD . Cheers, Mike On Tue, Feb 11, 2025 at 12:48 PM Xiaofei Wang <Xiaofei .Wang@xxxxxxxxxxxxxxxx> wrote:
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 |