Issue 69 (was Re: Access-Reject)

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

Avi Lior <avi@bridgewatersystems.com> wrote:
> Here is an simple example.  If an already authenticated user wants to
> establish a new call VoIP call etc... The NAS can then Authorize that call
> by issueing an Access-Request Authorize-Only.  No need to autenticate again
> right?

  Some comments, which are conceptual and not RADIUS-specific.

  1) The authorization request MUST be tied to a previous
authentication request.  If it is not, then we have the problem of
un-authenticated users being authorized to do something.  Users may
authenticate multiple sessions, so each authorization request MUST be
tied to a particular session, and not to a user.

  2) The authorization request itself MUST be authenticated.  This is
Bernard's comment in the issues page about using Message-Authenticator.

  3) The context of the authorization request MUST be interpreted as
what is being requested, and not any previous authentication or
authorization request.  e.g. User X authenticates, is authorized to do
X, Y, and Z.  He later requests authorization to do Q.  Any "yes/no"
response MUST be interpreted as meaning "yes/no" to do Q.  It MUST NOT
apply to the previously granted authorization.


  My reading of the above requirements in the light of RADIUS means
that implementing Authorize-Only semantics in Access-Requests may be
problematic.

  RADIUS does not have the concept of "authenticated sessions", so we
may use (for example) the "Class" attribute, as it's already used to
tie Accounting-Requests to previous Access-Requests.  Using Class to
tie Access-Requests together may have deployment issues.

  The Message-Authenticator attribute can address requirement (2).

  Requirement (3) means that the RADIUS server MAY have to keep track
of not only all user sessions, but all authorization data for all user
sessions.  Otherwise, if (in the above example) the user did not
originally request authorization to do "Q", he could later request it,
and possibly gain unintended authorization.  That is, the context of
authorization which permits/denies "Q" is the authorization to do "X,
Y, and Z", which itself may be time, resource, and location-dependent.


  So to answer Bernard's question: Yes, using Authorize-Only in an
Access-Request outside of the context of CoA-Request and
DisconnectRequest can be valid.  But we should highlight the issues,
so that any deployment is designed correctly.

  The Cisco TACACS+ command authorization example I discussed
previously is a narrowly scoped problem which can fit within the above
requirements.  As for others, I'm not sure.

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