Re: [Hipsec] HIT security analysis -- Follow-up on 4843bis / ORCHIDv2

[Tobias Heer <[e-mail]>]

Hi Bob, 

some quick comments from me...

Am 13.04.2010 um 16:02 schrieb Robert Moskowitz:

> Collision Resistance
> 
> HITs SHOULD be generated in a manner that is collision resistant. The application only knows the HIT, not the HI. So if an application were communicating with two hosts that had the same HIT, the API would not be able to route traffic appropriately. With the 96 bit space in ORCHIDv2, what is the probability of a collision, given Collision Resistance, with a host connected to 10 peers? To 10,000 peers? To 1,000,000 peers? (can someone do the math?)
> 
I had sent a mail to the list doing the math for finding collisions in equal-sized sets (any HIT collision will do). However for attacking any host in a ACL the sets are not equal-sized (you have a lot of possible HITs but only few that are useful for an attack). This makes it considerably harder.

> There is no advantage for Malice to find 2 HIs that have the same HIT. There does not seem to be a cryptographic risk related to Collision Resistance.
Uh, ...  if Malice would find a HI/HIT collision for a HIT in use, she could impersonate the other host - that would be bad. Again, this does not apply to arbitrary HI collisions but to collisions for a set of target HIs.


> 
> Preimage Resistance
> 
> If a host only has the HIT of its peer, then it is at risk of a Preimage attack. This applies to implementations that use a /etc/host file style ACL. Those that use HIP DNS records obtain both the HIT and HI and thus are resistant to a preimage attack. Opertunistic mode 'does not care'. It gets what it gets in R1; Malice can do whatever it wants in constructing an R1 and does not need to resort to a Preimage attack.
Finding the preimage of the HIT is not bad in the first place because in most cases the HI is public anyway. Second preimage is more relevant but only if the second preimage is a HI for which the attacker has the private key.
IMHO just looking at preimage resistance boils down to breaking the HI.
> 
> Second Preimage Resistance
> 
> Malice could launch a HIP state attack if the HIT generation is subject to a Second Preimage attack. If Malice determines that Bob and Alice are currently communicating, and Bob has HI1 and HIT1 and Malice can generate HI2 with HIT1, then Malice can 'take over' the communication channel from Bob to Alice with a new HIP exchange.
I guess this really depends how the HIP implementation handles HIs. If the implementation identifies HIP associations by HITs it is possible, if it identifies them by using HIs it is not a problem. RFC5201 Section 4.5.4.  "Reboot and SA Timeout Restart of HIP" provides little information how to handle a second HIP association for the same HIT. RFC4423 states "In the extremely rare case of a single HIT mapping to more than one Host Identity, the Host Identifiers (public keys) will make the final difference.". Hence, the different HI should prevent an attacker from taking over a connection. However, the handling of the IPsec security associations (bound to HITs) will prevent the second host to open a connection - this could work as DoS attack... although I doubt that it is of practical relevance. 

> This will be exposed, however as soon as Bob communicates with Alice and gets HIP errors. So this attack is only of value when Bob is a listener only (Alice is a sensor that only sends data) and does not check to ensure it is regularly receiving data from Alice.

I don't get the passage above.

Tobias


> 
> The Opertunistic mode analysis here is the same as for Preimage Resistance with the above state attack caveat.
> 
> From this brief analysis I get that provided that HIT/HI connection is maintained in all ACLs (and state machines), then the only hash security feature HITs/ORCHIDs need is Collision Resistance. As noted above, this is NOT the case for implementations that rely on a /etc/hosts style ACL.
> 
> 
> On 04/07/2010 12:42 PM, Robert Moskowitz wrote:
>> I am back (kind of) from Passover holidays.
>> 
>> Given some of the content of the 4843bis thread, I went looking to see if we had any writeup on the security threats for HITs, and really did not find a consistant writeup. Of course we want to minimize collisions, but what are the threats?
>> 
>> 4423 has always 'allowed' for HITs from a source other than a Public Key, but does not go through the threats, even if there is a PK Host Identity, but something other than a Cryptographic Hash is used to derive the HIT from it.
>> 
>> Or maybe it is all there (the threat analysis) and I am not seeing the tree in the forest.
>> 
>> 
>> _______________________________________________
>> Hipsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hipsec
>> 
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec




--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer