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