Re: Nat Traversal concern in IKEv2

[Ricky Charlet <rcharlet@speakeasy.net>]

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)
rcharlet@alumni.calpoly.edu
510.324.3163





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

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