WPA and WPA2

WPA and WPA2

[Tobin C. Harding]

Hi,

I am attempting to rewrite the ks7010 WEXT driver (drivers/staging/ks7010)
to use the CFG80211 API.

I am reading 802.11 Wireless Networks - Matthew S. Gast for reference.

I have some confusion regarding WEP/WPA/WPA2/RSN, ciphers, keys and
ie's?

As I understand, first there was WEP. Next we got a marketing term WPA
which referred to 802.11i (which specified the protocols TKIP and
CCMP, and also RSN).

WEP vs WPA
----------

To add to my confusion the ks7010 code seemingly mixes up the use of
WEP keys and WPA keys, to set both the WEP and the WPA keys the driver
uses the same MIB requests? Yet throughout the code WEP keys and WPA
keys are stored in separate structures (and treated differently).

If WPA is enabled are not WEP keys superfluous?

WPA vs WPA2
-----------

Were WPA version 1 and WPA version 2 marketing terms or do they differ?

ieee80211.h does not seem to mention WPA2 (and cfg80211.h mentions it
once only in some comments) however, from cfg80211.h;

 * struct cfg80211_crypto_settings - Crypto settings
 * @wpa_versions: indicates which, if any, WPA versions are enabled
 *	(from enum nl80211_wpa_versions)

When using the CFG80211 API we do not need to worry about the WPA/WPA2
distinction? Can I drop all the WPA version 1 code from the driver?

A little more information:

The WEXT driver defines ciphers, from looking at ieee80211.h it seems
that it uses WLAN_CIPHER_SUITE_XXX for WPA2 and for WPA it uses

#define CIPHER_ID_WPA_NONE    "\x00\x50\xf2\x00"
#define CIPHER_ID_WPA_WEP40   "\x00\x50\xf2\x01"
#define CIPHER_ID_WPA_TKIP    "\x00\x50\xf2\x02"
#define CIPHER_ID_WPA_CCMP    "\x00\x50\xf2\x04"
#define CIPHER_ID_WPA_WEP104  "\x00\x50\xf2\x05"

FYI ieee80211.h has

#define WLAN_OUI_MICROSOFT	       0x0050f2

Thanks for taking the time to read this mail, any suggestions most
appreciated.

thanks,
Tobin.

Re: WPA and WPA2

[Tobin C. Harding]

On Wed, May 24, 2017 at 05:27:50PM +1000, Tobin C. Harding wrote:
> Hi,
> 
> I am attempting to rewrite the ks7010 WEXT driver (drivers/staging/ks7010)
> to use the CFG80211 API.
> 
> I am reading 802.11 Wireless Networks - Matthew S. Gast for reference.
> 
> I have some confusion regarding WEP/WPA/WPA2/RSN, ciphers, keys and
> ie's?
> 
> As I understand, first there was WEP. Next we got a marketing term WPA
> which referred to 802.11i (which specified the protocols TKIP and
> CCMP, and also RSN).
> 
> WEP vs WPA
> ----------
> 
> To add to my confusion the ks7010 code seemingly mixes up the use of
> WEP keys and WPA keys, to set both the WEP and the WPA keys the driver
> uses the same MIB requests? Yet throughout the code WEP keys and WPA
> keys are stored in separate structures (and treated differently).

Oh, I just got why there is only one MIB request type - there are only
one set of keys used by the target

	DOT11_WEP_DEFAULT_KEY_VALUE1	= 0x13020101,
	DOT11_WEP_DEFAULT_KEY_VALUE2	= 0x13020102,
	DOT11_WEP_DEFAULT_KEY_VALUE3	= 0x13020103,
	DOT11_WEP_DEFAULT_KEY_VALUE4	= 0x13020104,

removing 'WEP' from the defines removes the confusion here :)

