Subject: Re: [IPsec] Final comments for ikev2-redirect-10

From: <[email-masked]>
Date: Fri, 5 Jun 2009 13:42:47 +0200

Vijay Devarapalli wrote:

> > And having these two cases is more complex than having just one
> > (IKE_SA is not used for any more exchanges). What benefits does
> > this additional complexity (both in spec and in implementation)
> > get us?
> >
> > If nothing, let's just remove it....
> 
> When the AUTH payloads are exchanged and verified, the IKEv2 SA is
> valid.  This seems straightforward. We are not doing anything out of
> the ordinary here by not invalidating the IKEv2 SA just because the
> gateway sent the REDIRECT payload to the client.
>
> I can imagine extensions tomorrow that would let the client convey
> additional information using the IKEv2 SA to the gateway, after the
> gateway had sent a REDIRECT payload to the client.

What do you mean by "valid"? So the client could potentially ignore
the redirect (in the last IKE_AUTH response), and continue using the
IKE_SA (at least for some time) for other exhanges?

AFAIK, the current text is *not* supposed to allow that -- but
it seems it is indeed quite unclear.

Best regards,
Pasi

---

From: Raj Singh <[email-masked]>
Date: Sat, 6 Jun 2009 16:16:32 +0530

Hi Team,

I agree with Pasi.

Regards,
Raj

On Fri, Jun 5, 2009 at 5:12 PM, <[email-masked]> wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Jun 2009 16:29:49 -0700

Hi Pasi,

> IKE_SA (at least for some time) for other exhanges?

Yes, the client can use the IKEv2 SA for other exchanges if it wants to.
When the AUTH payloads have been exchanged and verified, the IKEv2 SA setup
is complete, IMO. I don't think the REDIRECT payload during the IKE_AUTH
exchange should invalidate the IKEv2 SA. So the IKEv2 SA needs to be
explicitly torn down.

> it seems it is indeed quite unclear.

The current text only says the client SHOULD delete the IKEv2 SA with an
Informational message if it receives a REDIRECT payload in the IKE_AUTH
response. Only when EAP is used and the gateway decides to redirect based on
an unauthenticated ID, is the IKEv2 SA not created. The client does not have
to send a message to delete the IKEv2 SA in this case.

At least this has been my assumption so far.

Vijay

---

From: <[email-masked]>
Date: Thu, 11 Jun 2009 12:13:04 +0200

Vijay Devarapalli wrote:

> Yes, the client can use the IKEv2 SA for other exchanges if it wants
> to.  When the AUTH payloads have been exchanged and verified, the
> IKEv2 SA setup is complete, IMO. I don't think the REDIRECT payload
> during the IKE_AUTH exchange should invalidate the IKEv2 SA. So the
> IKEv2 SA needs to be explicitly torn down.
> 
> The current text only says the client SHOULD delete the IKEv2 SA
> with an Informational message if it receives a REDIRECT payload in
> the IKE_AUTH response. Only when EAP is used and the gateway decides
> to redirect based on an unauthenticated ID, is the IKEv2 SA not
> created. The client does not have to send a message to delete the
> IKEv2 SA in this case.
> 

This is exactly the opposite of my assumption so far, so clearly the
draft needs to be clarified one way or another.

Anyone else in the WG care to comment? If the gateway sends REDIRECT
in the last IKE_AUTH response, can the client ignore it and continue
using the IKE_SA?
 
(REDIRECT during IKE_SA_INIT clearly cannot be ignored by the 
client; at least, it cannot continue the IKE negotiation.)

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Jun 2009 13:22:07 +0300

> in the last IKE_AUTH response, can the client ignore it and continue

I did assume that, as the IKE SA was created completely, and it is
usable. Of course client should follow the redirection and delete the
IKE SA after that is finished, but there is nothing which results the
IKE SA to be unusable in that case. 

> client; at least, it cannot continue the IKE negotiation.)

Same goes for the REDIRECT during the IKE_AUTH if redirection is done
based on the unauthenticated identity (i.e. IKE SA is not finished). 
-- 
[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Jun 2009 15:53:54 -0700

Hi Pasi,

> draft needs to be clarified one way or another.

I think the current already describes what I wrote in my previous mail. But
just to make sure it is very explicit, we can make the following text
changes.

Replace

   If the gateway decides to redirect the client during the IKE_AUTH
   exchange, based on the identity presented by the client in the
   IKE_AUTH request message, it prevents the creation of a CHILD SA and
   sends the REDIRECT payload in the IKE_AUTH response.  When the client
   receives the IKE_AUTH response with the REDIRECT payload, it SHOULD
   delete the existing IKEv2 security association with the gateway by
   sending an Informational message with a DELETE payload.  The gateway
   MUST verify the client's AUTH payload before sending the Redirect
   payload, and the client MUST verify the gateway's AUTH payload before
   acting on the Redirect payload.

With

   If the gateway decides to redirect the client during the IKE_AUTH
   exchange, based on the identity presented by the client in the
   IKE_AUTH request message, it prevents the creation of a CHILD SA and
   sends the REDIRECT payload in the IKE_AUTH response.  The gateway
   MUST verify the client's AUTH payload before sending the Redirect
   payload, and the client MUST verify the gateway's AUTH payload before
   acting on the Redirect payload.  Since the AUTH payloads were
   exchanged and successfully verified, the IKEv2 security association
   is valid.  When the client receives the IKE_AUTH response with the
   REDIRECT payload, it SHOULD delete the IKEv2 security association
   with the gateway by sending an Informational message with a DELETE
   payload.

In addition, we already have the following text in section 6

   When EAP is used, the gateway MAY also redirect the client based on
   the unauthenticated identity presented by the client in the first
   IKE_AUTH exchange itself.  Since EAP is used as the authentication
   mechanism, the client does not include AUTH payload to authenticate
   his identity, but the server still MUST include his own AUTH payload,
   and client MUST verify it.  Note that the IKEv2 SA is not created in
   this case and the client does not have to explicitly delete the IKEv2
   SA.

Vijay