Subject: Re: Nat Traversal concern in IKEv2

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Thu, 19 Jun 2003 21:13:29 -0400

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" <[email-masked]> 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?
>

---

From: Ricky Charlet <[email-masked]>
Date: Thu, 19 Jun 2003 20:22:33 -0700

Well this was pretty silly of me then. I had gotten so used to using 
SHA1 in a HMAC context that I forgot it was an H. My apologies for the 
confusion.

But still, if there is a concern about leaking identities, then why not 
move the NAT_DETECTION payloads into the protected part of the 
exchange? The knowledge that we (or our peer) are behind a NAT is not 
needed until we attempt to send and/or receive ESP or AH.

I guess that one (very good) reason not to change this, is that this is 
too late in the process to change something this insignificant. I don't 
have a strong opinion about this either way since I got my initial 
confusion corrected.

---
Ricky Charlet
(formerly with Sonicwall and before that formerly with Redcreek)
[email-masked]
510.324.3163

On Thursday, June 19, 2003, at 06:13 PM, Radia Perlman - Boston Center