So are we working with the assumption that the gateway (or the AAA server) can
always authenticate any user that connects?
> -----Original Message-----
> From: Yaron Sheffer
> Sent: Monday, April 20, 2009 10:43 AM
> To: Yoav Nir; Vijay Devarapalli
> Cc: IPsecme WG
> Subject: RE: [IPsec] WG Last Call:
> draft-ietf-ipsecme-ikev2-redirect-08
>
> Below.
>
> > -----Original Message-----
> > From: Yoav Nir
> > Sent: Monday, April 20, 2009 10:30
> > To: Vijay Devarapalli
> > Cc: Yaron Sheffer; IPsecme WG
> > Subject: RE: [IPsec] WG Last Call:
> > draft-ietf-ipsecme-ikev2-redirect-08
> >
> > Hi
> >
> > Come to think of it, I'm wondering about something else.
> >
> > Let's suppose that the gateway cannot tell where the user
> should connect.
> > The EAP exchange with the AAA server begins. The AAA server
> realizes
> > that the user name ("jdoe") is not in its database, and the user
> > should be redirected to gateway B.
> >
> > What now? Does it complete the exchange successfully, and
> redirect?
> > Or does it fail the exchange and redirect?
> >
> > I think the obvious answer is to fail the exchange and redirect. I
> > think we should mandate that even with EAP failure, the
> client should
> > honor the REDIRECT.
> >
> > If the gateway authentication fails (the AUTH payload in the first
> > IKE_AUTH response fails to authenticate) then I'm not sure what the
> > right action is. REDIRECT is accepted in an
> unauthenticated INITIAL exchange.
> > Why not, then, in a failed authentication IKE_AUTH exchange?
> >
> [YS] No, failing authentication is different from being
> unauthenticated. The client may have a policy that says that
> it's willing to be redirected at IKE_SA_INIT. But if it
> receives an AUTH value that is explicitly untrusted (say,
> with a revoked certificate), I think it should not act on it.
> Even though a malicious gateway could have responded in the
> first exchange etc.
> etc.
>
> Also note that it may be hard to untangle client
> authentication from gateway authentication, e.g. when using
> symmetric password authentication such as <self plug> EAP-EKE
> </self plug>.
Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
