[PATCHv3 0/4] Improvements for roaming

[Jouni Malinen]

On Wed, Dec 07, 2016 at 09:49:16PM +0100, michael-dev wrote:
> Am 29.11.2016 22:55, schrieb Jouni Malinen:
> >AES-SIV would likely be the simplest option here
> 
> agreed, preliminary patches can be found here [1].
> [1] https://github.com/michael-dev/hostapd/tree/dev-20161207

It would be possible to derive the two AES-SIV keys (or well, one longer
key as it looks outside the SIV implementation) from the currently
configured 128-bit key using one of KDFs implemented in hostap.git, if
we want to maintain previously used configuration file design. I'm not
sure which way would be better here, i.e., either to make it painfully
obvious that the protocol and configuration needs changed and force
configuration file updates for keys in deployed systems wanting to
upgrade software or alternatively, try to minimize the impact and only
require network wide synchronized update of the hostapd binary.

> I'm thinking about splitting the message into two parts: one
> encrypted part and one only authenticated part, as AES-SIV allows
> for this.
> This would permit to filter for destination R0KH-ID/R1KH-ID/S1KH-ID
> and NONCE before decrypting and verifying the message. This might be
> especially useful with broadcasting, as it reduces the need to
> decrypt (correct) messages not intended for this instance.
> Though, it would also add extra complexity that is not strictly needed.

At minimum, some of the frame header fields could be included in the
authenticated-only area. If other parts are useful to allow
optimizations, now would be the time to do them, so I'm fine with the
added complexity (well, to a limit and this is not really that complex).

> Before discussing the need for replay protection, one should first
> identify the goals of RRB message crypto.
> 
> These goals are:
>  - authentication -> the attacker should not be able to impersonate
> another station by snooping the relevant keys
>  - access control -> it should be possible to revoke the permission
> to access the network by limiting time for using the MSK
>  - privacy -> the attacker should not be be able to learn the
> identity of the station roaming by snooping the RRB-OUI messages

DoS protection comes to picture especially with the other uses that has
been discussed for the AP-to-AP protocol (band/AP steering).

> Authentication and privacy is achieved by using AES-SIV.
> 
> There are three messages that can be replayed.
> 1. Replaying a "pull" message does not affect these goals, as it
> only triggers the R0KH to (re-)send the current (fresh) state
> 2. Replaying a "pull response" message does not affect these goals,
> as the receiver checks the nonce included in the message
> 3. Replaying a "push" message is the only message that could affect
> access control.
> 
> In order to circumvent access control, a push message could be
> replayed later in order to extend the session lifetime beyond the
> intended limit.

For the band/AP steering case (which admittedly could use different
solution even if using the same frame encapsulation mechanism) there
would be potential messages asking for a STA to be disconnected.
Similarly, something like enhanced IAPP could come up with cleanup
mechanism to get rid of old association entries during reassociation.

> Replay protection would prevent an attacker to reuse an already
> received message to gain access again. But it does not prevent the
> attacker in delaying a message and using it later, when the msk
> lifetime would already have expired. Hostapd might fall back to
> pull/resp for earlier roaming. Additionally a rogue station might
> trigger more push messages in order to be able to extend the
> lifetime even further without replaying a single message multiple
> times.

We should include MSK/PMK lifetime in the messages to avoid this type of
issues..

> In constrast, the 60 second window limits (with synchronized clocks)
> the time a session can be extended by an adversary to 60 seconds.
> 
> I'm wondering if time synchronisation using ntp might affect correct
> reauthentication timeout, as a man-in-the-middle attacker could
> impersonate the ntp server and thus affect the clock on the
> AccessPoints. This in turn might affect all session timers used by
> hostapd. So getting rid of these synchronized clocks would be
> beneficial.
> 
> Though without synchronized clocks, freshness of a push message can
> only be achieved by some kind of interaction.
> E.g.:
>  - each R1KH periodically sends a fresh (random) token to each R0KH
> and R0KH caches these token
>  - the push message includes this token so the R1KH can verify that
> this message is sufficiently fresh
> 
> Verifying freshness only in response to receiving a push message
> might overload the receive buffer of R0KH. We also cannot assume
> that each hostapd instance (r1kh) knows about each other hostapd
> instance (r0kh) in this mobility domain and thus not optimize based
> on this.

Each unicast exchange could verify freshness with nonce exchanges in
both directions, but this gets inconvenient for broadcast.. And well,
inconvenient with extra messages. In practice, having a key management
mechanism (e.g., something similar to 4-way handshake) to generate a new
key and then use an incrementing packet number that gets reset to 0 with
every new key and verified by the receiver to be incrementing whenever
same key is used would be the way to go here, if one were to provide
proper replay protection. One benefit from this would be in getting rid
of the synchronized clock requirement for the 60 second window type of
design. Then again, for maintaining consistent MSK/PMK lifetime,
synchronized time may be needed anyway. Or well, I guess the message
could always include the remaining number of seconds that the recipient
converts to something matching local time.

> I'm unsure if this complexity is actually worth it.

I'm leaning to agree with this if there is clear mechanisms that
prevents wireless STAs from receiving the AP-to-AP messages (i.e., so
that they would not even have anything to replay). That sounds likely to
be the case for unicast. What would happen with the broadcast messages,
though? Will Linux bridge code propagate them to all the wireless
interfaces as well?

-- 
Jouni Malinen                                            PGP id EFC895FA