11n + wpa_supplicant

11n + wpa_supplicant

[Emmanuel Grumbach]

Hi,

the spec of 11n makes the support on AES mandatory, but not TKIP.
Meaning that a NIC can support WPA2 and 11n separately, but not TKIP
in 11n. The RC4 encryption machine has a delay that makes difficult to
encrypt in TKIP (or WEP) in 11n rates. Intel's 11n are such NICs, 11n
+ TKIP/WEP is not supported.

The problem here is that the association (which can be 11n or not)
occurs before the 4-way handshake. Let's say that I have an AP that
publishes only TKIP in its WPA IE and 11n IE, I can understand that
there is no way I should do 11n association. But what happens with an
AP that publishes TKIP + AES in its RSN IE and 11n IE ? I could
associate in 11n, but then wpa_supplicant might be configured to
associate in TKIP (although the AP support AES), and I would be in an
unsupported mode.

One solution would be to make wpa_supplicant understand what 11n is,
but that's not it's job.
Another solution would be to make wpa_supplicant tell me that it
intends to use TKIP before asking me to associate.

Any ideas ?

thanks

-- 
Emmanuel Grumbach
egrumbach@gmail.com

Re: 11n + wpa_supplicant

[Johannes Berg]

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

Hi,

> the spec of 11n makes the support on AES mandatory, but not TKIP.
> Meaning that a NIC can support WPA2 and 11n separately, but not TKIP
> in 11n. The RC4 encryption machine has a delay that makes difficult to
> encrypt in TKIP (or WEP) in 11n rates. Intel's 11n are such NICs, 11n
> + TKIP/WEP is not supported.
> 
> The problem here is that the association (which can be 11n or not)
> occurs before the 4-way handshake. Let's say that I have an AP that
> publishes only TKIP in its WPA IE and 11n IE, I can understand that
> there is no way I should do 11n association. But what happens with an
> AP that publishes TKIP + AES in its RSN IE and 11n IE ? I could
> associate in 11n, but then wpa_supplicant might be configured to
> associate in TKIP (although the AP support AES), and I would be in an
> unsupported mode.
> 
> One solution would be to make wpa_supplicant understand what 11n is,
> but that's not it's job.

I would think that, indeed, it *is* its job since its job is
key/algorithm selection and 11n limits the choices.

How about we simply put the 11n information element into the generic IE
and have mac80211 use that?

johannes

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

Re: 11n + wpa_supplicant

[Emmanuel Grumbach]

>
>  I would think that, indeed, it *is* its job since its job is
>  key/algorithm selection and 11n limits the choices.
>

depends on priorities, maybe the security selection should limit the
11n... IMHO, security should be in higher priority since the user
explicitly said he wants TKIP

>  How about we simply put the 11n information element into the generic IE
>  and have mac80211 use that?
>

in mac80211 we perfectly know what the AP supports (in
ieee80211_send_assoc, I can read the IEs from the AP) , that's no the
issue here, the issue is what security alg the user will chose in the
4way. This decision affects the associate even though it occurs after
the association

>  johannes
>



-- 
Emmanuel Grumbach
egrumbach@gmail.com

Re: 11n + wpa_supplicant

[Johannes Berg]

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

On Tue, 2008-05-13 at 11:41 +0300, Emmanuel Grumbach wrote:
> >
> >  I would think that, indeed, it *is* its job since its job is
> >  key/algorithm selection and 11n limits the choices.
> >
> 
> depends on priorities, maybe the security selection should limit the
> 11n... IMHO, security should be in higher priority since the user
> explicitly said he wants TKIP
> 
> >  How about we simply put the 11n information element into the generic IE
> >  and have mac80211 use that?
> >
> 
> in mac80211 we perfectly know what the AP supports (in
> ieee80211_send_assoc, I can read the IEs from the AP) , that's no the
> issue here, the issue is what security alg the user will chose in the
> 4way. This decision affects the associate even though it occurs after
> the association

Ah, so you mean if the user chose TKIP then we should associate as a
legacy STA?

johannes

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

Re: 11n + wpa_supplicant

[Emmanuel Grumbach]

