RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

["Avi Lior" <avi@bridgewatersystems.com>]

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.

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 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.

> > If the issue is that the User wants the NAS to only 
> disclose location 
> > to RADIUS servers that he trusts, I think there is a lot of heavy 
> > lifting to do.
> 
> I'd argue that the only RADIUS server that a user can trust 
> is its home RADIUS server. There can be no notion of a user 
> trusting intermediate proxies.  

I agree with that.
 
> --
> 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/>
> 

--
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/>