about 802.11i IBSS support

about 802.11i IBSS support

[Hong Liu]

Hi,
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.

For 802.11i IBSS to work, each STA assumes two roles: supplicant + authenticator.
Usually in BSS network, authenticator is in AP.
The problem is the distribution of group keys.
The group key is used for one-to-many communication.
In BSS, the one is the AP, so the AP is responsible for the distribution of the group key.
In IBSS, every STA has its own group key, used to broadcast data to other STAs.

When a STA (say S1) joins in an IBSS network with N STAs,
it must negotiate keys with all N STAs.
The process for negotiation with one STA is as follows:
1. S1 init a 4-way handshake with one STA (say S2),
   to derive the pairwise key between them and then S1 sends its group key to S2,
   let S2 can decrypt s1's broadcast data.
2. S2 init the second 4-way handshake with S1, the main purpose for this 4-way handshake
   is for S2 to send its group key to S1, although this will also derive a second pairwise key.
3. Because in an IBSS there are two 4-Way Handshakes between 
   any two STA Supplicants and Authenticators, the pairwise key used between any two STAs
   is from the 4-Way Handshake initiated by the STA Authenticator with the higher MAC address.
So any STA in an IBSS network with N STAs must keep 2N-1 keys (N-1 for pairwise key and N for group key).

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.

   It should not be difficult because the infrastructures are all there in the dscape stack.

2. wpa_supplicant: this is the big part, we need to implement the authenticator
   in it. Not sure how much efforts needed?

Thanks,
Hong

Re: about 802.11i IBSS support

[Michael Buesch]

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.

Re: about 802.11i IBSS support

[Jouni Malinen]

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 Malinen                                            PGP id EFC895FA

RE: about 802.11i IBSS support

[Simon Barber]

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: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
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 Malinen                                            PGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

Re: about 802.11i IBSS support

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: about 802.11i IBSS support

[Hong Liu]

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

RE: about 802.11i IBSS support

[Simon Barber]

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: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
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 majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html