| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi
Duncan, Thanks for your comment. Could you have a look my contribution(DCN 1112/R2), I think it can cover the case you mentioned. https://mentor.ieee.org/802.11/documents?is_dcn=mlo%20security%20considerations Thanks Best Regards Jay Yang From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Hi Jay, Sorry I missed your email till now. My proposal is NOT to do 4-way handshake on each link of an MLD but rather the 4-way handshake is done only once (on any of the ML setup link) for each ML setup,
during which time both sides can exchange all their MAC addresses. Thanks, Duncan From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
CAUTION: This email originated from outside of
the organization. Hi Duncan, I agree what Rojan said that it’s not necessary to ask the key exchange of each link of MLD devices on L2 layer. Since the tunnel is set up between two MLD devices with their MLD <RA,TA> address, I think the key exchange for other links
can be done in this link/tunnel. As you know, the procedure of EAPOL key exchange is slower than other data frame, it’s cost too much OTA resource to repeat it.
Therefore, I have an open question on this: Do you think it’s necessary to repeat the procedure of the 4-way handshake on each link for MLD device?
Thanks Best Regards Jay Yang From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Hi Rojan, Thanks for your comments and please find my response inline. From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
CAUTION: This email originated from outside of
the organization. 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.
[DH] While those fields are not protected, that alone doesn’t mean we should not protect the MAC addresses. I think we should do our due diligence to ensure we do not break security when we develop new architecture in the spec. One unique
aspect of this MAC address attack you may lose one or more of the links that can be hard to diagnose. Say if you lose 2 of the 3 links after MLO setup, you will no idea why the other 2 links are not working since the RSSIs will look good and the 4WH completed
successfully. 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.
[DH] I have yet to think about the implication of changing the MAC addresses on the fly WITHIN an association but assuming we’re not doing that, then the 4WH is required anyway for each (re)assoc to derive the PTK for all authentication
schemes so I don’t see a problem if both sides need to change their MAC addresses across assoc. 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?
[DH] I thought about that also. However, I think the 4WH may be a better solution. The reason is once the 4WH is done, both sides can trust all the <TA, RA> pairs between the peers are valid so can be utilized and activated immediately.
Encrypted traffic can then be send on ANY of those pairs. If we use a management frame like you said and if the AP happens to send the management frame on the attacked RA, that frame will be lost. The AP will time out and retry on the same link or it may retx
that frame on another link until it finds a link that has not been attacked, if that exists. It may take more iterations and resource to recover whereas if we add the MAC address exchange within the 4WH, everything will be self-contained and the 4WH will fail
immediately if MAC address tempering is detected. 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 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 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 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 |