Re: Comments on draft-carroll-dynmobileip-cdma-04.txt

[Bernard Aboba <aboba@internaut.com>]

On Fri, 4 Mar 2005, Alan DeKok wrote:

> Avi Lior <avi@bridgewatersystems.com> wrote:
> > Access-Reject may not always result in the termination of a session etc...
> >
> > For example, when I am doing authorize only, (Access-Accept with
> > Service-Type = Authorize-Only) the Access-Reject is a rejection of that
> > authorization and not necessarily the rejection of the entire session or
> > service.  Or is it?

I believe it represents a request to terminate the session.  RFC 3576,
Section 1.1 states:

"   To simplify translation between RADIUS and Diameter, a Service-Type
   Attribute with value "Authorize Only" can (optionally) be included
   within a Disconnect-Request or CoA-Request.  Such a Request contains
   only identification attributes.  A NAS supporting the "Authorize
   Only" Service-Type within a Disconnect-Request or CoA-Request
   responds with a NAK containing a Service-Type Attribute with value
   "Authorize Only" and an Error-Cause Attribute with value "Request
   Initiated".  The NAS will then send an Access-Request containing a
   Service-Type Attribute with a value of "Authorize Only".  This usage
   sequence is akin to what occurs in Diameter and so is more easily
   translated by a Diameter/RADIUS gateway."

Note that while a CoA-NAK or Disconnect-NAK indicates no change in state
on the client, once an Access-Request is sent with "Authorize Only" the
semantics of conventional responses applies -- Access-Challenge,
Access-Accept and Access-Reject.

That is, I believe that the NAS interprets an Access-Reject as terminating
the session, regardless of whether the Service-Type=Authorize Only in the
Request.

After all, if the server just wanted to modify the authorizations, it
could respond with an Access-Accept and the new authorizations.  So
sending an Access-Reject is an explicit choice.

>   It's at least a rejection of what they asked for.  For
> Authorize-Only, the semantics of the Access-Reject should clearly be
> that the authorization failed.

It implies that the session is no longer authorized -- therefore it is to
be terminated.

>   e.g. Cisco TACACS-style command authorization.  A request for
> authorization of a command may be "rejected", but the admins session
> will remain active, because no session information was sent in the request.

In RADIUS, the way to accomplish this is to send an Access-Accept with the
same authorizations as was sent before.


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