> If WPA is enabled are not WEP keys superfluous?
> 
> WPA vs WPA2
> -----------
> 
> Were WPA version 1 and WPA version 2 marketing terms or do they differ?
> 
> ieee80211.h does not seem to mention WPA2 (and cfg80211.h mentions it
> once only in some comments) however, from cfg80211.h;
> 
>  * struct cfg80211_crypto_settings - Crypto settings
>  * @wpa_versions: indicates which, if any, WPA versions are enabled
>  *	(from enum nl80211_wpa_versions)
> 
> When using the CFG80211 API we do not need to worry about the WPA/WPA2
> distinction? Can I drop all the WPA version 1 code from the driver?
> 
> A little more information:
> 
> The WEXT driver defines ciphers, from looking at ieee80211.h it seems
> that it uses WLAN_CIPHER_SUITE_XXX for WPA2 and for WPA it uses
> 
> #define CIPHER_ID_WPA_NONE    "\x00\x50\xf2\x00"
> #define CIPHER_ID_WPA_WEP40   "\x00\x50\xf2\x01"
> #define CIPHER_ID_WPA_TKIP    "\x00\x50\xf2\x02"
> #define CIPHER_ID_WPA_CCMP    "\x00\x50\xf2\x04"
> #define CIPHER_ID_WPA_WEP104  "\x00\x50\xf2\x05"
> 
> FYI ieee80211.h has
> 
> #define WLAN_OUI_MICROSOFT	       0x0050f2
> 
> Thanks for taking the time to read this mail, any suggestions most
> appreciated.
> 
> thanks,
> Tobin.

Re: WPA and WPA2

[Johannes Berg]

On Wed, 2017-05-24 at 17:27 +1000, Tobin C. Harding wrote:

> I am attempting to rewrite the ks7010 WEXT driver
> (drivers/staging/ks7010) to use the CFG80211 API.

Heh, I wasn't even aware of this driver yet.

> As I understand, first there was WEP. 

Correct.

> Next we got a marketing term WPA which referred to 802.11i (which
> specified the protocols TKIP and CCMP, and also RSN).

No, technically WPA referred to a *draft* version of 802.11i, and used
(only?) TKIP - where WPA2 is equivalent to RSN, the published version
of 802.11i (now long rolled into the spec, of course), but WPA2 also
preferred CCMP and only used TKIP for compatibility, IIRC.

> WEP vs WPA
> ----------
> 
> To add to my confusion the ks7010 code seemingly mixes up the use of
> WEP keys and WPA keys, to set both the WEP and the WPA keys the
> driver uses the same MIB requests? Yet throughout the code WEP keys
> and WPA keys are stored in separate structures (and treated
> differently).
> 
> If WPA is enabled are not WEP keys superfluous?

Well, you can't really have both at the same time, but you can (and
probably should) support both.

> WPA vs WPA2
> -----------
> 
> Were WPA version 1 and WPA version 2 marketing terms or do they
> differ?

See above. But at the level you're looking at, it's probably not really
all that relevant. To some extent, WPA1 is TKIP and WPA2 is CCMP, but
you don't really care since you just get keys with a cipher suite
identifier attached to them.

> ieee80211.h does not seem to mention WPA2 (and cfg80211.h mentions it
> once only in some comments) however, from cfg80211.h;
> 
>  * struct cfg80211_crypto_settings - Crypto settings
>  * @wpa_versions: indicates which, if any, WPA versions are enabled
>  *	(from enum nl80211_wpa_versions)
> 
> When using the CFG80211 API we do not need to worry about the
> WPA/WPA2 distinction? 

This is only relevant for full-MAC devices, I think it's mostly used
for selecting the BSS?

> Can I drop all the WPA version 1 code from the driver?
> 
> A little more information:
> 
> The WEXT driver defines ciphers, from looking at ieee80211.h it seems
> that it uses WLAN_CIPHER_SUITE_XXX for WPA2 and for WPA it uses
> 
> #define CIPHER_ID_WPA_NONE    "\x00\x50\xf2\x00"
> #define CIPHER_ID_WPA_WEP40   "\x00\x50\xf2\x01"
> #define CIPHER_ID_WPA_TKIP    "\x00\x50\xf2\x02"
> #define CIPHER_ID_WPA_CCMP    "\x00\x50\xf2\x04"
> #define CIPHER_ID_WPA_WEP104  "\x00\x50\xf2\x05"

That's ... strange. The standard identifiers are

