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

["Alan DeKok" <aland@ox.org>]

Bernard Aboba <aboba@internaut.com> wrote:
> 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.

  I agree.  However, once an extension like Authorize-Only is added to
a protocol, it will be (ab)used in ways the designers never intended.

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

  According to RFC 3576, yes.  Implementations which are not using RFC
3576 CoA requests may still choose to use Authorize-Only.  In that
case, any meaning is implementation-defined.

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

  i.e. You're saying that the NAS re-sends an Access-Request for the
"session", when the administrator types a new command, and obtains an
Access-Accept with authorization for that "session".  I'm not sure why
this would be useful.  If an Access-Accept contains full authorization
for all administrator activities, there would be no need to any later
Access-Request to obtain additional authorization for that session.
The NAS would already have the complete list.

  However, a complete list of commands the admin is authorized to run
may be large.  That was the reason the individual commands were
dynamically authorized in TACACS+.  Such a list could also not fit
into one RADIUS packet, making it more useful to dynamically authorize
each command.

  In that case, the following two questions are disjoint:

  1) Is this administrator permitted to log in to this box?
  2) Is this administrator permitted to run this command?

  While (1) is a pre-requisite for (2) to be asked, I don't see why a
"no" answer to (2) would mean that the administrator is logged off.  I
can run "rm /etc/passwd" as a normal user without the system logging
me off.

  In this context, question (2) can be thought of as requesting a new
session, with new authorization parameters.  The two sessions are
logically separate, and can be treated that way by the NAS.
e.g. Using RADIUS authentiction for Unix logins.  I can log in as
myself, "su" to root, and get an Access-Reject for that "su" login
request.  But my personal session isn't logged off.  This is the exact
model used for Cisco TACACS+ command authentication.

  The concept of one user requesting two independent sessions from a
RADIUS client is not one which is widely used in RADIUS.  But I don't
see how the protocol forbids it.

  Alan DeKok.

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