On Wed, Oct 04, 2006 at 01:57:38PM -0400, Dan Williams wrote: > On Wed, 2006-10-04 at 16:19 +0200, Johannes Berg wrote: > > On Wed, 2006-10-04 at 09:41 +0200, Johannes Berg wrote:
> > Should cfg80211 do the chore of keeping track of the whole scan results? > > On the other hand, that doesn't seem to be doable with legacy hardware > > that does all the scanning. So probably one call for > > cfg80211_notify_scan() > > that takes a new scan result structure (taking a single BSSID etc.) and > > notifies all listeners. > > The same structure is used for get_scan() from the wiphy ops in an > > iterator interface like some other calls. > > Is it a problem to actually push the _entire_ scan list out to clients > over netlink? The scan list could be quite large, maybe even a few > kilobytes when stuff like Information Elements, ratesets, etc is > available. I've seen 35-item scan lists that are already around 1.5K. 1.5 KB sounds like a small scan result set to me.. I'm hitting 100+ BSSes at work (well, not really your normal environment ;-), and 50 at home.. These go way beyond 1.5 KB; closer to 32 KB at times, I'd guess. > There are several issues here. They can be roughly split by encryption > algorithm. But the big question: > > Is there a case for _multiple_ encryption algorithms enabled > on a single "virtual" interface at one time? What exactly do you mean with this? WPA allows different STAs associated with an AP to use different unicast encryption algorithms. This means that a client may need to use CCMP with key index 0 for unicast and TKIP with key index 1 for multicast. > Taking one-at-a-time as a given, and the pseudo-structure > > struct cmd_crypto { > enum crypto_alg alg; > union data { > none_data; > wep_data; > wpa_data; wep vs. wpa in crypto configuration does not make sense to me. WPA uses multiple ciphers; even WEP is allowed for group keys.. > Set alg == <whatever>, set the options, and the driver will _enable_ > that crypto mode with the given options. It makes no sense at all to, > say, set the WEP transmit key index or WEP key when the card is in WPA > mode or no-crypto mode. What is this "WPA" mode? Please note that IEEE 802.11i allows WEP to be used for group (multicast/broadcast) keys.. WPA should not be mixed in here with encryption key configuration. The are different encryption algorithms, like WEP, TKIP, CCMP, and they need to have keys and other parameters like key index and seq# configured. This is regardless of whether WPA is used or not. > It's important to note that some options are independent of the initial > operation that enabled the crypto, and need to be set later without > triggering deauth and such. Setting non-TX-index WEP key is one such > operation. I should be able to set WEP keys at indexes other than the > transmit key index without affecting operation of the card (unless some > hardware/firmware issue prevents this). And same for TKIP and CCMP. > - WEP encryption (following ops are independent of each other): > - Set TX key index > - Set privacy invoked These two are not WEP specific in any way. > - Set exclude unencrypted packets I would consider this more as a global variable for the BSS to match with dot11ExcludeUnecrypted variable defined in IEEE 802.11. In theory, this is not specific to WEP, but in practice, only WEP is sometimes used in mode which allows both encrypted and unencrypted frames. > - Set authentication mode (open, shared-key, or both) Not really WEP specific. Shared Key authentication can only be used with static WEP keys, but still, this configuration is not really part of crypto configuration. In addition, Cisco uses a proprietary "Network EAP" authentication algorithm and IEEE 802.11r is adding a new authentication algorithm, so there are more options to this configuration variable. > - Set (or clear) WEP key 1, 2, 3, or 4 Not specific to WEP. > - WPA/WPA2/IEEE8021X > - Jouni/others would know better and my brain is fried right now This item should not be WPA/WPA2/IEEE8021X, but TKIP/CCMP, i.e., ciphers like WEP.. Just like with WEP, there would need to be key index parameter. Default TX key could be set with separate operation (it is valid to switch between two keys without changing either one). TKIP and CCMP will also need options for setting and getting the sequence number for replay protection (TSC/PN). In other words, WEP, TKIP, CCMP (and likely all future ciphers added to 802.11) would be using the same configuration interface with same set of parameters. Some of these parameters are just ignored for some of the ciphers (e.g., WEP does not really need seq# get/set). > All the WEP options should be independent attributes in nl80211. You > could even have a generic WEPKey attribute that is defined like so: > > ATTR_WEP_KEY { > enum type (one of DISABLE, TYPE_40, TYPE_104, TYPE_152) I would rather use key length than come up with enum that needs to be changed whenever some vendor comes up with the great (yeah, right) security improvement by using a new WEP key length. In addition, this would mean that the same field can be shared (just like key_material) with all ciphers.. > char * key_material unsigned/u8 > enum index (one of DEFAULT, 1, 2, 3, 4) This is not specific to WEP, so could be shared with other algorithms.. None of the ATTR_WEP_KEY fields were actually specific to WEP.. Take a look at struct iw_encode_ext to see the needed parameters.. > Some cards, like older aironet ones, can only do 1 key. I don't want to > pollute nl80211 with limitations like that though, so the driver can > just return -EINVAL if the card doesn't support it. I don't think it > pays to have capability bits for something as far down in the driver > implementation as this. Actually, this particular case could be nice to include in capability flags if someone were interested enough to implement WPA with Group Key only keys, i.e., this case is described in WPA/IEEE 802.11i as an exception and authenticator/supplicant would need to behave differently with it. Then again, I've never really needed this or have even heard a request to implement it, so maybe it can by ignored now. > My impression of ENCODE and ENCODEEXT was that they were _just_ for > setting keying material (except in the case of WEP where you set the > auth mode open/shared too), and that AUTH was for higher level stuff. I think it is a design flaw to use ENCODE for open/shared auth_alg configuration and I never really understood that part of WE. That's why authentication algorithm was added separately in WE-19. IW_AUTH_* is just a subtyped way of being able to configure parameters without having to add a new ioctl for every one. They are not really tied to authentication, so the name is not exactly correct. > > - allowed wpa versions (why is this AUTH??) > > Can you do both WPA and WPA2 at the same time? You can certainly > advertise both a WPA IE and an RSN IE at the same time. Is it possible > to auth both types of clients? Sure you can. APs can have multiple stations and some of them can use WPA while others are using WPA2 (IEEE 802.11i/RSN). > > - setting pairwise and group ciphers (again.. AUTH??) > > Note that ENCODEEXT has a group key flag IW_ENCODE_EXT_GROUP_KEY too. > The pairwise and group cipher stuff in AUTH only sets the cipher _type_, > not the actual key material AFAICT. These parameters in IW_AUTH_ are for setting the allowed cipher suites. They are only used with drivers that generate WPA/RSN IE internally. > * Static WEP > - Keys: up to 4 group keys > - Crypto: WEP-40, WEP-104, WEP-152, WEP-256 > - 802.11 Auth: Open System or Shared Key > - Key Mgmt/Auth: none Static key mapping keys could be used, even though that is not very commonly used part of IEEE 802.11. In other words, there is individual WEP keys and up to four default keys. > * Dynamic WEP (LEAP?) > - Keys: up to 4 group keys > - Crypto: WEP-40, WEP-104, WEP-152, WEP-256 > - 802.11 Auth: Open System (only?) > - Key Mgmt/Auth: IEEE 802.1x with LEAP or EAP LEAP is an EAP method just like TLS, PEAP, etc. (it just happens to not follow the standard, but.. well, close enough). This should have the same keys as "Static WEP", i.e., possibly multiple individual (unicast) keys. In addition, thanks to Cisco, there's "Network EAP" authentication algorithm and possibility of using non-zero key indexes for unicast keys.. > * WPA PSK > - Keys: pairwise & group > - Use WPA IEs > - 802.11 Auth: Open System > - Crypto: TKIP or CCMP > - Key Mgmt/Auth: WPA-PSK (elided 802.1x) > There are pairwise keys and up to four group keys (Notice the pattern? this is same as WEP above..). > * WPA Enterprise > * WPA2 PSK > * WPA2 Enterprise And these have the exact same encryption options as WPA-PSK. In other words, encryption keys should be handled separately from auth_alg/key_mgmt configuration. -- Jouni Malinen PGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html