RE: [Technical Errata Reported] RFC5176 (2012)

["Dave Nelson" <d.b.nelson@comcast.net>]

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

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

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



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