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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
