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

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

Hi Alan,

Just one nit.  You said:

>   For non-location-aware NASes, the RFC's already require 
> implementations to treat unexpected Access-Challenges as 
> Access-Rejects, so this idea would appear to be fail-safe there, too.

It not unexpected Access-Challenges but rather unsupported
Access-Challenge.

Section 4.4 of RFC 2865 states:

"     If the NAS does not support challenge/response, it MUST treat an
      Access-Challenge as though it had received an Access-Reject
      instead."

There is a difference because unexptected seems to tie the Challenge to
the authentication method which is not true.

My understanding is a Challenge is an indication that the Server
requires more information.
 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Saturday, August 27, 2005 1:40 AM
> To: Bernard Aboba
> Cc: radiusext@ops.ietf.org; geopriv@ietf.org
> Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt
> 
> Bernard Aboba <aboba@internaut.com> wrote:
> > If the RADIUS authentication mechanism doesn't already utilize an 
> > Access-Challenge, this will not work.
> 
>   On the other hand, if the NAS is updated to include 
> location information, it may be acceptable to add additional 
> requirements such as this.

Yes.  The scenario in  Geopriv would imply that a NAS stating suppot for
Location is expected to receive a Challenge by a server requiring
location information.  But we can be more clear about this.


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