Sequences for PTK rekeying

[Jouni Malinen]

On Tue, Dec 05, 2006 at 12:34:32PM +0000, Mark Powell wrote:

> We are trying to understand the possible message sequences for PTK/GTK
> establishment and rekeying that wpa_supplicant uses via the
> Wireless Extensions API, and the interaction with the driver.

Are you looking this for WPA or IEEE 802.11i/WPA2? The main difference
is in when the GTK is configured during the initial association.

> Looking at PTKs first, it seems to me that there are six possible
> scenarios:

> 1) Us initiator, success.
> The sequence is:
> 
>     Tx EAPOL Auth 1
>     Rx EAPOL Auth 2
>     Tx EAPOL Auth 3
>     Rx EAPOL Auth 4
>     Set keys

'Us' would be an authenticator here and "EAPOL Auth" would be an
EAPOL-Key frame. This seems to match with the expected behavior for IEEE
802.11i authenticator.

> 2) Us responder, success.
> 
>     Rx EAPOL Auth 1
>     Tx EAPOL Auth 2
>     Rx EAPOL Auth 3
>     Tx EAPOL Auth 4
>     Set keys

> Particularly, does the SetKeys happen after the Tx EAPOL Auth 4 or could
> it happen after the Rx EAPOL Auth 3?

'Us' would be a supplicant. If the implementation were to follow the
"state machine" (in practice, the pseudo-code part of it) in IEEE
802.11i, PTK would actually be set before sending out msg 4/4. However,
msg 4/4 would not be encrypted, because MLME-SETPROTECTION.request() is
used only after this to enable encryption. In practice, I would expect
many implementations to do this by sending msg 4/4 before setting PTK
since MLME-SETPROTECTION.request primitive is not commonly implemented.

> Does the system wait for acknowledgement of the second tx before setting
> the keys?

There is no such requirement in IEEE 802.11 if I remember correctly. In
practice, there is a race condition with msg 4/4 and even if there were
a wait for ACK here, the AP might have ACK'ed the frame in very low
layer and then dropped it for some other reason after which it would
just retry msg 3/4 and would eventually fail to receive msg 4/4 since
that would now be encrypted. If I remember correctly, WPA resolved this
race by allowing authenticator state machine to ignore the lack of msg
4/4 and just configure PTK if all retries of msg 3/4 fail. IEEE 802.11i
does not have this workaround, but some implementations may still do it.

It would be kind of nice to wait for acknowledgement here, but I don't
know whether any implementation does that. At least wpa_supplicant does
not have code for doing it nor is there an interface to the driver that
would allow this to be done in most cases. With net/d80211 and userspace
MLME implementation, this could be a change that could be considered.

> 3) Us initiator, fails at second stage.
> 
>     Tx EAPOL Auth 1
>     Rx EAPOL Auth 2
>     Tx EAPOL Auth 3
>     Timeout or rx bad EAPOL Auth 4
> 
> Is there any indication to the driver that the key
> establishment/rekeying has failed?

Not at this point. Authenticator would re-transmit msg 3/4 couple of
times and then disconnect the client which would show up as an
indication to the driver.

> 4) Us responder, fails at second stage.
> 
>     Rx EAPOL Auth 1
>     Tx EAPOL Auth 2
>     Timeout or rx bad EAPOL Auth 3
> 
> Is there any indication to the driver that the key
> establishment/rekeying has failed?

Not explicitly for this case, but at least wpa_supplicant would try to
association again after the timeout.

> 5) Us initiator, fails at first stage.
> 
>     Tx EAPOL Auth 1
>     Timeout or rx bad EAPOL Auth 2
> 
> Is there any indication to the driver that the key
> establishment/rekeying has failed?

Same as case 3 (re-transmit of msg 1/4).

> 6) Us responder, fails at first stage.
> 
>     Rx bad EAPOL Auth 1
> 
> 
> Well, at least this one is easy!

Same as case 4.

> Is there any difference between initial PTK establishment and
> rekeying?

The main difference is in EAPOL-Key frames being encrypted in rekeying
case. This may change the race between 4/4 and retries of 3/4 a bit, but
the same issue may show up due to different PTK being configured at
before the authenticator has received msg 4/4.

> Similarly, for GTKs there seem to be four possible scenarios:

> 1) Us initiator, success.
> 
>     Tx EAPOL Auth 1
>     Rx EAPOL Auth 2
>     Set keys
> 
> Correct?

This is more complex. Authenticator uses multiple GTKs (usually two with
key indexes 1 and 2 (0-based index, i.e., 0..3). Authenticator wcan set
the GTK even before sending the update since the old key is using
another key index. However, the new GTK is taken into use (i.e., AP
starts transmitting multicast/broadcast frames using it) only after the
GTK has been sent to all associated STAs (i.e., only after having
received msg 2/2 from all STAs or after this has timed out(.

> 2) Us responder, success.
> 
>     Rx EAPOL Auth 1
>     Tx EAPOL Auth 2
>     Set keys
> 
> Is this correct?
> Particularly, does the SetKeys happen after the Tx or could it happen
> after the Rx?

GTK should be set before transmitting 2/2. Though, doing it after TX
would not really matter much in most cases unless the key configuration
is going to take long time. The AP will not be using the new GTK before
having received msg 2/2 from all STAs.

> Does the system wait for acknowledgement of the tx before setting the keys?

No and not much for this either since GTK is not used for encrypting
msg 1/2 or 2/2.

> 3) Us initiator, fails.
> 
>     Tx EAPOL Auth 1
>     Timeout or rx bad EAPOL Auth 2
> 
> Is there any indication to the driver that the key
> establishment/rekeying has failed?

Not at this point, but if retries of 1/2 fail, the client will be
disconnected.

> Again, is there any difference between the initial GTK establishment and
> GTK rekeying?

Yes, initial GTK establishment in IEEE 802.11i/WPA2 happens as part of
the 4-way handshake, i.e., there will not be msg 1/2 and 2/2 for it. In
case of WPA, both the initial GTK establishment and GTK rekeying is
using group key handshake (msgs 1/2 and 2/2), so they are more alike.

-- 
Jouni Malinen                                            PGP id EFC895FA