Re: [Technical Errata Reported] RFC5176 (2012)

[Avi Lior <avi@bridgewatersystems.com>]

i agree with you David,  see inline...

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

>> So it is 5580 that actually uses it in Access-Reject.
> 
> That usage is as follows:
> 
>   o  If the RADIUS server does not receive the requested information in
>      response to the Access-Challenge (including the Requested-
>      Location-Info Attribute), then the RADIUS server may respond with
>      an Access-Reject message with an Error-Cause Attribute (including
>      the "Location-Info-Required" value).
> 
> It constitutes a "poor-man's" form of capabilities negotiations, in that it
> signals that needed information that is missing from an
> Authentication-Request.  It is not use to signal a limited or alternate form
> of service to be provided as a result of the Access-Reject, however.  That
> would violate the "no means no" doctrine.

Understood.

> 
>> Given the above the situation is very grim.  Error-Cause is not the right
>> attribute.
> 
> I think it is not the right attribute.  In fact I think there is no
> attribute that *can* be use to change an Access-Reject into a modified,
> limited or alternate form of Access-Accept.
Right.
> 
>> In a situation where the AAA Server doesnt not intend to allow for access
>> to the service provided - an access-accept is should not be used.  Access-
>> Reject does not allow us to use even a Vendor Specific Attribute (26) so
>> we cant communicate the reason for rejection.
> 
> Correct.
> 
>> The only solution is to use Access-Accept with a code that indicates that
>> no service should be provided.  This is a terrible solution/situation.
> 
> Well, if *no* service is to be provided, then why isn't an Access-Reject
> appropriate?  

When I meant no service - it is not the service that was requested.

> OTOH, if what's really happening is that the RADIUS server is
> provisioning an alternate form of service, maybe even one that the NAS is
> not in a position to provide, why not send an Access-Accept including a set
> of attributes that provision the allowed service and let the NAS decide if
> it can provide that service, and if not how it wants to signal to the client
> that the alternate (allowed) service is not achievable on that connection?

yes.  But the danger here is that the NAS may not understand the attributes that are offering the alternate (limiting) service and would interpret the response as a full access-accept.

For this situation to work correctly the sender of the Access-Accept would have to know whether or not the Receiver has to means to recognize the response correctly.  This could be provided by a capability exchange for example.

If the NAS did not indicate support for the new attributes that an Access-Reject may be the correct response.

> 
> 


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