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?
Vijay Devarapalli wrote:
> Hi,
>
> On 4/18/09 11:16 AM, "Yoav Nir" wrote:
>
> > Vijay Devarapalli wrote:
> >>
> >> Hello,
> >>
> >> Yoav Nir wrote:
> >>> I see that in section 6 the following:
> >>>
> >>> In such cases, the gateway should send the REDIRECT
> notification
> >>> payload in the final IKE_AUTH response message that
> carries the AUTH
> >>> payload and the traffic selectors. The gateway MUST
> NOT send and the
> >>> client MUST NOT accept a redirect in an earlier
> IKE_AUTH message.
> >>>
> >>> I like that, and that was my position earlier, but wasn't the
> >>> conclusion at San Francisco that the REDIRECT could come
> in either
> >>> the first AUTH response (where we know the ID the client
> is using,
> >>> temporary or not)
> >>> *OR* in the last response?
> >>
> >> The text you quote above refers to the case when the
> gateway decides
> >> to redirect based on the EAP exchange or a as a result of
> interaction
> >> with the AAA server or some external entity (when multiple auth is
> >> used). The redirect is done in the final IKE_AUTH message.
> >>
> >>> When did we decide to not allow it in the first resopnse?
> >>
> >> We allow it. The first paragraph in section 6 and the message
> >> exchange just below it show this.
> >>
> >> Vijay
> >
> > The first paragraph refers to the non-EAP case. The
> paragraph I quoted
> > is the one that refers to the EAP case, and this is the
> case where it
> > makes sense to allow the REDIRECT both in the first and
> last IKE_AUTH
> > responses.
> >
> > The case for the last response is the one that you made: The AAA
> > server may tell the gateway to send the user to another gateway.
> >
> > The case for the first response is a little different. The
> content of
> > the IDi payload tells the gateway to what domain the user
> belongs. "Domain"
> > could map to a specific AAA server, and/or to a specific gateway.
> >
> > Suppose a user connects to gateway-A with the IDi payload
> containing
> > "j...@companyb.com". This is enough to tell the gateway
> that the user
> > should use gateway-B instead - policy says that all
> companyB employees
> > connect to the gateway-B. Or maybe the user is
> "j...@company.it" and
> > all such users should connect to the gateway
> > in Italy. In both cases there is no point in
> authenticating to the local
> > AAA server. The gateway knows immediately to send the user to the
> > appropriate gateway.
> >
> > That is why I think (and I believe that was the conclusion
> in SF) that
> > the REDIRECT may come in both the first and last responses.
>
> Ok, got it. Redirect in the first IKE_AUTH response is always
> allowed, even if there is an EAP exchange. I will clarify it
> in the next revision.
>
> Vijay
>
> >
> > Yoav
Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
