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
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
