netdev - Re: [RFC] mac80211: clean up frame receive handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1197634385.16079.34.camel@johannes.berg>
Date:	Fri, 14 Dec 2007 13:13:05 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Jouni Malinen <j@...fi>
Cc:	linux-wireless <linux-wireless@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	Michael Wu <flamingice@...rmilk.net>,
	Tomas Winkler <tomasw@...il.com>
Subject: Re: [RFC] mac80211: clean up frame receive handling

> Is there any way for an user space application to figure out whether a
> received EAPOL frame was encrypted? In theory, WPA/WPA2 Authenticators
> (e.g., hostapd) should verify that the frame was encrypted if pairwise
> keys are set (whereas IEEE 802.1X Authenticator accepts unencrypted
> EAPOL frames).

Unfortunately not. Does that really matter? It seems that the
verification whether the frame was encrypted would either be "always
require encryption when pairwise keys in use" (which this patch doesn't
do right now but could trivially be done) or simply "don't care since it
doesn't really matter".

> Did you/someone already verify that the Linux bridge code does not
> bridge EAPOL frames? The use of a separate interface for this removed
> the need for doing such filtering based on ethertype, but with EAPOL
> frames using the same netdev with other data frames, the bridge code
> should filter these out (mainly the PAE group addressed ones, but if I
> remember correctly, IEEE 802.1X specified all frames using EAPOL
> ethertype not to be bridged).

Actually, 802.1X doesn't specify that, as I said previously it
*recommends* it in C.3.3 (not C.1.1 as the 802.11 specs lead you to
believe). Also, a patch to do this was rejected by Stephen Hemminger, so
I decided to only pass up EAPOL frames that are either for our own
unicast address or the link-local eapol address, both of which won't be
bridged.

> I haven't looked into the current implementations and/or proposed
> patches on for TX part, but I would assume that it is possible to select
> whether an EAPOL frame will be encrypted when injecting it(?).

Yes, by setting the F_WEP flag on any frame you decide whether it will
be encrypted (if possible) or not. Right now, the corresponding hostapd
patch always sets that flag.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)