[Hipsec] [Fwd: Fwd: Belovin-Rescorla analysis - HIP]

[Gonzalo Camarillo <[e-mail]>]

Hi,

we have already gotten the B-R analysis on the main spec.

Cheers,

Gonzalo

-------- Original Message --------
Subject: Fwd: Belovin-Rescorla analysis - HIP
Date: Sat, 01 Apr 2006 17:06:02 -0500
From: Russ Housley <[e-mail]>
To: [e-mail], [e-mail]
CC: [e-mail]

Charlie Kaufman did the security review for HIP.  Please take a look
at his review, and let us know your thoughts.

Russ

>From: Charlie Kaufman <[e-mail]>
>To: Russ Housley <[e-mail]>, "[e-mail]" <[e-mail]>
>CC: "[e-mail]" <[e-mail]>
>Date: Thu, 23 Mar 2006 12:49:35 -0800
>Subject: RE: [secdir] [Fwd: Belovin-Rescorla analysis] - HIP
>
>I read draft-ietf-hip-base-05.txt, draft-ietf-hip-esp-02.txt, 
>draft-ietf-hip-arch-03.txt with a particular eye towards 
>shortcomings with crypto algorithm agility. The HIP design has 
>evolved considerably since I last read it. I can't in good 
>conscience tell you that this is a complete analysis - these 
>documents are primarily about security. HIP today looks a lot like IKEv2.
>
>Issues with crypto agility:
>
>While crypto algorithms are in some cases negotiated, there are 
>several places where use of SHA-1 is "wired in". In one very 
>important case, this would be very hard to fix.
>
>A central idea behind HIP is that a hash of a public key can be used 
>as a host identifier and that identifier can be used in place of an 
>IPv6 address in both internal data structures and in some cases on 
>the wire. Because IPv6 has a fixed address size of 128 bits, the 
>public key hash can be no larger than 128 bits. Because of address 
>allocation issues, the proposed actual size of the hash is 120 bits.
>
>The HIP base document makes a normative reference to 
>draft-laganier-ipv6-khi-01, and that document wires in both use of 
>SHA-1 and the extraction of a particular 120 bits of the SHA-1 hash. 
>Switching to use 120 bits of a SHA-256 hash would not be terribly 
>difficult, but it's not clear that would be any more secure.
>
>There are no real attacks on HIP based on finding collisions, but as 
>with many of these protocols there could be long theoretical 
>discussions about how finding collisions would be interesting. A 
>real attack would depend on the ability to find a second preimage.
>
>There are other places where SHA-1 is wired in with no mechanism for 
>negotiating anything else. None can be exploited given collision 
>attacks. They are:
>
>1) Key expansion: hash is not negotiated - SHA-1 wired in.
>
>2) Puzzles: SHA-1 is certainly "good enough" for puzzles, since any 
>weakness would have to find a first preimage more quickly than 
>computing a small number of hashes.
>
>3) HMAC and encryption algorithms are negotiated, but currently 
>SHA-1 and MD5 are the only registered options. In one place, the 
>size of the output of the HMAC is fixed at 160 bits. This is 
>probably a bug in the spec and easily fixed.
>
>4) When doing signatures, the HASH type is not negotiated but rather 
>is assumed to be determined by the signature algorithm (which is 
>also not negotiated). Each endnode decides the signature and hash 
>algorithms it is going to used and the other endnode can accept it 
>or not. The spec references RFCs 2536 and 3110 to match up signature 
>and hash algorithms. This is probably acceptable.
>
>There are other places where crypto-agility is not all that it might be:
>
>1) There is no negotiation of Diffie-Hellman groups. The responder 
>chooses. This means that if both ends support multiple groups and 
>there is some overlap, the negotiation could still fail if the 
>initiator does not support the responder's default group. As with 
>IKEv1, connections might succeed if initiated from one end but not 
>from the other. If an implementation compensates for this by trying 
>different groups upon retry, the protocol is subject to a downgrade 
>attack where a man-in-the-middle can get the two ends to use a group 
>weaker than one they would both prefer. This would be 
>straightforward (but not trivial) to fix.
>
>2) No key size is negotiated. Use of AES implies use of 128 bit 
>keys. This is not a serious problem - it just means that if support 
>of AES with bigger keys is desired, they must be treated as 
>different encryption algorithms.
>
>3) Fixing the "wired-in" uses of SHA-1 will require a new version 
>number in the protocol, but there is a version downgrade attack. The 
>current spec says that if the version number you get is not 
>supported, you reject it with an unsigned ICMP message. This means 
>two endnodes could likely be tricked by a man-in-the-middle to use 
>the older version of the protocol even if they both support the newer one.
>
>Other Security Concerns (beyond crypto-agility):
>
>Many packets are integrity protected with both an HMAC and a digital 
>signature. This is inefficient because it requires extra public key 
>operations. It is done for the benefit of middle-boxes that don't 
>know the HMAC keys but want to be able to verify the packet contents 
>for updating NAT and firewall configurations. As it stands, the 
>protocol is secure but slow. If the signatures were left out or 
>unverified, certain subtle vulnerabilities are introduced.
>
>There is mandatory support for ESP with HMAC-SHA1 and either Null or 
>AES128CBC encryption. This is mandatory not just in the 
>implementation but also in the configuration. (i.e., as written, the 
>spec says that one of those two suites must be offered in every negotiation).
>
>Assurance that two sessions will always use different session keys 
>is fragile. The keys are derived from the Diffie-Hellman keys and 
>puzzle challenges and responses, all of which can be reused. Perhaps 
>I missed it, but there should probably be more explicit guidance on 
>how to avoid this or explicit nonces should be added.
>
>Around line 1829, the base spec says "All HIP implementations MUST 
>employ a reassembly algorithm that is sufficiently resistant to DoS 
>attacks." This statement is too vague to be useful (and arguably 
>impossible). It should probably be changed to be implementer advice.
>
>Notifications are not acknowledged or protected from replay. Today, 
>notifications are only used for diagnostics, so a third party 
>filtering, duplicating, and reordering them probably can't do 
>substantial damage. It does seem suspicious though.
>
>When doing "opportunistic" HIP negotiation, when node A wants to 
>send to node B and doesn't know whether node B supports HIP, it has 
>three choices: 1) It can hold the first packet to B while it tries 
>to negotiate HIP, and if that fails send the first packet 
>unprotected; 2) It can forward the first packet unprotected and in 
>parallel try to negotiate HIP. If the negotiation succeeds, it can 
>start using the ESP tunnel; or 3) it can not try to negotiate HIP. 
>Each of these mechanisms has problems. The spec should offer some 
>guidance. It's possible this is provided in one of the other HIP documents.
>
>Non-security concerns:
>
>Use of Extended Sequence Numbers is not negotiated; either end can 
>mandate it. If all endpoints are required to support ESNs, it would 
>be simpler to just mandate their use all the time. If not, the 
>negotiation should allow one end to propose their use and the other 
>to accept it.
>
>         --Charlie



_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec