On Fri, 2016-10-14 at 16:52 +0300, Jouni Malinen wrote:

On Tue, Sep 27, 2016 at 02:36:15PM +0200, Johannes Berg wrote:

quoted

quoted

+ * @NL80211_ATTR_AUTHORIZED: flag attribute, if set indicates
that the
+ *      connection is authorized.

@@ -2267,6 +2270,8 @@ enum nl80211_attrs {
+	NL80211_ATTR_AUTHORIZED,

This already exists, no?

NL80211_STA_FLAG_AUTHORIZED should be more or less equivalent, if
you do it per station (or just for the AP in case of managed
connection)

It does indeed have a very similar meaning to the proposed
NL80211_ATTR_AUTHORIZED. However, NL80211_STA_FLAG_AUTHORIZED is
something that gets nested in NL80211_ATTR_STA or used with the
mask/set struct in NL80211_ATTR_STA_FLAGS2. I'm not sure either of
those would really be very clean ways to use with a connection/roam
event..

Oh, right, this is used in the event, not for control...

I guess that makes sense then, although it should be a flag attribute
instead of a u8?

We could still put a nested NL80211_ATTR_STA, but I agree that seems
awkward.

PMKSA caching cases, FT protocol, and 4-way handshake following EAP
might be doable in this manner and that might indeed be the cleanest
approach there. 

Ok

However, there will also be need to cover possibility
for offloading FILS at some point in the future.. 

Yeah, I hadn't considered FILS.

For FILS with shared key, the configuration will actually include ERP
keys that are not bound to any specific Authenticator/AP/BSSID and do
not really have a PMKSA cache entry.. At latest at that point, I'd
think we'll end up needing something else and that something else
could be defined already now to cover all these cases instead of
trying to force the current cases to go through
NL80211_CMD_SET_PMKSA.

Could be done, I guess. But don't we then have to be careful to
actually bind the non-FILS keys to the right Authenticator/AP/BSSID,
and then we have to invent a way to bind it? Does that make sense?

quoted

In particular, with key management offloaded, it's not clear to me
what exactly the roles of the device and host are here. I'm
considering that the device would handle the 4-way and 2-way
handshakes, but then you wouldn't need the KEK/KCK/ReplayCounter in
the host, so there wouldn't be much point in giving them to it.
But if the device doesn't do that, what exactly *does* it do?

One of the key uses is to allow the Wi-Fi firmware to complete
roaming (say, 4-way handshake based on existing PMKSA) when the host
processor is not awake (i.e., wpa_supplicant is not running at all). 

Ah. So this might not be used when the processor *is* awake? That's a
key point I was missing, perhaps, since we're building something where
it's simply always done by the device.

Why would you want to do it in the processor when you have the ability
to do it in the firmware?

However, this does not mean that we would necessarily offload all
EAPOL-Key processing. GTK rekeying and the initial 4-way handshake
for the first connection to an ESS might be performed by
wpa_supplicant especially in cases where the host is awake anyway.
That's why those PTK-related values need to be kept in sync between
the driver/firmware and host (wpa_supplicant).

Interesting, ok. Whatever the reason, I guess we have to support it
being done that way.

I guess we'll have to hash out the exact details.

I think we can publish a proposal soon that uses the PMKSA cache, but
lacks all the event data since we never see EAPOL-key messages on the
host in that model.

This model here with the temporal key etc. stuff is clearly unworkable.

I'm not sure I've made up my mind on introducing a new mechanism that
covers FILS vs. PMKSA (and then later an only-FILS-style mechanism) -
that's the issue with binding to a BSSID above.

johannes