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