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

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

Hi Bernard,
 
Bernard wrote:

> Based on this discussion, I think it is even simpler than I 
> had thought -- Access-Challenge, Error-Cause and a "send 
> location" attribute appear to solve the problem with no need 
> for any capability advertisements. 

I still think you are missing something.  I still need to know whether
the capability is supported.  It may impact my policy decision.  I may
have a policy that allows certain services to be provided only if
location is provided.  Knowing that a NAS cant support location allows
me to send an Accept with only those services that do not require
location information to be provided. 

And blindly requesting for location information (as you propose) I run
the risk of having a rejection by getting to a NAS that does not support
Challenge in the first place. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, August 27, 2005 2:13 AM
> To: Alan DeKok
> Cc: [email-masked]; [email-masked]
> Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt
> 
> >   Can there be multiple Error-Causes?  That would seem to 
> be efficient.
> 
> Off the top of my head, I don't see why not.  RFC 3576 allows 
> 0+ Error-Cause attributes in a NAK, so I'd assume that it 
> also would be allowed in an Access-Challenge or Access-Reject. 
> 
> > 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.
> 
> Where an Access-Challenge is expected, this works.  Where it 
> is unexpected, RFC 2865 Section 4.4 requires that the NAS 
> treat the Access-Challenge as an Access-Reject. 
> 
> >   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.
> 
> I think that it's possible to make this work without changing 
> existing Access-Challenge behavior.  If an Access-Challenge 
> would be sent anyway, a "send location" attribute can be 
> piggybacked on it.  If it is unexpected, the Access-Challenge 
> will be treated as an Access-Reject and re-authentication 
> will be required. 
> 
> > > Am I missing something, or is the problem really this simple? 
> > 
> >   It would appear so.
> 
 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 27 Aug 2005 03:54:56 -0700 (PDT)

> Challenge in the first place. 

The only reason a RADIUS server will need to send an Access-Challenge is 
if it *requires* location and it is not present.  In that case, the RADIUS 
server cannot allow access if location isn't provided.  

If the RADIUS server doesn't require location, then it can just request 
location in the Access-Accept.  If it gets it, great.  If not, it is 
willing to live with out it. 

In either case (mandatory or optional), capability advertisement by the 
NAS is irrelevant.