On Tue, May 13, 2008 at 11:47 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> On Tue, 2008-05-13 at 11:41 +0300, Emmanuel Grumbach wrote:
>  > >
>  > >  I would think that, indeed, it *is* its job since its job is
>  > >  key/algorithm selection and 11n limits the choices.
>  > >
>  >
>  > depends on priorities, maybe the security selection should limit the
>  > 11n... IMHO, security should be in higher priority since the user
>  > explicitly said he wants TKIP
>  >
>  > >  How about we simply put the 11n information element into the generic IE
>  > >  and have mac80211 use that?
>  > >
>  >
>  > in mac80211 we perfectly know what the AP supports (in
>  > ieee80211_send_assoc, I can read the IEs from the AP) , that's no the
>  > issue here, the issue is what security alg the user will chose in the
>  > 4way. This decision affects the associate even though it occurs after
>  > the association
>
>  Ah, so you mean if the user chose TKIP then we should associate as a
>  legacy STA?
>

I think so... If the AP is N-only we would be in trouble...

>  johannes
>



-- 
Emmanuel Grumbach
egrumbach@gmail.com

Re: 11n + wpa_supplicant

[Johannes Berg]

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


> >  Ah, so you mean if the user chose TKIP then we should associate as a
> >  legacy STA?
> >
> 
> I think so... If the AP is N-only we would be in trouble...

Hm. I don't really see much reason to do this. Technically, you could
configure it this way, but in practice most people will just enable all
algorithms they can support (i.e. all).

I don't really care, but I wouldn't want to complicate wext further for
this.

johannes

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

Re: 11n + wpa_supplicant

[John W. Linville]

On Tue, May 13, 2008 at 11:17:28AM +0200, Johannes Berg wrote:
> 
> > >  Ah, so you mean if the user chose TKIP then we should associate as a
> > >  legacy STA?
> > >
> > 
> > I think so... If the AP is N-only we would be in trouble...
> 
> Hm. I don't really see much reason to do this. Technically, you could
> configure it this way, but in practice most people will just enable all
> algorithms they can support (i.e. all).
> 
> I don't really care, but I wouldn't want to complicate wext further for
> this.

Amen to that...

-- 
John W. Linville
linville@tuxdriver.com

Re: 11n + wpa_supplicant

[Jouni Malinen]

On Tue, May 13, 2008 at 11:41:15AM +0300, Emmanuel Grumbach wrote:

> in mac80211 we perfectly know what the AP supports (in
> ieee80211_send_assoc, I can read the IEs from the AP) , that's no the
> issue here, the issue is what security alg the user will chose in the
> 4way. This decision affects the associate even though it occurs after
> the association

Unless you are talking about IBSS (which would not use association),
"the user" (as in the non-AP STA/Supplicant) does not select pairwise
cipher in 4-way handshake; this happens in (re)association request. Only
the AP/Authenticator is able to propose another cipher suite in 4-way
handshake if per-client security policy rejects use of whatever cipher
was selected during association (and I've not heard of anyone having
implemented this).
 
-- 
Jouni Malinen                                            PGP id EFC895FA

Re: 11n + wpa_supplicant

[Jouni Malinen]

On Tue, May 13, 2008 at 11:18:29AM +0300, Emmanuel Grumbach wrote:

> the spec of 11n makes the support on AES mandatory, but not TKIP.
> Meaning that a NIC can support WPA2 and 11n separately, but not TKIP
> in 11n. The RC4 encryption machine has a delay that makes difficult to
> encrypt in TKIP (or WEP) in 11n rates. Intel's 11n are such NICs, 11n
> + TKIP/WEP is not supported.

This is not just a hardware support question; 11n explicitly disallows
use of TKIP between HT STAs and this needs to be enforced somewhere.

> The problem here is that the association (which can be 11n or not)
> occurs before the 4-way handshake. Let's say that I have an AP that
> publishes only TKIP in its WPA IE and 11n IE, I can understand that
> there is no way I should do 11n association. But what happens with an
> AP that publishes TKIP + AES in its RSN IE and 11n IE ? I could
> associate in 11n, but then wpa_supplicant might be configured to
> associate in TKIP (although the AP support AES), and I would be in an
> unsupported mode.

In most cases, the pairwise cipher is selected during association, not
during 4-way handshake. Consequently, the driver/firmware should refuse
to send an (Re)Association Request that requests TKIP as the pairwise
cipher when using .11n.

In the corner case (which I don't think I have even implemented yet in
wpa_supplicant..) the AP/Authenticator could request the STA to use
another pairwise cipher if security policy for that specific STA does
not allow the pairwise cipher suite that the STA tried to select in
(re)association request. In this particular case (should it ever be
implemented), it could be useful for wpa_supplicant to know that .11n is
used. However, no sane security policy would require TKIP as the
pairwise cipher in such a case, so I don't think this is really going to
ever happen in real networks and any kind of failure to use the network
is suitable end result for such an attempt..

