Subject: IKE_SA SPI with a changed address

From: Corrado Derenale <[email-masked]>
Date: Tue, 27 May 2003 15:39:54 +0200

Dear all,

what would happen in IKEv2 if the  Initiator and Responder change their
IP adresses after have established an IKE_SA?

It is still possible refernce the SAD with the SPI (the IKE_SA SPI)
found in the CREATE_CHILS_SA header in order to retrieve the parametres
to generate a new CHILD_SA?

Thanks,
	/cdr

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 May 2003 17:47:49 +0200

In your previous mail you wrote:

=> 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.

=> yes, this is the role of the SPI and any IKEv2 implementation
which uses addresses to look up an IKE_SA should be nuked.

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

[email-masked]

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

---

From: Corrado Derenale <[email-masked]>
Date: Thu, 29 May 2003 06:44:23 +0200

Hello,

 >    just to rekey the IKE_SA.

I was against the NAT yet before reading the
draft-dupont-transient-pseudonat-01.txt but now, after that reading I'm
even more against it!

The problem was not for NAT traversal, I hope that with the IPv6 coming
all that problems with NAT will vanish with the NAT itself, but with the
mobile user. I was thinking about keep-up an IKE_SA even if one of the
peers change his network access (change WLAN hot spot) end conseguently
its IP address

 > which uses addresses to look up an IKE_SA should be nuked.

This sounds very good to me.

 > can be built using this security flaw,

I think that you refer to some DoS attacks, because only the
authenticated peers can negotiate a new CHILD_SA and derive new
cryptographic material from the one negotiated and authenticated during
the IKE_SA_INIT. Am I right?

 > it is possible a future draft
 > mechanism too.

That will be very usefull in the mobile/nomadic user scenario.

 > Nothing is really decided, only my firm intention to

:)

Thank you,

/cdr