Re: IKE_SA SPI with a changed address
Francis Dupont <Francis.Dupont@enst-bretagne.fr> Tue, 27 May 2003 18:49 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24437 for <ipsec-archive@lists.ietf.org>; Tue, 27 May 2003 14:49:39 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06883 Tue, 27 May 2003 11:42:43 -0400 (EDT)
Message-Id: <200305271547.h4RFlnof044936@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: derenale@polito.it
cc: ipsec@lists.tislabs.com
Subject: Re: IKE_SA SPI with a changed address
In-reply-to: Your message of Tue, 27 May 2003 15:39:54 +0200. <3ED36AAA.1030003@polito.it>
Date: Tue, 27 May 2003 17:47:49 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote: what would happen in IKEv2 if the Initiator and Responder change their IP adresses after have established an IKE_SA? => nothing very good: - NAT traversal includes an optional automatic peer address update for all SAs for a peer which is detected to be behind a NAT. - responses are required to be sent with source/destination address/port reversed, so received requests will be correctly answered. - without an explicit peer address update mechanism (there is a WG agreement to study such a thing in the close future) the best is just to rekey the IKE_SA. It is still possible refernce the SAD with the SPI (the IKE_SA SPI) => yes, this is the role of the SPI and any IKEv2 implementation which uses addresses to look up an IKE_SA should be nuked. found in the CREATE_CHILS_SA header in order to retrieve the parametres to generate a new CHILD_SA? => an IKE_SA rekey will use the addresses IKE runs over so this should work. BTW as the peer addresses are not protected in this case and some attacks can be built using this security flaw, it is possible a future draft will change this... For instance I interpret Jari and Tero's proposal as keeping the peer addresses seen in the first message where they are indirectly protected, note the proposal includes an explicit update mechanism too. Nothing is really decided, only my firm intention to raise a concern if nothing is done about peer address protection before the last call. Thanks Francis.Dupont@enst-bretagne.fr PS: read draft-dupont-transient-pseudonat-01.txt for an example of an attack based on the lack of protection, and RFC 3519 for a defense against a similar problem in Mobile IP which was never claimed to be a security protocol...
- IKE_SA SPI with a changed address Corrado Derenale
- Re: IKE_SA SPI with a changed address Francis Dupont
- Re: IKE_SA SPI with a changed address Corrado Derenale