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

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

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: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Saturday, August 27, 2005 2:13 AM
> To: Alan DeKok
> Cc: radiusext@ops.ietf.org; geopriv@ietf.org
> 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 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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