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

[Bernard Aboba <aboba@internaut.com>]

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

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. 



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