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

[Bernard Aboba <aboba@internaut.com>]

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

If the RADIUS authentication mechanism doesn't already utilize an 
Access-Challenge, this will not work. 

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

But we can't impose that requirement retroactively. 

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