Re: [Technical Errata Reported] RFC5176 (2012)

[Avi Lior <avi@bridgewatersystems.com>]

The summary for this discussion is:

-Access-Accept should be used as defined by 5080.
-However there are dangers - which a capability negotiation could have solved.
-Error-Cause is for protocol errors mostly.  Having said that it does have a an Error Code 501 "Administratively Prohibited" which would be a stretch to call a protocol error.

Regarding the Errata. I still think it should be issued because it is not that obvious where Error-Cause can be included.  But we know.

-IANA should have clear instruction on how to extend Error-Cause.  Currently i dont think they do.

-Unless i am missing something, except for values 0-199 and 300-399, the RFCs do not reserve unused values for Error-Cause -- and then we wonder why people just grab numbers.

-It would have been useful to allow VSA to be included in Access-Reject. So at least an SDO can return an Error-Cause of their own or even Authorization-Failure-Cause or Authentication-Failure-Cause instead of hacking the Reply-Message attribute.




On 26-01-2010, at 21:51 , Dave Nelson wrote:

>> There are just too many unknowns around NAS behavior to over-load
>> Access-Accept.
> 
> I don't think anyone has suggested over-loading Access-Accept.  If use as
> originally intended, to provision service, it works just fine, at least if
> the service is described in the Service-Type attribute.
> 
> After all, RADIUS is not about answering authorization questions from NASes,
> it's about identifying users and *telling* them what service they get, based
> on their identity, and contextual hints from the NAS.
> 
> 


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