[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Hi,
On Thu, Sep 08, 2005 at 03:41:55PM -0400, Avi Lior wrote:
> Hi Bernard,
>
> > -----Original Message-----
> > From: owner-radiusext@ops.ietf.org
> > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> > Sent: Thursday, September 08, 2005 3:23 PM
> > To: Nelson, David
> > Cc: radiusext@ops.ietf.org
> > Subject: RE: Capabilities (was Re: AW: Review of
> > draft-ietf-geopriv-radius-lo-04.txt )
> >
> > > > The RADIUS server may REQUIRE location in order to evaluate a
> > > > authentication/authorization policy. That policy could
> > state that
> > > > if location is not provided then allow the user on with certain
> > > > constraints.
> >
> > Yes, but the RADIUS server can do this *after* it has
> > indicated that it requires the NAS to provide location
> > information via an Access-Challenge.
> >
> > For example, the NAS initially does not send location
> > information; the RADIUS server sends an Access-Challenge
> > asking for it; the NAS still does not send it, and then the
> > RADIUS server sends an Access-Accept with limited
> > authorizations, instead of an Access-Reject.
>
> Not exactly. If the NAS does not support the above challenge, then it
> will terminate the session.
>
> > In this scenario, there is still no need for "capabilities
> > advertisement" by a NAS.
>
> I still think that there is.
>
> There is also the efficiency aspect. We should only challlenge for
> location if we know that the NAS supports it. Otherwise we are invoking
> an extra transaction for nothing.
Isn't it the case that you only challenge for location if:
1. you didn't already receive location in the access request, because
the NAS or local AAA doesn't trust the proxy chain towards you;
2. you require location in order to determine the level of access you'll
grant;
3. you assume that suddenly the NAS will trust the proxies enough to
include location when challenged?
> It may be fine in simple enterprise solution to have these extra
> transactions. But in large deployements with 50 million subs, this is
> not acceptable.
In such deployments you simply send location in access request. The
local AAA determines whether he trusts the path towards home AAA enough
to forward location. End of story.
> > > In the case of location information, what is the problem
> > with the NAS
> > > always providing any location information that it has to the RADIUS
> > > server?
> >
> > It may be undesirable for the NAS to send location by
> > default. But as argued earlier, this is not a problem -- the
> > RADIUS server can ask for the information.
>
> But it SHOULD only do so when RADIUS Server knows that the NAS supports
> it. A hence we need an advertizement.
But that advertisement is also an extra transaction. What's the home AAA
supposed to do, keep state from separate pseudo-authentications that
include the advertised information for later use? That doesn't sound
like RADIUS, at all.
If I may be blunt for a moment, this issue is so application specific
(not wanting to send an attribute that belongs in an access request the
first time 'round) that it doesn't warrant a generic new capability from
RADIUS.
What's the condition that the NAS uses whether or not to send the
attribute? I mean, it can show its capabilities for all it wants, but
that's information from it, not towards it to help it make its decision.
If it wants to base its decision whether or not to include Location on
whether or not the particular home AAA for that authentication will make
a different decision based on the value Location, then you need two
round trips anyway.
Or would you want the NAS to remember state per home AAA? It won't
learn who the home AAA is from anything in RADIUS, so you can rule that
out if you want to keep the protocol sane.
If you have a RADIUS routing tree containing trusted and untrusted
proxies, and the NAS wants to know, guaranteed, what the full path will
be before doing the actual authentication in order to determine which
attributes it wants to include in its access request, then you need A. a
preauthentication (extra round trip! Just like challenge!) to learn the
path, B. a requirement for each proxy to include its identity and some
credentials in the access accept so that the NAS gets it, C. a guarantee
that a subsequent real authentication will take the exacy same path.
All that just does not seem reasonable. If you don't want to go that
far, then for the NAS to conditionally include Location in its access
request makes no sense, because it doesn't have enough information to
make that decision.
The only alternative model for conditionally sending Location is for
each hop to make the decision whether or not to include Location in
access requests proxied upstream, depending on its level of trust in the
upstream it's about to query.
Combine that with a requirement that a home AAA that uses Location to
base its access level on, MUST echo Location in its access accept, and
that IF a proxy passes it upstream (towards home AAA), it MUST also pass
it downstream (towards NAS).
Then, the NAS can always send Location if it trusts the RADIUS server it
sends the request to. Next, if the NAS doesn't get Location back, it can
conclude that it was not used by the home AAA to base its
accept/reject/access level decision on, and apply a local policy, such
as reject.
That means no challenges, no capability advertising, and a trust model
that's in line with RADIUS.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)78 6136282 http://www.e-advies.nl
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>