| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Duncan, Thanks for initiating the conversation. Please find my response inline. Regards, Rojan From: Duncan Ho <dho@xxxxxxxxxxxxxxxx> Hi all, Sorry we ran out of time answering questions on the call today. I’ll try to answer them below here and please send me other questions you may have. Rojan asked: How can 4-way handshake pass? Answer: The 4-way handshake is between the non-AP MLD and the AP MLD and in MLO case it uses the MLD addresses to generate the PTK. Only the non-AP MLD and AP MLD know the PMK. The attacker does not change anything in the 4way handshake
so the 4WH will pass. The problem is the attacker has changed one of the STA MAC addresses of the non-AP MLD included in the Association Req msg, which goes undetected. [RC] Thanks for clarifying, I understand your problem statement better now. I thought you meant the 4-way handshake is also performed with the attacker.
If we add the STA MAC addresses of the non-AP MLD in one of the protected msgs within the 4way handshake, the AP will receive the protected STA MAC addresses. Same idea goes in the other direction (AP MLD to the STA MLD). [RC] By the same logic, the attacker could also modify many other fields in the Association request or even the response frame then right, e.g. the AID, or any of the capabilities fields etc. This is true even
in legacy devices, but I don’t see those being included in the 4-way handshake. I have the same concern as Sai, using this method the L2 MAC Addresses are tied to the 4 way handshake. I think the MLD framework gives us an unique opportunity to de-couple the
L2 MAC Address from the Security association, paving the way for L2 MAC address randomization or local address assignments; but with this proposal it is again tying the L2 MAC addresses with the SA. Every time the non-AP MLD’s L2 MAC address changes, the 4-way
handshake needs to be re-performed. Although such schemes may be out of scope of 11be,
I strongly believe we should not close the door on such future directions. For example, IETF is in the process of finalizing such a L2 MAC Address assignment scheme (https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-07).
And we also have SA Query procedure that the AP MLD can use to verify the non-AP’s L2 MAC addresses.
I think an simple alternative could be this: upon completion of the 4-way handshake the non-AP MLD informs the AP MLD of its L2 MAC Addresses using protected Management frame exchange (e.g. another (protected)
association request frame or a new protected action frame) and the AP MLD updates its record. What do you think?
Yongho asked: can we change the MAC address part as the following? The MAC address(es) of the STA(s) of the non-AP MLD corresponding to the link(s) it intends to setup with the AP MLD. Answer: Absolutely. Thanks, Duncan To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |