Subject: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04)

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 5 Mar 2009 16:53:56 -0800

Hello,

There at least three people who think that the IKE_AUTH response
message should itself contain the REDIRECT payload. I went through the
email exchange between Fan and Tero.  There was no new information
that came out of that discussion for me to make this change in the
draft.

Does any one else have an opinion?

Otherwise I suggest the WG chairs to make a call on this.

Both solutions, 1) sending a REDIRECT payload in the IKE_AUTH response
2) sending a NO_ADDITIONAL_SAS in the IKE_AUTH response followed by a
REDIRECT message, would work.

Vijay

2009/2/26 Yaron Sheffer <[email-masked]>:
> <WG chair hat off>
>
> I join Yoav and Fan in supporting this draft, even in its current form. However I also agree with them that the protocol will be cleaner (and subsequently, implementations will be simpler), if we allow redirection in IKE_AUTH, specifically only in the last message of the exchange.
>
> Thanks,
>        Yaron
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> fan zhao
>> Sent: Thursday, February 26, 2009 3:58
>> To: Yoav Nir
>> Cc: IPsecme WG
>> Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
>>
>> Hi,
>>
>> I am ok with moving this draft forward. However, I strongly prefer
>> allowing
>> redirection in the IKE_AUTH as well. As you may know, last week
>> on the 3GPP SA2 meeting, the SA2 working group adopted the solution
>> that uses the IKEv2 signaling message for gateway redirection/reallocation
>> when the mobile terminal performs attach.
>>
>> Sincerely,
>> fan
>>
>>
>>
>> On Wed, Feb 25, 2009 at 5:02 AM, Yoav Nir <[email-masked]> wrote:
>> > I support advancing this.
>> >
>> > I preferred allowing the redirect in IKE_AUTH as well, but it seems like
>> the group consensus went against that.
>> >
>> > One textual comment: since we have section 7 describing a symmetric case
>> (redirect by either peer), section 6.1 should be chagned to reflect that
>> the REDIRECT_SUPPORTED may be in either or both of the request and reply
>> of the Initial exchange, and perhaps a picture can be added to section 7.
>> >
>> > Even without this, the text is clear and useful.
>> >
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]]
>> >> On Behalf Of Yaron Sheffer
>> >> Sent: Wednesday, February 25, 2009 2:34 PM
>> >> To: IPsecme WG
>> >> Subject: Re: [IPsec] WG Last Call:
>> >> draft-ietf-ipsecme-ikev2-redirect-04
>> >>
>> >> This is a reminder that we are having a last call for the
>> >> Redirect document. Even if you support advancing this
>> >> document, but have no other comments, please state your
>> >> opinion on the list.
>> >>
>> >> Thanks,
>> >>       Yaron
>> >>
>> >> > -----Original Message-----
>> >> > From: [email-masked]
>> >> [mailto:[email-masked]] On Behalf
>> >> > Of Yaron Sheffer
>> >> > Sent: Monday, February 16, 2009 11:46
>> >> > To: IPsecme WG
>> >> > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
>> >> >
>> >> > This is a 2 week working group last call for
>> >> draft-ietf-ipsecme-ikev2-
>> >> > redirect-04. The target status for this document is
>> >> Proposed Standard.
>> >> >
>> >> > Please send your comments to the ipsec list by March 2, 2009, as
>> >> > follow- ups to this message.
>> >> >
>> >> > Please clearly indicate the position of any issue in the Internet
>> >> > Draft, and if possible provide alternative text. Please
>> >> also indicate
>> >> > the nature or severity of the error or correction, e.g. major
>> >> > technical, minor technical, nit, so that we can quickly judge the
>> >> > extent of problems with the document.
>> >> >
>> >> > The document can be accessed here:
>> >> > http://tools.ietf.org/html/draft-ietf-
>> >> > ipsecme-ikev2-redirect-04.
>> >> >
>> >> > Please note that one issue is currently open against this draft:
>> >> > http://tools.ietf.org/wg/ipsecme/trac/ticket/82.
>> >> >
>> >> > Thanks,
>> >> >     Yaron
>> >> >
>> >> > Email secured by Check Point
>> >> > _______________________________________________
>> >> > IPsec mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/ipsec
>> >> >
>> >> > Scanned by Check Point Total Security Gateway.
>> >> >
>> >> > Scanned by Check Point Total Security Gateway.
>> >>
>> >> Email secured by Check Point
>> >> _______________________________________________
>> >> IPsec mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/ipsec
>> >>
>> >> Scanned by Check Point Total Security Gateway.
>> >>
>> >> Scanned by Check Point Total Security Gateway.
>> >>
>> > Email secured by Check Point
>> > _______________________________________________
>> > IPsec mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/ipsec
>> >
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>> Scanned by Check Point Total Security Gateway.
>>
>> Scanned by Check Point Total Security Gateway.
>
> Email secured by Check Point
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: <[email-masked]>
Date: Tue, 10 Mar 2009 13:39:25 +0100

