[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.