RE: Capabilities complexity summary

["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: Friday, October 14, 2005 10:56 AM
> To: radiusext@ops.ietf.org
> Subject: Re: Capabilities complexity summary
> 
> >I think that Avi's point is that the desired result is *not* 
> >Access-Reject in the particular scenario he describes: a roaming 
> >consortium which contains none legacy, non-GEOPRIV NASes.  The home 
> >provider would *like* to use GEOPRIV information to authorize its 
> >roaming customers, but doesn't want to risk annoying the customer by 
> >denying any form of access when they happen to be roaming via a 
> >non-home ISP that has legacy NASes.
> 
> It would appear to me that there are multiple ways to address 
> this scenario without additional complexity.  At least four 
> potential solutions come to mind.
> 
> As has been pointed out, this problem would not exist if 
> location information were made available in the 
> Access-Request.  It's not clear to me that the granularity of 
> information required to make authorization decisions 
> represents a legitimate privacy concern.
> 
> It's worth pointing out that RFC 2865 requires that an 
> Access-Request contain at least one NAS identificaiton 
> attribute: NAS-Identifier, NAS-IP-Address, or 
> NAS-IPv6-Address. Therefore some location-relevant 
> information is always present in an Access-Request.   It is 
> fairly routine 
> for providers to include location information in the 
> NAS-Identifier attribute, or to include a PTR RR in the DNS 
> that maps the NAS-IP-Address to a city, state and country.  
> For example, "4.68.127.109" has a PTR RR for 
> "so-3-2-0.gar1.Seattle1.Level3.net".
> 
> Given this, it would seem that course-grained location 
> information (e.g. 
> information at the state/city level) could be included in the 
> Access-Request by default without representing an additional 
> privacy risk.

You would think so but this has been discussed in Geopriv at length and
they felt that knowning the IP address of the NAS does not compromize
the user's location.

Note I am crossposting to Geopriv so that they can respond to your
assertion.

 
> There are also ways to address the issue that do not require 
> sending location in the initial Access-Request.  Since 
> location is not required for initial authorization, an 
> Access-Accept is sent requesting location.  This 
> allows the user to access the  network.   Location information, if 
> available, is then sent within the Accounting-Request and may 
> be stored for the duration of the session.

But what if an Authorization to use the network requires location
information?
 
> Access to location services can then be made available by one 
> of the following mechanisms:
> 
> 1. An application-specific request can then be sent for the 
> location-aware services, which will be granted by a RADIUS 
> server that has access to the location information sent in 
> previous Accounting-Requests.
 
> 2. An RFC 3576 DAC can upgrade the user authorizations once 
> location information is available.

But what if I didn't want to authorize the user if I don't have location
information?
Or what if the NAS does not support 3576?
 
> 3. The original Access-Request can contain a Session-Timeout 
> attribute, allowing re-authentication/re-authorization to 
> occur once the location information has been made available.

All of the above solution ignore the fact that we may need location
information during authorization.  In all the cases the user gets
service while location is being sorted out. As well each method is
complex requiring additional message exchanges and or schemes.

I don't understand why you would suggest these schemes over the
simplicity of  Access-Request with an advertizement and Challenge
mechanism.

NAS
---   Access-Request with indication to support location  Server
 +---------------------------------------------------------->|
 |                                                           |
 |    Acess-Challenge with request of location               |
 |<----------------------------------------------------------|
 |    Access-Request with Location Information               |
 |---------------------------------------------------------->|
 |    Access-Accept  or Access-Reject                        |
 |<----------------------------------------------------------|

Seems to me that the above callflow is pretty darn straightforward vs.
the complexities of your proposals.




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