Vijay Devarapalli wrote:
> message should itself contain the REDIRECT payload. I went through
> the email exchange between Fan and Tero.  There was no new
> information that came out of that discussion for me to make this
> change in the draft.
> 

I think including REDIRECT in the final IKE_AUTH response would be
simpler and cleaner.

If we assume that redirect based on the initiator identity will be
a somewhat relevant use case, putting REDIRECT in IKE_AUTH response
avoids the slightly weird "what the heck I'm supposed to do know?!" 
state on the client after receiving the IKE_AUTH response but
before seeing the INFORMATIONAL request.

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 11 Mar 2009 14:58:08 +0200

> REDIRECT message, would work.

If you add text allowing REDIRECT with IKE_AUTH, then add also text
explaining how REDIRECT is used with other different extensions,
including EAP and multi auth. I.e. what happens if the server returns
REDIRECT before the first EAP exchange is finished, or what happens if
the server returns REDIRECT after the first EAP has succeeded, but
before the AUTH payload exchange after that, or what happens if server
returns REDIRECT even when the client wants to do another AUTH
negotiation etc.

I.e. if we take following example from the RFC4739:

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                             <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                          N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERTREQ+], [IDr],
                   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) }  -->
                             <--  4. HDR, SK { IDr, [CERT+], AUTH,
                                               EAP(Request) }
      5. HDR, SK { EAP(Response) }  -->
                             <--  6. HDR, SK { EAP(Request) }
      7. HDR, SK { EAP(Response) }  -->
                             <--  8. HDR, SK { EAP(Success) }
      9. HDR, SK { AUTH,
                   N(ANOTHER_AUTH_FOLLOWS) }  -->
                             <--  10. HDR, SK { AUTH }
      11. HDR, SK { IDi }  -->
                             <--  12. HDR, SK { EAP(Request) }
      13. HDR, SK { EAP(Response) }  -->
                             <--  14. HDR, SK { EAP(Request) }
      15. HDR, SK { EAP(Response) }  -->
                             <--  16. HDR, SK { EAP(Success) }
      17. HDR, SK { AUTH }  -->
                             <--  18. HDR, SK { AUTH, SA, TSi, TSr }

In which packets is the REDIRECT allowed. Is it only allowed in the
final 18th message? Is it also allowed in packet 10? Can it be sent
during any time of the EAP exachanges?

This is actually something that is bit unclear already in the RFC4306.

For notification payloads belonging to the IPsec SA (IPCOMP_SUPPORTED,
ADDITIONAL_TS_POSSIBLE, USE_TRANSPORT_MODE,
ESP_TFC_PADDING_NOT_SUPPORTED, NON_FIRST_FRAGMENTS_ALSO), it is quite
logical that the payloads containing SA and TS* payloads are the ones
where they should be in, but for example ESP_TFC_PADDING_NOT_SUPPORTED
and NON_FIRST_FRAGMENTS_ALSO do not contain explicit text listing
where they should be.

For others there are other defined places (i.e.
HTTP_CERT_LOOKUP_SUPPORTED should be in the payload containing
CERTREQ, REKEY_SA should be same packet as SA payload, COOKIE and
NAT_DETECTION_*_IP are used only in IKE_SA_INIT).

For status notifications like INITIAL_CONTACT and SET_WINDOW_SIZE there
is no defined or logical place to send them, so most likely they can
be in any packet during IKE_AUTH exchange (or after that as separate
INFORMATIONAL exchange).

The RFC4478 defines one more status notification i.e. AUTH_LIFETIME
and that is defined to be in last IKE_AUTH message, or as separate
INFORMATIONAL exchange.

