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

[Robert Moskowitz <[e-mail]>]

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?)

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.

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.

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

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
>