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 protected] [[email protected]] On Behalf Of Yaron Sheffer [[email protected]] Sent: Friday, March 20, 2009 19:56 To: [email protected]; [email protected]; [email protected] Cc: [email protected] Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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 > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Friday, March 20, 2009 15:23 > To: Yaron Sheffer; [email protected]; [email protected] > Cc: [email protected] > Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft- > ietf-ipsecme-ikev2-redirect-04) > > 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:[email protected]] > > > 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. > > > -- > > > [email protected] > > > > > > Scanned by Check Point Total Security Gateway. > > > > Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. Email secured by Check Point _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