WLAN_CIPHER_SUITE_*, which are 00-0F-AC:n (with the same values for n
as above).

If the firmware wants them with MS OUI, then you'd probably have to
translate them.



All this wext code there looks really strange though.

Does this driver actually work with standard wpa_supplicant?

johannes

Re: WPA and WPA2

[Tobin C. Harding]

On Wed, May 24, 2017 at 09:40:51AM +0200, Johannes Berg wrote:
> On Wed, 2017-05-24 at 17:27 +1000, Tobin C. Harding wrote:
> 
> > I am attempting to rewrite the ks7010 WEXT driver
> > (drivers/staging/ks7010) to use the CFG80211 API.
> 
> Heh, I wasn't even aware of this driver yet.

Thanks for replying. It came into staging a couple of months
ago.

> > As I understand, first there was WEP. 
> 
> Correct.
> 
> > Next we got a marketing term WPA which referred to 802.11i (which
> > specified the protocols TKIP and CCMP, and also RSN).
> 
> No, technically WPA referred to a *draft* version of 802.11i, and
> used (only?) TKIP - where WPA2 is equivalent to RSN, the published
> version of 802.11i (now long rolled into the spec, of course), but
> WPA2 also preferred CCMP and only used TKIP for compatibility, IIRC.

Oh nice, thanks for the clarification.

> > WEP vs WPA
> > ----------
> > 
> > To add to my confusion the ks7010 code seemingly mixes up the use of
> > WEP keys and WPA keys, to set both the WEP and the WPA keys the
> > driver uses the same MIB requests? Yet throughout the code WEP keys
> > and WPA keys are stored in separate structures (and treated
> > differently).
> > 
> > If WPA is enabled are not WEP keys superfluous?
> 
> Well, you can't really have both at the same time, but you can (and
> probably should) support both.
> 
> > WPA vs WPA2
> > -----------
> > 
> > Were WPA version 1 and WPA version 2 marketing terms or do they
> > differ?
> 
> See above. But at the level you're looking at, it's probably not really
> all that relevant. To some extent, WPA1 is TKIP and WPA2 is CCMP, but
> you don't really care since you just get keys with a cipher suite
> identifier attached to them.

For this driver I think it matters. It is not a soft MAC driver, but
it is not a Full MAC either. The firmware was released in 2009, I
don't imagine it is getting any updates. The WEXT driver adds/checks
the TKIP Michael MIC in software.

Perhaps for the initial cfg80211 implementation we could simply
support RSN only (i.e either WPA2 or no security)?

> > ieee80211.h does not seem to mention WPA2 (and cfg80211.h mentions it
> > once only in some comments) however, from cfg80211.h;
> > 
> >  * struct cfg80211_crypto_settings - Crypto settings
> >  * @wpa_versions: indicates which, if any, WPA versions are enabled
> >  *	(from enum nl80211_wpa_versions)
> > 
> > When using the CFG80211 API we do not need to worry about the
> > WPA/WPA2 distinction? 
> 
> This is only relevant for full-MAC devices, I think it's mostly used
> for selecting the BSS?
> 
> > Can I drop all the WPA version 1 code from the driver?
> > 
> > A little more information:
> > 
> > The WEXT driver defines ciphers, from looking at ieee80211.h it seems
> > that it uses WLAN_CIPHER_SUITE_XXX for WPA2 and for WPA it uses
> > 
> > #define CIPHER_ID_WPA_NONE    "\x00\x50\xf2\x00"
> > #define CIPHER_ID_WPA_WEP40   "\x00\x50\xf2\x01"
> > #define CIPHER_ID_WPA_TKIP    "\x00\x50\xf2\x02"
> > #define CIPHER_ID_WPA_CCMP    "\x00\x50\xf2\x04"
> > #define CIPHER_ID_WPA_WEP104  "\x00\x50\xf2\x05"
> 
> That's ... strange. The standard identifiers are
> 
> WLAN_CIPHER_SUITE_*, which are 00-0F-AC:n (with the same values for n
> as above).
> 
> If the firmware wants them with MS OUI, then you'd probably have to
> translate them.
> 
> 
> 
> All this wext code there looks really strange though.
> 
> Does this driver actually work with standard wpa_supplicant?