> One solution would be to make wpa_supplicant understand what 11n is,
> but that's not it's job.
> Another solution would be to make wpa_supplicant tell me that it
> intends to use TKIP before asking me to associate.

The exact mechanism depends on whether ap_scan=1 or ap_scan=2 is being
used, i.e., whether wpa_supplicant is responsible for selecting a BSS
from scan results or not.

In ap_scan=1, I would say that it would be useful for wpa_supplicant to
know whether the BSS (and the local wlan driver/hardware for that
matter!) supports .11n. If the scan results indicate this in some
reliable way (e.g., all IEs are delivered to wpa_supplicant), the AP's
support for 11n can be figured out. The local side support would need to
be added, e.g., to driver capabilities reporting.

In ap_scaqn=2, wpa_supplicant requests the driver to select a BSS based
on configuration (SSID, security policy, including a specific cipher
suite), i.e., the driver would be told about TKIP use before
association and the driver would be responsible for not trying to use
11n in that case. The corner case of AP/Authenticator requesting another
pairwise cipher would still be possible here, but not really something
that I would consider a real problem that needs to be solved.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: 11n + wpa_supplicant

[Johannes Berg]

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


> In most cases, the pairwise cipher is selected during association, not
> during 4-way handshake. Consequently, the driver/firmware should refuse
> to send an (Re)Association Request that requests TKIP as the pairwise
> cipher when using .11n.

So to do this we should look at the associate IE(s) we get from
userspace for association, right?

> The exact mechanism depends on whether ap_scan=1 or ap_scan=2 is being
> used, i.e., whether wpa_supplicant is responsible for selecting a BSS
> from scan results or not.
> 
> In ap_scan=1, I would say that it would be useful for wpa_supplicant to
> know whether the BSS (and the local wlan driver/hardware for that
> matter!) supports .11n. If the scan results indicate this in some
> reliable way (e.g., all IEs are delivered to wpa_supplicant), the AP's
> support for 11n can be figured out. The local side support would need to
> be added, e.g., to driver capabilities reporting.
> 
> In ap_scaqn=2, wpa_supplicant requests the driver to select a BSS based
> on configuration (SSID, security policy, including a specific cipher
> suite), i.e., the driver would be told about TKIP use before
> association and the driver would be responsible for not trying to use
> 11n in that case. The corner case of AP/Authenticator requesting another
> pairwise cipher would still be possible here, but not really something
> that I would consider a real problem that needs to be solved.

I'd think we can also just include the HT IE in the scan result. Or, why
not just include all of them, parsers must be able to tell them apart
anyway and NM could display an HT icon for example then.

johannes

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

Re: 11n + wpa_supplicant

[Jouni Malinen]

On Tue, May 13, 2008 at 02:34:40PM +0200, Johannes Berg wrote:

> > In most cases, the pairwise cipher is selected during association, not
> > during 4-way handshake. Consequently, the driver/firmware should refuse
> > to send an (Re)Association Request that requests TKIP as the pairwise
> > cipher when using .11n.
> 
> So to do this we should look at the associate IE(s) we get from
> userspace for association, right?

Well, at least in theory, yes, we could refuse to send the frame if
WPA/RSN IE requests TKIP as the pairwise cipher and we would be using
.11n (or alternatively, just drop to legacy mode). However, I think it
would be better to leave this task to whatever component picks the BSS,
i.e., in this particular case to userspace if the request is indeed to
associate with a specific WPA/RSN IE and a selected BSSID.

