Tero Kivinen wrote:
Vijay Devarapalli writes:
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 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.
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