MOBIKE (RFC 4555) defines that the new status notifications which can
be in IKE_AUTH (MOBIKE_SUPPORTED and ADDITIONAL_IP*_ADDRESSES) are in
the IKE_AUTH message containing the SA payload.

I assume that REDIRECT is going to be status notification, which means
that the IKE SA is created even when that is returned during IKE_AUTH,
and then the resulting IKE_AUTH still needs to be deleted with
separate INFORMATIONAL exchange containing delete payloads.
-- 
[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 11 Mar 2009 13:14:17 -0800

Hi Tero,

> returns REDIRECT even when the client wants to do another AUTH

The one significant piece of information that the gateway has during the 
IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT exchange, 
is the identity of the client. Some folks want to redirect the client 
based on whatever identity it presents. So if thats they case, the first 
IKE_AUTH response would be used for sending the REDIRECT payload. If the 
gateway wanted to redirect the client because of load conditions, it 
would have done it during the IKE_SA_INIT exchange itself. I don't 
expect the EAP exchange or the multiple auth exchange to trigger a 
redirect. We can make this explicit if needed.

> I.e. if we take following example from the RFC4739:

I expect the REDIRECT payload to appear only in message 4. We can make 
this explicit if we decide to include the REDIRECT payload in the 
IKE_AUTH response.

Vijay

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Mar 2009 14:14:34 +0200

> redirect. We can make this explicit if needed.

I tought someone wanted to do some kind of radius lookup to select
where client is redirected to and in some cases client might not be
sending the ID used for that in the ID payload but might use the EAP
identity request/reply (even though RFC4306 3.16 says SHOULD NOT).

If it will be enough to only see IDi to do redirect, meaning we can
always restrict the REDIRECT to message 4, then it might be even
acceptable to make that change. The main reason I was against having
REDIRECTS in IKE_AUTHs is that there is so many locations where it can
be and testing all possible combinations with all possible
authentication methods and other extensions gets very complicated.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 12 Mar 2009 22:07:18 +0200

We should not do the redirect based on an asserted, unautheticated identity.
Going back to Tero's previous message on this thread, I think we should
allow redirect both in message 10 and 18 (i.e. following both EAP rounds,
and where the EAP state machine is "idle"). The gateway probably needs the
AAA server to tell it where to redirect to, anyway.

In message 10 the gateway still doesn't know that the client wants to
perform secondary authentication, but I propose to ignore this issue for
simplicity.

Thanks,
	Yaron

> Tero Kivinen
> Sent: Thursday, March 12, 2009 14:15
> To: Vijay Devarapalli
> Cc: IPsecme WG; Yoav Nir; [email-masked]
> Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:
> draft-ietf-ipsecme-ikev2-redirect-04)
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Mar 2009 15:11:38 -0700

Hi Yaron, Tero,

We don't really have a protocol extension (EAP, RADIUS or Diameter) for
the AAA server to tell the IKEv2 gateway to redirect the client to
another gateway. 

In addition, if there is an EAP exchange, the true identity of the
client is not revealed to the gateway.

So I am not sure on what basis the gateway would redirect the client in
message #10 and #18 in Tero's email.
http://www.ietf.org/mail-archive/web/ipsec/current/msg04025.html

My proposal is to limit the REDIRECT payload to appear in message #4 (in
the first IKE_AUTH response), based on the identity presented by the
client. And leave EAP scenarios out of scope for this document. If
someone wants the AAA server to redirect the client based on the EAP
exchange, a separate document could be written. And this document can
specify that the REDIRECT message can be sent in message 10. 

Does this sound good?

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 17 Mar 2009 00:40:30 +0200

Hi Vijay,

I don't have the details at hand, but in 3GPP land it is common for the
client to send all sorts of temporary identities, and for the AAA server to
respond to the Packet Data Gateway (that's our gateway) with the client's
"true" identity (IMSI, MSISDN, whatever). Such permanent identity could
serve as the basis for a redirect decision. Do we have people on the list
familiar with these specs?

Thanks,
	Yaron

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2009 0:12
> To: Yaron Sheffer; Tero Kivinen
> Cc: IPsecme WG
> Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-
> ietf-ipsecme-ikev2-redirect-04)
> 
> Hi Yaron, Tero,
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Mar 2009 15:55:53 -0700

> familiar with these specs?