If ap_scan=2 were to be used (I don't think this is supported in
mac80211 or at least it wasn't originally), the task would be in kernel
code, but in that case, the pairwise cipher would be configured as a
separate parameter and there would be no need to parse IEs to figure it
out.

> I'd think we can also just include the HT IE in the scan result. Or, why
> not just include all of them, parsers must be able to tell them apart
> anyway and NM could display an HT icon for example then.

I would recommend to include all the IEs. This should have been the
design from the beginning, but well, it wasn't at least enforced very
strongly. I've changed wpa_supplicant to use full set of IEs internally
and WPA/RSN IE(s) are already converted to this format if only those IEs
are available and drivers should just report all the IEs from
Beacon/ProbeResp frames with IWEVGENIE when using WEXT.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: 11n + wpa_supplicant

[Emmanuel Grumbach]

On Tue, May 13, 2008 at 3:50 PM, Jouni Malinen <j@w1.fi> wrote:
> On Tue, May 13, 2008 at 02:34:40PM +0200, Johannes Berg wrote:
>
>  > > In most cases, the pairwise cipher is selected during association, not
>  > > during 4-way handshake. Consequently, the driver/firmware should refuse
>  > > to send an (Re)Association Request that requests TKIP as the pairwise
>  > > cipher when using .11n.
>  >
>  > So to do this we should look at the associate IE(s) we get from
>  > userspace for association, right?
>
>  Well, at least in theory, yes, we could refuse to send the frame if
>  WPA/RSN IE requests TKIP as the pairwise cipher and we would be using
>  .11n (or alternatively, just drop to legacy mode). However, I think it
>  would be better to leave this task to whatever component picks the BSS,
>  i.e., in this particular case to userspace if the request is indeed to
>  associate with a specific WPA/RSN IE and a selected BSSID.
>
>  If ap_scan=2 were to be used (I don't think this is supported in
>  mac80211 or at least it wasn't originally), the task would be in kernel
>  code, but in that case, the pairwise cipher would be configured as a
>  separate parameter and there would be no need to parse IEs to figure it
>  out.
>
>
>  > I'd think we can also just include the HT IE in the scan result. Or, why
>  > not just include all of them, parsers must be able to tell them apart
>  > anyway and NM could display an HT icon for example then.
>
>  I would recommend to include all the IEs. This should have been the
>  design from the beginning, but well, it wasn't at least enforced very
>  strongly. I've changed wpa_supplicant to use full set of IEs internally
>  and WPA/RSN IE(s) are already converted to this format if only those IEs
>  are available and drivers should just report all the IEs from
>  Beacon/ProbeResp frames with IWEVGENIE when using WEXT.
>
>
>
>  --
>  Jouni Malinen                                            PGP id EFC895FA
>

So, If I understand you well, we should pass the HT IE using IWEVGENIE
during scan, and wpa_supplicant will detect the conflict between
encryption method and HT, and will request association in legacy mode
(or won't allow the encryption method according to what has
precedence: security or 11n).

Am I correct ?

-- 
Emmanuel Grumbach
egrumbach@gmail.com

Re: 11n + wpa_supplicant

[Jouni Malinen]

On Tue, May 13, 2008 at 04:03:19PM +0300, Emmanuel Grumbach wrote:

> So, If I understand you well, we should pass the HT IE using IWEVGENIE
> during scan, and wpa_supplicant will detect the conflict between
> encryption method and HT, and will request association in legacy mode
> (or won't allow the encryption method according to what has
> precedence: security or 11n).
> 
> Am I correct ?

Yes, I would expect the driver/mac80211 to do exactly that. You can
actually pass full set of IEs received from Beacon/ProbeResp in one
IWEVGENIE event and wpa_supplicant will parse the IEs from that data and
there is no need for separate reporting of WPA/RSN IEs.

The current version of wpa_supplicant would ignore the HT IE, but it
sounds reasonable to add code there to take care of this new requirement
in .11n on limiting the available pairwise ciphers.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: 11n + wpa_supplicant

[Emmanuel Grumbach]

On Tue, May 13, 2008 at 4:10 PM, Jouni Malinen <j@w1.fi> wrote:
> On Tue, May 13, 2008 at 04:03:19PM +0300, Emmanuel Grumbach wrote:
>
>  > So, If I understand you well, we should pass the HT IE using IWEVGENIE
>  > during scan, and wpa_supplicant will detect the conflict between
>  > encryption method and HT, and will request association in legacy mode
>  > (or won't allow the encryption method according to what has
>  > precedence: security or 11n).
>  >
>  > Am I correct ?
>
>  Yes, I would expect the driver/mac80211 to do exactly that. You can
>  actually pass full set of IEs received from Beacon/ProbeResp in one
>  IWEVGENIE event and wpa_supplicant will parse the IEs from that data and
>  there is no need for separate reporting of WPA/RSN IEs.
>
>  The current version of wpa_supplicant would ignore the HT IE, but it
>  sounds reasonable to add code there to take care of this new requirement
>  in .11n on limiting the available pairwise ciphers.
>
>  --

Great thanks !

-- 
Emmanuel Grumbach
egrumbach@gmail.com