Am 16.03.20 um 22:37 schrieb Jouni Malinen:
On Mon, Mar 16, 2020 at 10:07:26PM +0100, Alexander Wetzel wrote:
First, you see BASIC+FT0+FILS0 as standardized? (See previous mail)
I don't understand what "FT0" and "FILS0" really mean.. If that means
never using KeyID 1 with FT protocol or FILS authentication when going
through PTK rekeying, no, I don't think I would say so. If those mean
that the very first KeyID for an association has to be 0, I guess I'd
agree. So in the simplest default case: KeyID 0 is always assigned first
regardless of which authentication mechanism is used and PTK rekeying
through 4-way handshake can then switch between KeyID 1 and 0 since that
same design is used with all cases.
The only question is then if we can "mark" the connections to be using
Extended Key ID at the FT or FILS connect or shall wait till we rekey.
Since both handshakes have RSN and therefore the Extended Key ID Capability
Bit the initial connect seems to be the logical point.
Alternatively we can make the check that the AP is not stopping using
Extended Key ID less strict and allow e.g. PTK0 rekey for at least the first
EAPOL rekey. Even when the RSN Capapilities at the initial connect told us
it should be Extended Key ID.
I'm not sure I fully follow the terminology of "PTK0 rekey" and what
would you describe here.. I'd expect station/supplicant to follow
whatever the AP tells it for the KeyID. If there is no explicit
indication of KeyID for the initial TK at the beginning of association,
0 have to be assumed to be used. Whenever going through PTK rekeying
(4-way handshake), if there is an explicit indication of Key ID (i.e.,
Key ID KDE), that provides the Key ID to use; otherwise, 0 is assumed.
First: FT0 and FILS0 seem to to exactly what you want. I'm just not sure
if you are ok with how these modes "pin" Extended Key Id support with
the initial handshakes (FT or FILS) and make sure the rekeys are then
using something different later.
I would also have simple told the STA to signal support for Extended Key
ID and only check the KeyID in EAPOL#3: If there is a keyID use that. If
not use zero. But the standard forces us to check the RSN (chapter
12.7.6.4):
If the Extended Key ID for Individually Addressed Frames subfield of the
RSN Capabilities field is 1 for both the Authenticator and Supplicant
then prior to sending message 4, STA_P uses the MLME-SETKEYS.request
primitive to configure the IEEE 802.11 MAC to receive individually
addressed MPDUs protected by the STK with the assigned Key ID.
Simply acting on the KeyID would therefore violate the standard.
Or are you just talking about the wpa_deny_ptk0_rekey != 0 cases?
Wouldn't that be obvious at the time of the first rekey? If both the
initial TK and the second TK from that first rekey use Key ID 0, the AP
is not using Extended Key ID.
Yes, that would also be a problem... wpa_deny_ptk0_rekey != 0 is
resetting the connection normally way prior to getting the new keyID.
when we not decide at the initial connection if we are using Extended
Key ID or not we would have to reset the connection much later and not
at the first indication one end plans to rekey.
wpa_supplicant can also be configured to start an AP. The network setting is
passed through to the AP. Using a global setting for that will prevent to
configure it for the AP at all. It either would be stuck to a hard coded
value or to the global config setting. Shall I go for that?
Ah, yes.. We'll have to consider the implication for AP mode. I guess it
could be justifiable to do that with the shared global parameter as
well. A specific network profile for AP mode is explicitly selected
anyway, so there would be no significant limitation from requiring the
global parameter value to be set for cases where different setting for
use of Extended Key ID is needed. I'd probably also drop the special
case of starting with Key ID 1, i.e., simply have ext_key_id=0/1 as the
wpa_supplicant global parameter while hostapd would use ext_key_id=0/1/2
to allow start-with-KeyID-1 testing (with PSK/SAE; not with FT/FILS per
discussion on what the standard actually describes).
Honestly I'm thinking of dropping the "start-with-keyid-1" outright now.
Just using it for testcases is probably not worth it.
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
