[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nat Traversal concern in IKEv2



1) it's not a keyed hash...it's just the straight SHA1.
So that part is OK in the spec

2) You are right that it is mysterious to send
the hashes of the addresses instead of the addresses
themselves. It's computationally annoying to compute
the actual addresses (in case a good guy wanted
to do it for logging or debugging),
but not sufficiently computationally difficult to
prevent a bad guy from computing them. Luckily
in practice the good guy doesn't need to know
the exact addresses...they can just hash the
addresses from the IP header and compare them
with the NAT_DETECTION addresses. So it's
not really a problem to do it the way it is.

The theory behind hashing them was to prevent leaking
internal net numbers outside.

We (IKEv2) just copied the design from what was
already implemented for NAT traversal for IKEv1.
In the draft that we copied it acknowledged, in
the "security considerations" section, the weakness
that you mentioned (that a bad guy could compute it).

Radia



"Ricky Charlet" <rcharlet@speakeasy.net> wrote:

>So when sending NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP 
>these payloads contain a SHA1 hash of the IP address and port.
>
>First of all, there is no specification as to what key to use for the 
>SHA1. And this is before the DH has completed. So I see no reasonable 
>choice for how to key this algorithm.
>
>But more worrisome would be that a dictionary attack on all possible IP 
>addresses with 500 and 4500 for ports would reveal the key with fairly 
>light effort. So I perceive a requirement that the key used for this 
>SHA1 in the NAT_DETECTION_* payloads MUST NOT be related in any way to 
>the keys or key generating material used for privacy, integrity and 
>authentication later. This requirement seems onerous.
>
>
>So perhaps we could move the  NAT_DETECTION_SOURCE_IP and 
>NAT_DETECTION_DESTINATION_IP payloads to somewhere in the protected 
>portion of the IKE exchanges and just put the IP/port in the packet 
>directly (not a SHA1 hash).
>
>What do y'all think?
>