Access-Reject (was RE: Comments on draft-carroll-dynmobileip-cdma -04.txt)

[Avi Lior <avi@bridgewatersystems.com>]

Hi Bernard,

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

But if the server which just received an Authorize-Only packet didn't want
to do the re-authorization requested?

It could send an Access-Reject if we allow the Access-Reject to mean I don't
want to re-authorize.  Full stop.

Failing that, it will have to send an Access-Accept with _all_ the
previously sent authorization attributes.

My concern is that this behaviour while was good enough for simple
deployments, makes it difficult to build new extensions to RADIUS.

I can live with the traditional meaning of Access-Reject, but I do have
issues with how we make it easier and more realistic to develop RADIUS
extnesions.

Also related to this discussion - I ran into this in Pana : pana-pana-07

   "Within separate NAP and ISP authentication, the NAP authentication
   and the ISP authentication are considered completely independent.
   Presence or success of one should not effect the other.  Making a
   network access authorization decision based on the success or failure
   of each authentication is a network policy issue."

If EAP-failure can only be carried in an Access-Reject then if one of 
these enetities rejects the authentication, and the other accepts the 
authentication we can get into a situation where:
NAS receives an Access-Accept
NAS receives an Access-Reject
And the session is allowed to go on.



> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Friday, March 04, 2005 6:00 PM
> To: Alan DeKok
> Cc: radiusext@ops.ietf.org
> Subject: Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> 
> 
> 
> 
> 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/>
> 

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