I'm not sure, I got hardware in the mail a couple of days ago but have
not tested it yet. The current driver may be broken thanks to my
refactoring efforts of late. I believe it was tested and functional
when it was first brought into staging. I do not know to what depth it
was tested.

> johannes

Thanks Johannes,
Tobin.

Re: WPA and WPA2

[Johannes Berg]

On Wed, 2017-05-24 at 20:13 +1000, Tobin C. Harding wrote:

> For this driver I think it matters. It is not a soft MAC driver, but
> it is not a Full MAC either. The firmware was released in 2009, I
> don't imagine it is getting any updates. The WEXT driver adds/checks
> the TKIP Michael MIC in software.

Right. It might matter, but it depends - does the device actually
select the BSS (AP) to connect to?

It only really matters if it selects the BSS, or tries to roam, or
builds the association request IEs itself. If it doesn't do any of
those, and just takes the IEs from wpa_supplicant, it will not matter -
then it would only matter what key cipher you configure.

> Perhaps for the initial cfg80211 implementation we could simply
> support RSN only (i.e either WPA2 or no security)?

I'm not sure how much that buys you, but sure, doing things step by
step isn't a bad idea in general :)

> > Does this driver actually work with standard wpa_supplicant?
> 
> I'm not sure, I got hardware in the mail a couple of days ago but
> have not tested it yet. The current driver may be broken thanks to my
> refactoring efforts of late. I believe it was tested and functional
> when it was first brought into staging. I do not know to what depth
> it was tested.

I think you should try this first, and try to get some kind of logging
out to see what's going on with the firmware. Perhaps even put
tracepoints like iwlwifi has (iwlwifi_dev_hcmd) to see what
communication goes on with the device...

If it does work with the standard supplicant with wext, then I believe
it has to be using the IEs from there, and then the whole WPA/WPA2
thing shouldn't matter.

johannes

Re: WPA and WPA2

[Dan Williams]

On Wed, 2017-05-24 at 17:34 +1000, Tobin C. Harding wrote:
> On Wed, May 24, 2017 at 05:27:50PM +1000, Tobin C. Harding wrote:
> > Hi,
> > 
> > I am attempting to rewrite the ks7010 WEXT driver
> > (drivers/staging/ks7010)
> > to use the CFG80211 API.
> > 
> > I am reading 802.11 Wireless Networks - Matthew S. Gast for
> > reference.
> > 
> > I have some confusion regarding WEP/WPA/WPA2/RSN, ciphers, keys and
> > ie's?
> > 
> > As I understand, first there was WEP. Next we got a marketing term
> > WPA
> > which referred to 802.11i (which specified the protocols TKIP and
> > CCMP, and also RSN).
> > 
> > WEP vs WPA
> > ----------
> > 
> > To add to my confusion the ks7010 code seemingly mixes up the use
> > of
> > WEP keys and WPA keys, to set both the WEP and the WPA keys the
> > driver
> > uses the same MIB requests? Yet throughout the code WEP keys and
> > WPA
> > keys are stored in separate structures (and treated differently).
> 
> Oh, I just got why there is only one MIB request type - there are
> only
> one set of keys used by the target
> 
> 	DOT11_WEP_DEFAULT_KEY_VALUE1	= 0x13020101,
> 	DOT11_WEP_DEFAULT_KEY_VALUE2	= 0x13020102,
> 	DOT11_WEP_DEFAULT_KEY_VALUE3	= 0x13020103,
> 	DOT11_WEP_DEFAULT_KEY_VALUE4	= 0x13020104,
> 
> removing 'WEP' from the defines removes the confusion here :)

I could be entirely wrong, but it looks like the driver really just
defines 4 "keys" which can be used for anything.

For WEP, they are the 4 WEP key indexes.

For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused.

Because WEXT is pretty convoluted, I woudn't necessarily try to
translate what eg ks_wlan_set_encode_ext() is doing directly to
cfg80211, but to understand how the firmware interface works and then
just write the cfg80211 code to the firmware interface.

Basically, you have the following modes:

