linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Andreas Hartmann <andihartmann@01019freenet.de>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>,
	hostap@lists.shmoo.com,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"users@rt2x00.serialmonkey.com" <users@rt2x00.serialmonkey.com>
Subject: Re: [rt2x00-users] [rt2800pci (AP) - ath9k] 802.11w: broken aggregation handling?
Date: Tue, 8 May 2012 10:34:46 +0300	[thread overview]
Message-ID: <20120508073446.GA2887@w1.fi> (raw)
In-Reply-To: <4FA8BD11.3080703@01019freenet.de>

On Tue, May 08, 2012 at 08:28:33AM +0200, Andreas Hartmann wrote:
> > The main requirements:
> > - support CCMP encryption/decryption of unicast robust management frames
> >   (subset of Action frames, Deauthentication, Disassociation)
> 
> I tested WPA-EAP-SHA256 with group key ccmp.

The key point here is to test whether at least one of those management
frames gets encrypted and decrypted correctly. Deauthentication frames
may be easiest for that purpose and you can request the station to
disconnect to test AP's capability of receiving the frame and then use
hostapd_cli deauthenticate <addr> command on the AP to request the
station to be disconnected.

> The IGTK is a single key (shared key). There are a maximum of 4 shared
> keys designated in rt2x00mac.c for each BSS for use with hw encryption.

BIP uses key indexes 4 and 5 (i.e., the 5th and 6th index).. Anyway,
this would most likely be handled in software so the main point here is
to prevent hardware from doing anything additional to the frames.

> Since rt2800usb is working fine with nohwcrypt=1 (but not with
> encryption done in hw), I assume, that there is no differentiation
> between the encryption / decryption of different frame types. If hw
> encryption is turned on, all types of frames are encrypted / decrypted
> by hardware and vice versa.

BIP is kind of special since it doesn't actually even set the Protected
field in the frame header which may make this easier.. The frames are
not actually encrypted, i.e., BIP protects only authenticity of the
frames.

> I'm not sure how BIP is secured if hw encryption is enabled. BIP is
> implemented in mac80211 as part of decryption. Is BIP done during hw
> encryption, too? Or is it done by mac80211 w/ enabled hw encryption, too?

With most drivers, yes, I would expect mac80211 to handle both TX and RX
side. The driver should just return -EOPNOTSUPP in the set_key() handler
for WLAN_CIPHER_SUITE_AES_CMAC to leave BIP for mac80211 and CCMP for
hwardware.

> This means for rt2x00: to get 11w working with hw encryption enabled,
> there needs to be some differentiation for the encryption of management
> frames: if management frame, let mac80211 do the job - all other frames
> should be encrypted by hw.
> Correct?

Well, if you are saying that the issues shows up with unicast robust
management frames, too, and not just BIP (group addressed robust
management frames), then you are in problems.. With good luck, you could
be able to make the hardware not mess up with unicast robust management
frames and handle them in mac80211. This may be easier for TX, but RX
can be a bit complex. It may go to the point of having to use the
driver to workaround the mess that hardware did (i.e., re-encrypted the
frame in incorrect way to get back to the correctly encrypted form and
then sent that to mac80211).. All this depends on the exact behavior of
the hardware with a frame that was designed after the hardware was, so
good luck figuring that out ;-).

-- 
Jouni Malinen                                            PGP id EFC895FA

  parent reply	other threads:[~2012-05-08  7:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07  5:11 [rt2800pci (AP) - ath9k] 802.11w: broken aggregation handling? Andreas Hartmann
2012-05-07  7:02 ` [rt2x00-users] " Andreas Hartmann
2012-05-07 10:17   ` Andreas Hartmann
2012-05-07 11:04     ` Helmut Schaa
2012-05-07 13:55       ` Jouni Malinen
2012-05-08  6:28         ` Andreas Hartmann
2012-05-08  6:34           ` Johannes Berg
2012-05-08  7:22             ` Andreas Hartmann
2012-05-08  7:37               ` Johannes Berg
2012-05-08  7:34           ` Jouni Malinen [this message]
2012-05-08 18:16             ` Andreas Hartmann
2012-05-07 13:59   ` Jouni Malinen
2012-05-07 14:16     ` Andreas Hartmann
2012-05-07 15:18       ` Jouni Malinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120508073446.GA2887@w1.fi \
    --to=j@w1.fi \
    --cc=andihartmann@01019freenet.de \
    --cc=helmut.schaa@googlemail.com \
    --cc=hostap@lists.shmoo.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=users@rt2x00.serialmonkey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).