Hi Pasi, On 6/11/09 3:13 AM, "pasi.ero...@nokia.com" wrote:
> Vijay Devarapalli wrote: > >>> 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? >> >> 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. >> >>> AFAIK, the current text is *not* supposed to allow that -- but >>> 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. > > This is exactly the opposite of my assumption so far, so clearly the > 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 > > 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 > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