a) open, no encryption
b) WEP encryption (4 possible WEP keys, each either 40 or 104 bits)
c) WPA/RSN (PMK and GMK are computed by wpa_supplicant and supplied to
you, just need to send to firmware)

most of the stuff about IW_ENCODE_ALG_* is useless for cfg80211, you
just take the values that you get from userspace (eg, wpa_supplicant)
for the key and the type of key and just tell the firmware to use
those.

The driver also has odd stuff like SME_WEP_FLAG_REQUEST that really
just maps to DOT11_PRIVACY_INVOKED, so that's going to be a bit
confusing for you too since that's used not just for WEP but also for
WPA/RSN.

So anyway, it's going to be an interesting ride for you, but I think
you'll be pleasantly surprised at how much awful code you can actually
remove.

And to answer Johannes, this firmware looks much more fullmac than
softmac; BSS selection seems left up to the firmware.  You just send it
a "connect with these parameters" command (HIF_INFRA_SET_REQ) including
channels, SSID, BSSID, mode, etc and it does everything.

So Tobin, I think that means this driver should probably implement the
"connect" call like fullmac drivers do.  One existing example of that
is the 'brcmfmac' driver, eg brcmf_cfg80211_connect().

Dan

> > If WPA is enabled are not WEP keys superfluous?
> > 
> > WPA vs WPA2
> > -----------
> > 
> > Were WPA version 1 and WPA version 2 marketing terms or do they
> > differ?
> > 
> > ieee80211.h does not seem to mention WPA2 (and cfg80211.h mentions
> > it
> > once only in some comments) however, from cfg80211.h;
> > 
> >  * struct cfg80211_crypto_settings - Crypto settings
> >  * @wpa_versions: indicates which, if any, WPA versions are enabled
> >  *	(from enum nl80211_wpa_versions)
> > 
> > When using the CFG80211 API we do not need to worry about the
> > WPA/WPA2
> > distinction? Can I drop all the WPA version 1 code from the driver?
> > 
> > A little more information:
> > 
> > The WEXT driver defines ciphers, from looking at ieee80211.h it
> > seems
> > that it uses WLAN_CIPHER_SUITE_XXX for WPA2 and for WPA it uses
> > 
> > #define CIPHER_ID_WPA_NONE    "\x00\x50\xf2\x00"
> > #define CIPHER_ID_WPA_WEP40   "\x00\x50\xf2\x01"
> > #define CIPHER_ID_WPA_TKIP    "\x00\x50\xf2\x02"
> > #define CIPHER_ID_WPA_CCMP    "\x00\x50\xf2\x04"
> > #define CIPHER_ID_WPA_WEP104  "\x00\x50\xf2\x05"
> > 
> > FYI ieee80211.h has
> > 
> > #define WLAN_OUI_MICROSOFT	       0x0050f2
> > 
> > Thanks for taking the time to read this mail, any suggestions most
> > appreciated.
> > 
> > thanks,
> > Tobin.

Re: WPA and WPA2

[Johannes Berg]

Just a small correction:

On Wed, 2017-05-24 at 11:44 -0500, Dan Williams wrote:
> 
> For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused.

PTK and GTK, and in theory you could have more than two GTKs but that's
not usually done.

> Because WEXT is pretty convoluted, I woudn't necessarily try to
> translate what eg ks_wlan_set_encode_ext() is doing directly to
> cfg80211, but to understand how the firmware interface works and then
> just write the cfg80211 code to the firmware interface.
> 
> Basically, you have the following modes:
> 
> a) open, no encryption
> b) WEP encryption (4 possible WEP keys, each either 40 or 104 bits)
> c) WPA/RSN (PMK and GMK are computed by wpa_supplicant and supplied
> to you, just need to send to firmware)

Again, PTK/GTK :)

> And to answer Johannes, this firmware looks much more fullmac than
> softmac; BSS selection seems left up to the firmware.  You just send
> it a "connect with these parameters" command (HIF_INFRA_SET_REQ)
> including channels, SSID, BSSID, mode, etc and it does everything.

Yeah. Makes sense then.

johannes

