linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>,
	linux-wireless@vger.kernel.org, hostap@lists.infradead.org,
	yangzy@marvell.com, Cathy Luo <cluo@marvell.com>,
	Nishant Sarmukadam <nishants@marvell.com>,
	lihz <lihz@marvell.com>
Subject: Re: [PATCH] nl80211: add key management offload feature
Date: Fri, 14 Oct 2016 16:38:21 +0300	[thread overview]
Message-ID: <20161014133821.GA8928@w1.fi> (raw)
In-Reply-To: <df801822-f23d-e7e3-15c2-1849370fd01f@broadcom.com>

On Tue, Sep 27, 2016 at 01:24:24PM +0200, Arend Van Spriel wrote:
> On 27-9-2016 12:56, Amitkumar Karwar wrote:
> > From: lihz <lihz@marvell.com>
> 
> minor thing. Could you use another prefix iso 'nl80211:'. That has
> different expectation for me at least, ie. changes in nl80211 api, but
> this patch is for hostap repo so 'hostap:' or 'wpa_supp:' would be
> better fit here.

Well.. That's for the context of linux-wireless. As far as the actual
commit in hostap.git and the hostap mailing list (now with the correct
address) is concerned, "nl80211:" is the correct prefix to use in the
commit message.

> > diff --git a/src/common/defs.h b/src/common/defs.h
> > @@ -148,7 +148,9 @@ enum wpa_alg {
> > -	WPA_ALG_BIP_CMAC_256
> > +	WPA_ALG_BIP_CMAC_256,
> > +	WPA_ALG_PMK_R0,
> > +	WPA_ALG_PMK_R0_NAME,

I guess I could kind of understand WPA_ALG_PMK_R0 as a new "algorithm"
since this is also used to configure keys, but PMK-R0-Name is going
pretty far in that regard. It most certainly is not a key..

> >  #define WLAN_CIPHER_SUITE_SMS4		0x00147201
> > +#define WLAN_CIPHER_SUITE_PMK		0x00147202
> > +#define WLAN_CIPHER_SUITE_PMK_R0	0x00147203
> > +#define WLAN_CIPHER_SUITE_PMK_R0_NAME	0x00147204

As noted previously, it is not acceptable to assign new AKMs from
someone else's OUI. Once there is consensus on what values are needed, I
can assign the needed values from the 00:13:74 OUI.

> > diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
> > @@ -2675,21 +2675,34 @@ static int wpa_driver_nl80211_set_key(const char *ifname, struct i802_bss *bss,
> > -#ifdef CONFIG_DRIVER_NL80211_QCA
> > -	if (alg == WPA_ALG_PMK &&
> > -	    (drv->capa.flags & WPA_DRIVER_FLAGS_KEY_MGMT_OFFLOAD)) {
> > -		wpa_printf(MSG_DEBUG, "%s: calling issue_key_mgmt_set_key",
> > -			   __func__);
> > -		ret = issue_key_mgmt_set_key(drv, key, key_len);
> > -		return ret;
> > +
> > +	if ((alg == WPA_ALG_PMK || alg == WPA_ALG_PMK_R0 ||
> > +	     alg == WPA_ALG_PMK_R0_NAME) &&

I understand PMK as a new key that is being configured. For FT, I'm not
completely sure about PMK-R0 as a separate algorithm and especially not
about using this interface for setting PMK-R0-Name which is tightly
coupled name with a specific PMK-R0 and not something that one would
configure separately.

> > diff --git a/src/drivers/driver_nl80211_event.c b/src/drivers/driver_nl80211_event.c
> > @@ -2065,18 +2065,6 @@ static void do_process_drv_event(struct i802_bss *bss, int cmd,
> >  	wpa_printf(MSG_DEBUG, "nl80211: Drv Event %d (%s) received for %s",
> >  		   cmd, nl80211_command_to_string(cmd), bss->ifname);
> >  
> > -	if (cmd == NL80211_CMD_ROAM &&
> > -	    (drv->capa.flags & WPA_DRIVER_FLAGS_KEY_MGMT_OFFLOAD)) {
> > -		/*
> > -		 * Device will use roam+auth vendor event to indicate
> > -		 * roaming, so ignore the regular roam event.
> > -		 */
> > -		wpa_printf(MSG_DEBUG,
> > -			   "nl80211: Ignore roam event (cmd=%d), device will use vendor event roam+auth",
> > -			   cmd);
> > -		return;
> > -	}

It is not going to be acceptable to break the existing mechanism that
uses QCA vendor specific commands/events. In other words, the new
extensions need to be done in a backwards compatible manner that allow
both to work based on driver capabilities.

> > diff --git a/src/rsn_supp/wpa_ft.c b/src/rsn_supp/wpa_ft.c
> > @@ -37,6 +37,10 @@ int wpa_derive_ptk_ft(struct wpa_sm *sm, const unsigned char *src_addr,
> > +	wpa_sm_set_key(sm, WPA_ALG_PMK_R0, NULL, 0, 1, NULL,
> > +		       0, sm->pmk_r0, PMK_LEN);
> > +	wpa_sm_set_key(sm, WPA_ALG_PMK_R0_NAME, NULL, 0, 1, NULL,
> > +		       0, sm->pmk_r0_name, WPA_PMK_NAME_LEN);

This looks quite bad. I don't think I can really support two separate
nl80211 commands to set a PMK-R0 and the matching PMK-R0-Name, i.e.,
this should really be a single (atomic) operation.

-- 
Jouni Malinen                                            PGP id EFC895FA

  reply	other threads:[~2016-10-14 13:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-27 10:56 [PATCH] cfg80211: add key management offload feature Amitkumar Karwar
2016-09-27 10:56 ` [PATCH] nl80211: " Amitkumar Karwar
2016-09-27 11:24   ` Arend Van Spriel
2016-10-14 13:38     ` Jouni Malinen [this message]
2016-09-27 11:27   ` Arend Van Spriel
2016-09-27 11:14 ` [PATCH] cfg80211: " Kalle Valo
2016-09-27 12:36 ` Johannes Berg
2016-10-14 13:52   ` Jouni Malinen
2016-10-20 12:53     ` Johannes Berg
2016-10-26 12:11 ` Johannes Berg
2016-10-26 12:26   ` [RFC] cfg80211: support 4-way-handshake offload with PSK and 802.1X Johannes Berg

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=20161014133821.GA8928@w1.fi \
    --to=j@w1.fi \
    --cc=akarwar@marvell.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=cluo@marvell.com \
    --cc=hostap@lists.infradead.org \
    --cc=lihz@marvell.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nishants@marvell.com \
    --cc=yangzy@marvell.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).