Re: peer address protection

Charlie_Kaufman@notesdev.ibm.com Thu, 09 January 2003 15:33 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h09FXco23252; Thu, 9 Jan 2003 07:33:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07326 Thu, 9 Jan 2003 10:04:40 -0500 (EST)
From: Charlie_Kaufman@notesdev.ibm.com
In-Reply-To: <200301071741.h07HfNof046164@givry.rennes.enst-bretagne.fr>
Subject: Re: peer address protection
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002
Message-ID: <OF1E3C0226.65774115-ON85256CA9.0051C38D-85256CA9.005256F5@notesdev.ibm.com>
Date: Thu, 09 Jan 2003 09:59:24 -0500
X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 01/09/2003 10:06:46 AM
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk




Francis.Dupont@enst-bretagne.fr wrote:

> Peer addresses (as defined in draft-ietf-ipsec-pki-profile-01.txt) are
> not protected in IKE (not always in IKEv1, not at all in IKEv2 with
> revised identities). This opens a security hole, not against IKE itself,
> but using IKE to divert traffic (i.e., not a property we'd like for a
> security protocol).
>  The I-D editor has just announced the new version of my I-D about
> the transient pseudo-NAT attack and its application to Mobile IPv4
> (documented in the security section of the NAT traversal extension)
> and to IKE... Its name is draft-dupont-transient-pseudonat-01.txt.
>  I believe we should fix the issue (the security flaw) for the next
> version of the IKEv2 document.

Please take a look at draft-ietf-ipsec-ikev2-04.txt. As part of NAT
traversal, there is a new mechanism for sending protected peer addresses.
It does not, however, specify any algorithms for using that information
to protect against the kinds of attacks you're worried about. I
haven't read your I-D (but I will). I believe the really hard problem
for us to solve is how to protect against pseudo-NAT attacks while
supporting real NATs given that NATs are generally not capable of
providing any cryptographic authentication.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).