Re: WPA and WPA2

[Tobin C. Harding]

On Wed, May 24, 2017 at 08:06:40PM +0200, Johannes Berg wrote:
> Just a small correction:
> 
> On Wed, 2017-05-24 at 11:44 -0500, Dan Williams wrote:
> > 
> > For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused.
> 
> PTK and GTK, and in theory you could have more than two GTKs but that's
> not usually done.

Excuse my ignorance but why do you say PTK and GTK here? Who generates
the transient keys, hardware, firmware or software? Is this device
specific or is there a *normal* way?

>From the nomenclature in the WEXT driver I thought the driver supplied the
master keys to the firmware and transient keys were generated at the
firmware layer or lower.

thanks,
Tobin.

Re: WPA and WPA2

[Tobin C. Harding]

On Wed, May 24, 2017 at 11:44:00AM -0500, Dan Williams wrote:
> On Wed, 2017-05-24 at 17:34 +1000, Tobin C. Harding wrote:
> > On Wed, May 24, 2017 at 05:27:50PM +1000, Tobin C. Harding wrote:
> > > Hi,
> > > 
> > > I am attempting to rewrite the ks7010 WEXT driver
> > > (drivers/staging/ks7010)
> > > to use the CFG80211 API.
> > > 
> > > I am reading 802.11 Wireless Networks - Matthew S. Gast for
> > > reference.
> > > 
> > > I have some confusion regarding WEP/WPA/WPA2/RSN, ciphers, keys and
> > > ie's?
> > > 
> > > As I understand, first there was WEP. Next we got a marketing term
> > > WPA
> > > which referred to 802.11i (which specified the protocols TKIP and
> > > CCMP, and also RSN).
> > > 
> > > WEP vs WPA
> > > ----------
> > > 
> > > To add to my confusion the ks7010 code seemingly mixes up the use
> > > of
> > > WEP keys and WPA keys, to set both the WEP and the WPA keys the
> > > driver
> > > uses the same MIB requests? Yet throughout the code WEP keys and
> > > WPA
> > > keys are stored in separate structures (and treated differently).
> > 
> > Oh, I just got why there is only one MIB request type - there are
> > only
> > one set of keys used by the target
> > 
> > 	DOT11_WEP_DEFAULT_KEY_VALUE1	= 0x13020101,
> > 	DOT11_WEP_DEFAULT_KEY_VALUE2	= 0x13020102,
> > 	DOT11_WEP_DEFAULT_KEY_VALUE3	= 0x13020103,
> > 	DOT11_WEP_DEFAULT_KEY_VALUE4	= 0x13020104,
> > 
> > removing 'WEP' from the defines removes the confusion here :)
> 
> I could be entirely wrong, but it looks like the driver really just
> defines 4 "keys" which can be used for anything.

Thank you very much for taking the time to look at the driver, I
really appreciate it.

> For WEP, they are the 4 WEP key indexes.
> 
> For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused.
> 
> Because WEXT is pretty convoluted, I woudn't necessarily try to
> translate what eg ks_wlan_set_encode_ext() is doing directly to
> cfg80211, but to understand how the firmware interface works and then
> just write the cfg80211 code to the firmware interface.

That's a good idea.

thanks,
Tobin.

Re: WPA and WPA2

[Dan Williams]

On Thu, 2017-05-25 at 08:40 +1000, Tobin C. Harding wrote:
> On Wed, May 24, 2017 at 08:06:40PM +0200, Johannes Berg wrote:
> > Just a small correction:
> > 
> > On Wed, 2017-05-24 at 11:44 -0500, Dan Williams wrote:
> > > 
> > > For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused.
> > 
> > PTK and GTK, and in theory you could have more than two GTKs but
> > that's
> > not usually done.
> 
> Excuse my ignorance but why do you say PTK and GTK here? Who
> generates
> the transient keys, hardware, firmware or software? Is this device
> specific or is there a *normal* way?
> 
> From the nomenclature in the WEXT driver I thought the driver
> supplied the
> master keys to the firmware and transient keys were generated at the
> firmware layer or lower.

