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

["David Harrington" <ietfdbh at comcast.net>]

Hi,

I agree with (what I believe to be) Randy's assessment.
VACM has two major parts:
	1) a binding of user to policy/group
	2) the detailed access controls for a group (views,
permissions, etc.)

I think it is fine for RADIUS to provide a user/policy, and for VACM
to translate that into user/groupname even if there are no entries
specifying the views and permissions for the groupname. The
isAccessAllowed() will simply say "no" for any  group for which no
views/permissions are defined.

Nobody is talking about providing agent-supplied defaults that grant
default permissions to an unrecognized groupname.

So installing the user/group binding alone should be fine. No security
hole that I see.

--

As Randy says, ISMS is trying to address user churn, not policy churn.
The configuration of the policy details within the VACM model can be
done using SNMP (or CLI or netconf or startup files or ...). Once
installed, the policy usually remains unchanged. 

The WG will need to deal with mid-session changes to user/policy
assignments and/or policy configuration changes. Maybe we assume
sessions will short-lived enough not to worry about it, but given the
sensitivity of management access, I think we will need to address
this. IIRC, RADIUS servers can specify "interrupts" - hey, client, I
need to revoke the current access-accept and force you to ask me
again, because some things have changed. 

Hopefully, we will not need to deal with a user changing their group's
permissions in a way that denies them access to the view and
permissions tables they are changing ;-)

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Randy Presuhn
> Sent: Wednesday, June 10, 2009 2:41 PM
> To: isms at ietf.org
> Subject: Re: [Isms] Moving into some design / architecture 
> issues ofExtendedVACM
> 
> Hi -
> 
> > From: "Dave Nelson" <d.b.nelson at comcast.net>
> > To: <isms at ietf.org>
> > Sent: Wednesday, June 10, 2009 11:15 AM
> > Subject: [Isms] Moving into some design / architecture 
> issues of ExtendedVACM
> >
> > Randy Presuhn writes...
> > 
> > > (1) the RADIUS authorization data includes the name of the
> > > group of which this user is an authorized member.  (You can
> > > call it a policy if you will, but to break out of chicken--egg
> > > provisioning problems it must be possible to transform it into
> > > a VACM group name without any prior configuration.)
> > 
> > I don't think the "without any prior configuration" part 
> works.  A group
> > name or policy name, whatever we call it, is just short-hand for a
> > potentially long list of policy rules or access control 
> rules.  There's no
> > practical way that the RADIUS server can know what group 
> names exist on the
> > NAS and what access rights they convey.  That has to be 
> pre-arranged by the
> > system administrator.  Similarly, there's no way that the 
> NAS can intuit the
> > correct set of policy rules from the name.  The name, IMHO, 
> must simply be a
> > label and MUST NOT be encoded with actual access control
semantics.
> 
> When I talked about "provisioning" I was referring to the 
> SNMP-manageable
> system.  The whole point of this exercise is to push as much 
> as practical
> (not as much as possible!) into the RADIUS world.  This means that
the
> group access rights *will* have to be pre-configured.  That's ok.
> 
> The point of the ISMS work is to cope with user churn, not 
> policy churn.
> 
> > > (2) if one does not already exist, a corresponding entry 
> is created
> > > in the vacmSecurityToGroupTable.
> > 
> > That, I think, is a potential security hole that you could 
> drive a whole
> > fleet of trucks through.  Creating a table entry with some 
> default, null or
> > wildcard set of access control rules seems like a very bad 
> idea.  It's good
> > for ease-of-use, but bad for security.
> 
> No, look at what the vacmSecurityToGroupTable *does*.
> If there is no access control policy in place for a particular
group,
> then no rights are granted.  I think we very clearly do *NOT* 
> want this
> stuff to be messing with anything in VACM other than the
> vacmSecurityToGroupTable.  Practically by definition, we trust
> the RADIUS server to deliver the correct user->group mapping.
> If we can't make that assumption, this whole exercise is pointless.
>  
> Randy
> 
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>