On Mon, Feb 24, 2020 at 01:35:51PM -0600, Denis Kenzior wrote: > But it seems like the benefits outweigh the drawbacks? At least we have > been super happy with how control port works for us. If you take the > pre-auth path away, I'm really not sure there's any point in (at least for > us) keeping support for the control port path. Do you use the control port for RX only or both TX and RX? The RX side is mostly harmless _if_ something filters unprotected RSN pre-authentication frames that are received between the association and the completion of 4-way handshake. That something would either need to be the specific user space application using the interface or potentially mac80211 with some special rules that are different between EAPOL and RSN pre-authentication ethertypes. For TX, the control port path will likely result in more problematic issues. I'd expect drivers to use higher priority and/or higher reliability for delivering the frames. That is justifiable for EAPOL frames, but unnecessary for RSN pre-authentication frames. Being able to bypass the port authorization control would be undesired from security view point. The key point for me here is the concept of authorized/unauthorized port for normal Data frames based on the IEEE 802.1X standard. Only the frames critical for the authentication service (establishing protected link with the current access point) are allowed to be transmitted and received while the port used for normal data is unauthorized. For IEEE 802.11, only the EAPOL frames are such Data frames that are needed before the port can be authorized. RSN pre-authentication frames are used to establish a new security association with a different access point once the port with the current AP is authorized. As such, RSN pre-authentication frames do not need to go through any special path from the protocol view point and in fact, it would be incorrect to allow them to be transmitted or received before the main port has been authorized. The IEEE 802.11 standard describes this with "communication of all non-IEEE-802.1X MSDUs sent or received" being authorized/not-authorized. MSDU is a reference to Data frames and "non-IEEE-802.1X" in this context to any ethertype other than the one defined in IEEE 802.1X (EAPOL). As a more specific example, the EAPOL frames are expected to be transmitted unencrypted during the initial 4-way handshake (and with some old IEEE 802.1X/WEP designs and some WPA(v1) implementation, even during rekeying). On the other hand, RSN pre-authentication frames are never supposed to go out unencrypted over the air (i.e., they must not be sent or received before the encryption key has been established for the link). The IEEE 802.11 standard describes this with "A STA shall not use preauthentication except when pairwise keys are employed" and "As preauthentication frames do not use the IEEE 802.1X EAPOL EtherType field, the AP with which the STA is currently associated need not apply any special handling. The AP and the MAC in the STA shall handle these frames in the same way as other frames with arbitrary EtherType field values that require distribution via the DS." I understand that there is a different view point for this from the kernel--user space interface side and it may indeed look more convenient to use the same path for both EAPOL and RSN pre-authentication frames from that view point. If that mechanism is used, it needs to be understood that the rules for EAPOL and RSN pre-authentication frames are different, though, and it is not clear where that difference is going to be enforced if the same interface path is used. -- Jouni Malinen PGP id EFC895FA
