Subject: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt

From: "Avi Lior" <[email-masked]>
Date: Sat, 27 Aug 2005 03:17:58 -0400

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Saturday, August 27, 2005 1:40 AM
> To: Bernard Aboba
> Cc: [email-masked]; [email-masked]
> Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt
> 
> Bernard Aboba <[email-masked]> 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.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 31 Aug 2005 13:03:00 -0400

> the authentication method which is not true.

  PAP & CHAP don't currently use Access-Challenge, which is why I used
the term "unexpected".  The same NAS may support Access-Challenge for one authentication protocol, but not another.

  But "unsupported" is the more correct term.

> requires more information.

  Yes.  That makes it the ideal place to put capabilities exchange.

  Alan DeKok.