Re: about 802.11i IBSS support
On Wednesday 25 October 2006 10:54, Hong Liu wrote: 2. wpa_supplicant: this is the big part, we need to implement the authenticator in it. Not sure how much efforts needed? Well, I think that should go together with a merge of wpa_supplicant with hostapd (which I think is desired anyway). -- Greetings Michael. - 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
Re: about 802.11i IBSS support
On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. We need the following parts to make 802.11i IBSS work: 1. for the d80211 part: I don't think there will be much efforts. We may add a group key to each sta_info for decrypting multicast data from that STA. And in RX path, we need to add code to select the correct group key for decryption. And also we need to store our own group key used to send multicast data to others. This will also include looking into how different WLAN chipsets have implemented (or will implement) hardware acceleration for such a case. In addition, there will likely be need for some new kernel-to-userspace events to notify supplicant/authenticator that communication with a new target is needed. I don't think the standard has strict requirements on how this is done and there may be different preferences based on the application, so adding a generic mechanism for this would be nice. 2. wpa_supplicant: this is the big part, we need to implement the authenticator in it. Not sure how much efforts needed? This is on my to-do list for wpa_supplicant/hostapd 0.6 branch where it will be possible to link in part of wpa_supplicant and hostapd together into a single program. In other words, the authenticator code (both IEEE 802.1X/EAPOL and WPA/WPA2) will be available from hostapd. -- Jouni MalinenPGP 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
RE: about 802.11i IBSS support
One area that needs work is the 802.11 qdisc - there is no provision in the current implementation for queueing certain frames because the 802.11 link is not ready to traqnsmit them yet, while letting other frames through. E.G. for normal client mode links it would be nice for the qdisc to allow management frames and EAPOL frames to an AP through while mid roam to another AP - but to queue other data frames until EAPOL has sucessfully completed. In the IBSS case a similar mechanism could queue data frames sent to a particular destination, until a key has been negociated with that destination. Indeed if the mechanism is generic the client mode case should be a subset of the IBSS case. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jouni Malinen Sent: Wednesday, October 25, 2006 8:48 AM To: Hong Liu Cc: Jiri Benc; netdev Subject: Re: about 802.11i IBSS support On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. We need the following parts to make 802.11i IBSS work: 1. for the d80211 part: I don't think there will be much efforts. We may add a group key to each sta_info for decrypting multicast data from that STA. And in RX path, we need to add code to select the correct group key for decryption. And also we need to store our own group key used to send multicast data to others. This will also include looking into how different WLAN chipsets have implemented (or will implement) hardware acceleration for such a case. In addition, there will likely be need for some new kernel-to-userspace events to notify supplicant/authenticator that communication with a new target is needed. I don't think the standard has strict requirements on how this is done and there may be different preferences based on the application, so adding a generic mechanism for this would be nice. 2. wpa_supplicant: this is the big part, we need to implement the authenticator in it. Not sure how much efforts needed? This is on my to-do list for wpa_supplicant/hostapd 0.6 branch where it will be possible to link in part of wpa_supplicant and hostapd together into a single program. In other words, the authenticator code (both IEEE 802.1X/EAPOL and WPA/WPA2) will be available from hostapd. -- Jouni MalinenPGP 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 - 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
Re: about 802.11i IBSS support
On Wed, 2006-10-25 at 08:48 -0700, Jouni Malinen wrote: 1. for the d80211 part: I don't think there will be much efforts. We may add a group key to each sta_info for decrypting multicast data from that STA. And in RX path, we need to add code to select the correct group key for decryption. And also we need to store our own group key used to send multicast data to others. This will also include looking into how different WLAN chipsets have implemented (or will implement) hardware acceleration for such a case. For bcm43xx, you can use any key for TX. At RX, the mac address of the sender is used to look up which key to use (broadly spoken). But if the frame is multicast, bcm43xx can only use the 4 default keys if enabled. That said, we're recently started to reverse engineer the firmware and I can see that it should be trivial to also do a mac address matching for multicast frames and use different keys then. johannes signature.asc Description: This is a digitally signed message part
Re: about 802.11i IBSS support
On Wed, 2006-10-25 at 23:48, Jouni Malinen wrote: On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. This may add complexity to the implementation. If the STA wants to send broadcast data, it must distribute its group key to all other STAs, and then it can send out the packet. For RX, if it receives data from other STA it needs to find out whether it has finished key negotiation with that STA. And it can not decrypt the data until key negotiation is finished. If we negotiate keys at the beginning, things will be simple. But the cost is we may negotiating keys with STAs we may not communicate with. Thanks, Hong - 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
RE: about 802.11i IBSS support
It's not possible to 'negotiate keys at the beginning' - since there is no indication of a new station joining an IBSS. The first you ever know about a station joining an IBSS is when you receive a frame from that station. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hong Liu Sent: Wednesday, October 25, 2006 7:47 PM To: Jouni Malinen Cc: Jiri Benc; netdev Subject: Re: about 802.11i IBSS support On Wed, 2006-10-25 at 23:48, Jouni Malinen wrote: On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote: I am reading the 802.11i IBSS spec and trying to find if it is OK to add patches to d80211 to support this feature. Large parts of this will be outside d80211, but yes, I think d80211 should be made ready to support this (mainly in the multiple group keys area). When a STA (say S1) joins in an IBSS network with N STAs, it must negotiate keys with all N STAs. I don't think it is required to negotiate keys with all STAs of the network unless it actually needs to communicate with them, i.e., there may be cases where it is not needed to send or receive data from some of the nodes. This may add complexity to the implementation. If the STA wants to send broadcast data, it must distribute its group key to all other STAs, and then it can send out the packet. For RX, if it receives data from other STA it needs to find out whether it has finished key negotiation with that STA. And it can not decrypt the data until key negotiation is finished. If we negotiate keys at the beginning, things will be simple. But the cost is we may negotiating keys with STAs we may not communicate with. Thanks, Hong - 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 - 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
