[PATCHv3 0/4] Improvements for roaming

[michael-dev]

Hi,

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].

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.

> consider potential needs for replay protection here as well.. In the
> current implementation, the only available protection is timestamp
> comparison which has a 60 second window to allow not exactly
> synchronized system times on the devices.

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

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.

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.
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.

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

Regards,
M. Braun

[1] https://github.com/michael-dev/hostapd/tree/dev-20161207