Re: [Isms] Moving into some design/architectureissuesofExtendedVACM

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> Cc: <isms at ietf.org>
> Sent: Thursday, June 11, 2009 3:57 PM
> Subject: Re: [Isms] Moving into some design/architectureissuesofExtendedVACM
>
> On Thu, Jun 11, 2009 at 10:55:09PM +0200, Randy Presuhn wrote:
>  
> > > But the minimum we have to do is to specify what the RADIUS client
> > > does if the creation fails.
> > 
> > Yup, and I think the answer is "nothing."  There's no channel for
> > signalling back the failure.  From an implementation perspective,
> > if there aren't resources to create/update a vacmSecurityToGroupEntry,
> > then I'd be wary of trying to do things like queue up special-purpose
> > notifications for the security administrator, who'd be the one who'd have
> > to figure out a recovery strategy.
> 
> I am talking in general about a failure to install the requested
> policy / name to group mapping - not just about the resource shortage
> case.
> 
> 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?

Yes, since that's exactly what would happen if another security
administrator tried to create/update the entry and failed.

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

I see no value whatsoever to doing so.  If the system is already configured
to treat that user as a member of a particular group, and (for whatever
reason) is unable to honor the group membership asserted by RADIUS,
then it makes perfect sense for it to use the policy it already has in
place.  After all, that's exactly what it would do today.

> 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). If this is the case, simply ignoring a failure to
> install the requested policy sounds kind of wrong.

I think in our case it makes more sense to view this information as being
provided by a security administrator, since it is being used to update
the access control configuration of the system, and is *not* directly an
access-allowed/access-denied decision.
 
> PS: Does the RADIUS client have the "rights" to modify any existing
>     writable matching table entries?

If we take the stance that this should be treated like an update from a
security administrator, then yes, when vacmSecurityToGroupStorageType
is not 'readOnly', it would need to be able to update vacmGroupName and
vacmSecurityToGroupStatus (if not already 'active').


> Will it revert the changes when
>     the session dies?

Again, if we take as our model that the RADIUS information is configuration
data,  treated as if coming from an authorized security administrator, then
it does not make sense to revert the changes.

Randy