I am aware of these specs. The last EAP message with "Success" from the 
AAA server to the gateway, has the real identity of the client as a 
RADIUS attribute (for example). But we don't have a reference for this 
in the IETF, since RFC 4306 says that there shouldn't be an EAP Identity 
Request/Response exchange.

In RFC 4877, we did mention that the Mobile IPv6 home agent MUST acquire 
the true identity of the mobile node when EAP is used, but left the 
actual mechanism out of scope. Section 8 of RFC 4877 says

    When EAP is used, the identity presented by the mobile node in the
    IDi field may not be the actual identity of the mobile node.  It
    could be set to an identity that is used only for Authentication,
    Authorization, and Accounting (AAA) routing purposes and selecting
    the right EAP method.  It is possible that the actual identity is
    carried inside EAP, invisible to the home agent.  While IKEv2 does
    not allow an EAP Identity Request/Response message exchange, EAP
    methods may exchange identities within themselves.  In this case, the
    home agent MUST acquire the mobile node's identity from the
    corresponding AAA server.  How the home agent acquires the mobile
    node's identity is out of scope for this document.

One option would to be adapt the above text to say that if the client 
had presented a temporary identity to the gateway in the IKE_AUTH 
request message and the gateway does acquire the real identity of the 
client after the EAP exchange, then the gateway can decide to redirect 
based on the true identity. The REDIRECT payload would then be sent in 
the IKE_AUTH response that carries the EAP success message.

Vijay

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Mar 2009 12:17:54 +0200

Vijay Devarapalli writes:
> client. And leave EAP scenarios out of scope for this document.

If others feel this is needed, I am willing to accept that solution,
as it should still be fixed defined location, which means testing it
will be simplier. 

> If someone wants the AAA server to redirect the client based on the
> EAP exchange, a separate document could be written. And this
> document can specify that the REDIRECT message can be sent in
> message 10.

In this case I would rather propose doing the IKE AUTH exchange
completely and then using the INFORMATIONAL exchange to redirect the
client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow it in the
first response IKE_AUTH packet of the exchage, and nowhere else.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 17 Mar 2009 13:33:41 +0200

Hi Tero, Vijay,

I'm all for restricting Redirect to only one fixed defined location. But I
suggest that this location should be the *last* message of IKE_AUTH, whether
you're using EAP or not. This would be message #4 in barebones IKE, message
#18 in Tero's long example. I don't think a security protocol should perform
operations based on asserted, unauthenticated identity.

Thanks,
	Yaron

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2009 12:18
> To: Vijay Devarapalli
> Cc: Yaron Sheffer; IPsecme WG

---

From: "Addepalli Srini-B22160" <[email-masked]>
Date: Tue, 17 Mar 2009 09:40:31 -0700

Hi Vijay,

Sending "REDIRECT" notification upon receiving IKE_SA_INIT request
solves the load issue. 

Sending "REDIRECT" notification as part of first IKE_AUTH response
satisfies selection of VPN responder based on IDi.  Based on my
understanding, even 3GPP IMSI is sent along with IDi.  This information
(typically some portion of it) can be used to figure out the right VPN
Server to redirect. 

Yet times, based on the type of internal network the user is accessing,
VPN server might decide to redirect the user to some other VPN Server to
improve user experience. I guess this case is handled in the draft under
section 'Gateway Initiated Redirect".

Though it seems fine sending "Redirect" notification along with "EAP
SUCCESS" as part of AUTH response, I am wondering the deployment use
cases for this.  If Authentication is successful, then I guess majority
of heavy work is already done by VPN gateway and it is better if it
continues to serve the user. 

Regards
Srini

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Vijay Devarapalli
Sent: Monday, March 16, 2009 3:56 PM
To: Yaron Sheffer
Cc: IPsecme WG; Tero Kivinen
Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG
LastCall:draft-ietf-ipsecme-ikev2-redirect-04)

    methods may exchange identities within themselves.  In this case,
the

Vijay

>>> and where the EAP state machine is "idle"). The gateway probably
needs
>> the
>>>> From: [email-masked] [mailto:[email-masked]] On
Behalf
>> Of
>>>>> The one significant piece of information that the gateway has
during
>> the
>>>>> IKE_AUTH response would be used for sending the REDIRECT payload.
If
>> the

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 18 Mar 2009 11:32:24 -0700

