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 > -----Original Message----- > From: Yaron Sheffer > Sent: 17 March, 2009 13:34 > To: Tero Kivinen; Vijay Devarapalli > Cc: IPsecme WG > Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: 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 > > > -----Original Message----- > > From: Tero Kivinen [mailto:kivi...@iki.fi] > > Sent: Tuesday, March 17, 2009 12:18 > > To: Vijay Devarapalli > > Cc: Yaron Sheffer; IPsecme WG > > Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG > Last Call:draft- > > ietf-ipsecme-ikev2-redirect-04) > > > > 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. > > -- > > kivi...@iki.fi > > > > Scanned by Check Point Total Security Gateway. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
