Re: [Isms] Moving into some design/architecture issues of ExtendedVACM

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

Juergen Schoenwaelder writes...

> Suppose the RADIUS server tells the RADIUS client that "joe" using
> "TSM" is authorized for the management policy "restricted" but the
> attempt of the RADIUS client to install this policy fails since for
> some reason (e.g., there exists an entry for "joe" using "TSM" using
> group "poweruser" that for whatever reason can't be modified). Is it
> OK to ignore the failure and to let "joe" now use the "poweruser"
> rights?

I guess the question can be rephrased to ask whether you really want two
different repositories (the RADIUS server's database and the locally stored
VACM MIB entries) to be equally authoritative for authorization, especially
when they conflict.  I would think, in general, that's not a good idea.

In a carefully managed environment, many things are acceptable that would
not be acceptable in the more general case.  For example, if you assume that
the "joe" that RADIUS has authenticated is the same "joe" that is found
configured in the VACM MIB Module, it *might* in some circumstances be OK to
let the VACM data take precedence over the RADIUS data.  OTOH, if it's
possible that there are two *different* users with the username "joe" one in
RADIUS and another in VACM, then it may be a very bad idea.

Generally speaking when a feature is taken under RADIUS control, RADIUS is
considered to be the primary authority, and local data does not override the
access provisioned by RADIUS.  I feel quite uncomfortable with proposing
that behavior for use with the VACM extension.  Local data can use used with
RADIUS, but typically only in a fall-back use case, for example when RADIUS
is unavailable because of network problems or a server crash.

> Or should the RADIUS client do something like deny
> authentication of joe's session if it can't install the management
> policy, or kill joe's session if it is already there (likely a
> challenge to write down due to the architectural model we have, but
> likely easy to implement ;-).

With the caveat that this behavior could be overridden by local policy
configuration, this is exactly the behavior that I would recommend. 

Let me quote a portion of Section 6.3 of
draft-ietf-radext-management-authorization-07.txt, now in the RFC Editor
Queue:

   The management access policy named in this attribute, received in an
   Access-Accept packet, MUST be applied to the session authorized by
   the Access-Accept.  If the NAS supports this attribute, but the
   policy name is unknown, or if the RADIUS client is able to determine
   that the policy rules are incorrectly formatted, the NAS MUST treat
   the Access-Accept packet as if it had been an Access-Reject.

This indicates to me that when present in RADIUS authorization information
the policy (group name) specified in the Management-Policy-ID attribute MUST
be applied faithfully, or access MUST be rejected.

> My understanding is that RADIUS decisions are of the kind "here is
> exactly what you do or you deny service" (RADIUS folks, please correct
> me if I am wrong).

You are correct.

> If this is the case, simply ignoring a failure to install the 
> requested policy sounds kind of wrong.

Agreed.

> PS: Does the RADIUS client have the "rights" to modify any existing
>     writable matching table entries? Will it revert the changes when
>     the session dies?

I think it needs to revert, yes.

While we talk loosely of the RADIUS authorization information being used to
update the VACM MIB Module in the same sense that the SNMP engine would do
in response to an SNMP SET, we may be taking this too literally.  I think
that the RADIUS information kept by the VACM Extension should be transient,
with a lifetime limited to that of the secure transport session.