> first response IKE_AUTH packet of the exchage, and nowhere else.

Agree. Here is the text proposal to address this issue.

    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 MUST
    send an empty message as an acknowledgement and delete the IKEv2 SA
    as described above.

         Initiator                    Responder ( VPN GW)
         ---------                    -------------------

     (IP_I:500 -> IP_R:500)
     HDR(A,0), SAi1, KEi, Ni,   -->
     N(REDIRECTED_SUPPORTED)

                                   (IP_R:500 -> IP_I:500)
                               <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ]

     (IP_I:500 -> IP_R:500)
     HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
     [IDr,]AUTH, SAi2, TSi, TSr} -->

                                   (IP_R:500 -> IP_I:500)
                               <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
                                            N[REDIRECT, IP_R/FQDN_R]}

      HDR, SK {} -->

    In case the IKE_AUTH exchange involves EAP authentication as
    described in Section 2.16 of RFC 4306 [2] or multiple authentication
    methods as described in RFC 4739 [6], the IKE_AUTH exchange is more
    complicated.  The identity presented by the client in the first
    IKE_AUTH request might be a temporary one.  In addition, the gateway
    might decide to redirect the client based on the interaction with the
    the AAA server, when EAP authentication is used or the external
    authentication server, when multiple authentication methods are used.
    In such cases, the gateway MUST complete the IKE_AUTH exchange and
    then use the gateway-initiated redirect mechanism, i.e., an
    INFORMATIONAL message with the REDIRECT payload, to redirect the
    client to another gateway.

Pasi, Yaron, Srini, does the above work for you?

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Mar 2009 22:22:45 +0200

Sorry, it doesn't work for me. For a few reasons:
- EAP authentication is the primary use case I see for the Redirect
mechanism. If anything should be solved well, it's EAP authentication.
- The proposal introduces Redirect during IKE_AUTH, which is fine, but then
it reintroduces the complexity of a post-IKE_AUTH Informational. So what's
the benefit? Why not simply define that Redirect can always be sent as part
of the last message of IKE_AUTH, no matter what was the authentication
method.
- And lastly, I think the empty response following the IKE_AUTH response is
redundant. You don't need to acknowledge a response.

Thanks,
	Yaron

> Sent: Wednesday, March 18, 2009 20:32
> To: Tero Kivinen; Yaron Sheffer; [email-masked];
> [email-masked]
> Cc: IPsecme WG
> Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-

---

From: "Addepalli Srini-B22160" <[email-masked]>
Date: Wed, 18 Mar 2009 14:04:24 -0700

My feel is that REDIRECT in response to IKE_SA_INIT, first response of
IKE_AUTH phase (4th message) and Gateway initiated REDIRECT are good
enough If there is a need for REDIRECT after EAP, then I would think
that it is more required along with EAP_SUCCESS than at the end.  If
there are two EAP authentication stages, there may be a requirement to
redirect the Initiator to some other VPN Router based on result from
first EAP authentication. So, my suggestion in regards to EAP is to send
the REDIRECT to Initiator along with EAP-SUCCESS payload.

Thanks
Srini

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Wednesday, March 18, 2009 11:32 AM
To: Tero Kivinen; Yaron Sheffer; [email-masked]; Addepalli
Srini-B22160
Cc: IPsecme WG
Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last
Call:draft-ietf-ipsecme-ikev2-redirect-04)

    sends the REDIRECT payload in the IKE_AUTH response.  When the
client

     (IP_I:500 -> IP_R:500)

                                   (IP_R:500 -> IP_I:500)

     (IP_I:500 -> IP_R:500)

                                   (IP_R:500 -> IP_I:500)

      HDR, SK {} -->

    might decide to redirect the client based on the interaction with
    authentication server, when multiple authentication methods are
used.

Vijay

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Mar 2009 14:05:35 +0200

>     send an empty message as an acknowledgement and delete the IKEv2 SA

That empty message as an acknowledgement is completely against the
generic IKEv2 exchange model. That is unacceptable.

Also the text does not say whether the IKE SA creation succeded or
failed when REDIRECT was sent. As REDIRECT is status notification it
would indicate that IKE SA succeded, and in your example it must have
succeeded, as initiator used it after the IKE_AUTH to send that empty
message.

