Re: Review of draft-ietf-geopriv-radius-lo-04.txt

["Alan DeKok" <aland@ox.org>]

Bernard Aboba <aboba@internaut.com> wrote:
> 1) The RADIUS server REQUIRES the NAS to provide location
> in the Access-Request (e.g. it implements location-based access control).
> In this case the RADIUS server can send an Access-Reject with an 
> Error-Cause attribute with a value of "Location Required". 

  Can there be multiple Error-Causes?  That would seem to be efficient.

  Also, this use of Access-Reject is closer to the semantics for
Access-Challenge.  I would prefer to use that, instead.  i.e. An
Access-Request MAY be responded to with an Access-Challenge containing
Error-Cause, For authentication methods that normally expect
request/ack, receipt of an Access-Challenge would indicate that they
add the relevant data, and re-send the Access-Request without
prompting the user for more information.

  That requirement would make it clear that the NAS *does* have to
maintain state, but that it does not have to tell the user about the
re-authentication.

> Alternatively if the authentication mechanism (e.g. EAP) supports 
> Access-Challenges, the RADIUS server can place a "Send 
> location" attribute in the Challenge.  On receiving either of these 
> indications, the NAS includes location attributes in the Access-Request. 
> Note that the server's decision is not influenced by whether the client 
> has advertised location support, only by the inclusion of location 
> attributes in the Access-Request.

  Yes.

> 2) The RADIUS server does not require location in the Access-Request,
...

  Yes.

> Am I missing something, or is the problem really this simple? 

  It would appear so.

  Alan DeKok.

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