| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Gabor, Thanks for your comments. Please see my response inline. From: Gabor Bajko <gabor.bajko@xxxxxxxxxxxx> CAUTION: This email originated from outside of
the organization. Apologies, I missed the presentation of this document, I have some observations down below: From: Duncan Ho [mailto: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).
This could be achievable by a separate signaling mechanism after the 4-way handshake is completed and a PTKSA is established, just like you propose below for the exchange of L2 addresses. And such a mechanism
would be independent of the authentication/association procedure. [DH] Please see my explanation of such scheme highlighted below. [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. The 4-way handshake is preceded by authentication and association. The earlier the L2 addresses are exchanged and confirmed, the better. With SAE, there is a possibility to exchange and verify the addresses during
the authentication message exchanges, and I think that would be a much better solution than waiting for the verification to be done during the 4-way exchange. [DH] Yes as my slides also mentioned, such optimization for SAE could be explored but keep in mind we still need a solution for non-SAE
authentication. Thanks, Duncan 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 *********** MEDIATEK Confidentiality Notice *********** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! 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 |