[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nat Traversal concern in IKEv2
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
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
(formerly with Sonicwall and before that formerly with Redcreek)
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).
> "Ricky Charlet" <email@example.com> wrote:
>> So when sending NAT_DETECTION_SOURCE_IP or
>> 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
>> 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?