I think the correct way to do that is to split REDIRECT to two
different notifications, one REDIRECT that is allocated from the
NOTIFY MESSAGES - ERROR TYPES range (0-8191) which indicates that the
IKE SA creation failed and initiator MUST move to new location. This
is the one that should be used in the IKE_SA_INIT and IKE_AUTH phase.
Then there would be another status REDIRECT, which is allocated from
the NOTIFY MESSAGES - STATUS TYPES. This status REDIRECT would be used
in the INFORMATIONAL exchanges, i.e. where it does not cause IKE SA to
be deleted when such notify message is received.

This whole discussion is putting more and more me back to my original
opinion that we should NOT allow redirects during IKE_AUTH.

There is reason to do the redirect during IKE_SA_INIT before doing
Diffie-Hellman.

There is reason to do it after kwowing the identity, but as others has
pointed out in that case it should be done only after the identity has
been proven. If redirection is done only after identity has been
proven, then it can be done as separate INFORMATIONAL exchange after
the IKE_AUTH.

I do not want REDIRECT to be defined so that it can be sent any time
during IKE_AUTH as that exponentially multiple the number of test
cases required for IKE_AUTH tests (i.e. test REDIRECT during all the
possible half a dozen messages using different authentication methods
including multiple authentication etc). 
-- 
[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 19 Mar 2009 10:21:47 -0700

> generic IKEv2 exchange model. That is unacceptable.

Thats an oversight. I combined the IKE_AUTH response with 
NO_ADDITIONAL_SAs payload and the Informational message with REDIRECT 
payload, but didn't remove the ack from the client. This is fixed now.

> succeeded, as initiator used it after the IKE_AUTH to send that empty

The IKEv2 of course succeeded, otherwise the IKE_AUTH exchange would not 
have happened. The client needs to delete the IKEv2 SA after receiving 
the REDIRECT message.

> be deleted when such notify message is received.

I think we should keep this simple, assume that the IKEv2 SA does not 
become invalid because of the REDIRECT message received during the 
IKE_AUTH exchange and have the client delete the IKEv2 SA.

If the REDIRECT is received during the IKE_SA_INIT exchange, then the 
IKEv2 SA is not created.

This is what is described in the document currently.

Vijay

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 20 Mar 2009 14:22:34 +0100

Hmm -- if the redirect is based on the (real) initiator identity, then
I agree that the logical place is the last IKE_AUTH response
(in case of EAP, we might not know the real initiator identity
before that anyway).

But what if the redirect is based on the *responder* identity (the
optional IDr payload in the first IKE_AUTH request)? 

At least 3GPP specs often have multiple responder identities on the
same IP address (and use the IDr in IKE_AUTH request to distinguish
them). In that case, allowing redirect in the first IKE_AUTH
response might make sense.

Best regards,
Pasi 

> From: Yaron Sheffer
> Sent: 17 March, 2009 13:34
> To: Tero Kivinen; Vijay Devarapalli
> Cc: IPsecme WG
> Last Call:draft-ietf-ipsecme-ikev2-redirect-04)
> 
> Hi Tero, Vijay,
> 
> I'm all for restricting Redirect to only one fixed defined
> location. But I suggest that this location should be the *last*
> message of IKE_AUTH, whether you're using EAP or not. This would be
> message #4 in barebones IKE, message #18 in Tero's long example. I
> don't think a security protocol should perform operations based on
> asserted, unauthenticated identity.
> 
> Thanks,
> 	Yaron
>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 20 Mar 2009 19:56:37 +0200

Wait, we're all assuming the Redirect is sent by the responder. In which
case I don't understand what is the meaning of redirecting based on IDr.

Thanks,
	Yaron

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 15:23
> To: Yaron Sheffer; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 20 Mar 2009 20:59:02 +0200

An Initiator MAY send an IDr in the IKE_AUTH request, to tell the peer which of its multiple identities you want to talk to. The 3GPP people like that functionality.

It makes sense for there to be one gateway, you tell it which identity you're looking for, and then it redirects you to the proper gateway for that identity. In that case, it makes no sense to authenticate to that "master" gateway (presumably with EAP-SIM or EAP-AKA)
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Yaron Sheffer [[email-masked]]
Sent: Friday, March 20, 2009 19:56
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG       Last Call:draft-ietf-ipsecme-ikev2-redirect-04)

Thanks,
        Yaron