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

From: Robert Moskowitz <[email-masked]>
Date: Wed, 07 Apr 2010 12:42:11 -0400

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.

---

From: Tobias Heer <[email-masked]>
Date: Mon, 12 Apr 2010 17:14:39 +0300

Hi Bob, 

sorry for the late reply - I have been traveling / was on holiday, too.

Am 07.04.2010 um 19:42 schrieb Robert Moskowitz:

> 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.
> 
I am not aware of such document but from my understanding, having a non-cryptographic HIT still requires some cryptographic binding to a public key so that you have a signature algorithm that you can use in the BEX. Such binding could be a certificate that binds the non-cryptographic identity to a public key. However, I do not know any direct source of information. I would certainly be interested if there is some work on this already.

Tobias

> Or maybe it is all there (the threat analysis) and I am not seeing the tree in the forest.
> 
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 13 Apr 2010 08:33:54 -0400

On 04/12/2010 10:14 AM, Tobias Heer wrote:
> I am not aware of such document

read RFC 4423. There are warnings, but as a 'nod' to work elsewhere we 
covered non-cryptographically based HITs with NO backing crypto.

>   but from my understanding, having a non-cryptographic HIT still requires some cryptographic binding to a public key so that you have a signature algorithm that you can use in the BEX.

Obviously such a HIT would not use BEX, but some other HIP exchange.
>   Such binding could be a certificate that binds the non-cryptographic identity to a public key. However, I do not know any direct source of information. I would certainly be interested if there is some work on this already.
>
> Tobias
>
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 13 Apr 2010 09:02:31 -0400

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.

---

From: Tobias Heer <[email-masked]>
Date: Tue, 13 Apr 2010 17:57:25 +0300

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

--