Usually the supplicant supplies only the PTK/GTK to the driver at the
right times (like during the 4-way handshake).  It looks like the
driver only refers to PMK/GMK when using the rx_seq[] bits, while the
actual WPA keys are probably the PTK/GTK.

While it's not the best example, see
drivers/net/wireless/marvell/libertas/cfg.c and lbs_cfg_connect() and
lbs_cfg_add_key().  That should translate fairly well to the ks7010
driver.  The important parts you'll get from nl80211 are
add_key/del_key and set_default_key.  The connect hook gets called
first to tell the driver to start the auth/assoc process to a given AP,
 and that's where you'd set up the general stuff like whether or not
you'll use WEP or WPA, what the SSID/BSSID are, whether PSK or
EAPOL/802.1x, rates, etc.  Then after that you'll get the add_key hook
that actually sends the real keys to the driver when the supplicant has
calculated them.


Dan

Re: WPA and WPA2

[Johannes Berg]

On Thu, 2017-05-25 at 08:40 +1000, Tobin C. Harding wrote:
> On Wed, May 24, 2017 at 08:06:40PM +0200, Johannes Berg wrote:
> > Just a small correction:
> > 
> > On Wed, 2017-05-24 at 11:44 -0500, Dan Williams wrote:
> > > 
> > > For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused.
> > 
> > PTK and GTK, and in theory you could have more than two GTKs but
> > that's
> > not usually done.
> 
> Excuse my ignorance but why do you say PTK and GTK here?

Well, you said that it was doing TKIP MMIC in software, so you need the
TK to do that :) It seemed unlikely to be received from the firmware.
Also, I know that Dan meant PTK/GTK - a "GMK" doesn't exist at all.

> Who generates the transient keys, hardware, firmware or software? Is
> this device specific or is there a *normal* way?

Dan explained this well.

> From the nomenclature in the WEXT driver I thought the driver
> supplied the master keys to the firmware and transient keys were
> generated at the firmware layer or lower.

Seems unlikely, but it seems also very based on WEP which didn't have a
concept of "master" and "transient" keys.

johannes

Re: WPA and WPA2

[Tobin C. Harding]

On Thu, May 25, 2017 at 12:45:53PM -0500, Dan Williams wrote:
> On Thu, 2017-05-25 at 08:40 +1000, Tobin C. Harding wrote:
> > On Wed, May 24, 2017 at 08:06:40PM +0200, Johannes Berg wrote:
> > > Just a small correction:
> > > 
> > > On Wed, 2017-05-24 at 11:44 -0500, Dan Williams wrote:
> > > > 
> > > > For RSN, they are 1 = PMK, 2 = GMK, 3 = GMK2, 4 seems unused.
> > > 
> > > PTK and GTK, and in theory you could have more than two GTKs but
> > > that's
> > > not usually done.
> > 
> > Excuse my ignorance but why do you say PTK and GTK here? Who
> > generates
> > the transient keys, hardware, firmware or software? Is this device
> > specific or is there a *normal* way?
> > 
> > From the nomenclature in the WEXT driver I thought the driver
> > supplied the
> > master keys to the firmware and transient keys were generated at the
> > firmware layer or lower.
> 
> Usually the supplicant supplies only the PTK/GTK to the driver at the
> right times (like during the 4-way handshake).  It looks like the
> driver only refers to PMK/GMK when using the rx_seq[] bits, while the
> actual WPA keys are probably the PTK/GTK.
> 
> While it's not the best example, see
> drivers/net/wireless/marvell/libertas/cfg.c and lbs_cfg_connect() and
> lbs_cfg_add_key().  That should translate fairly well to the ks7010
> driver.  The important parts you'll get from nl80211 are
> add_key/del_key and set_default_key.  The connect hook gets called
> first to tell the driver to start the auth/assoc process to a given AP,
>  and that's where you'd set up the general stuff like whether or not
> you'll use WEP or WPA, what the SSID/BSSID are, whether PSK or
> EAPOL/802.1x, rates, etc.  Then after that you'll get the add_key hook
> that actually sends the real keys to the driver when the supplicant has
> calculated them.
> 
> 
> Dan

Awesome, thanks Dan