Subject: RE: [Isms] Multiple access control models

From: "David B Harrington" <[email-masked]>
Date: Thu, 25 Aug 2005 14:02:00 -0400

Hi Keith,

Thank you for your comments. I agree with them.

I hope I wasn't too subtle. I agree that populating a vacm table from
a security model is **broken** and do not believe it should be done
that way. Some proposals seem to argue for that solution, and while it
is one way to achieve the mapping, it has serious architectural
problems to do it that way. 

Thank you for reinforcing this.

If populating the vacm table is done as part of VACM, where does the
information come from? How do you maintain the cryptographic binding
between the authentication and the authorization? RFC 3411 provides
the model/level/name triplet in the ASIs to provide such binding. But
how does one use that from within VACM to access e.g. RADIUS
attributes for authorization?

dbh 

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]] 
> Sent: Thursday, August 25, 2005 8:55 AM
> To: [email-masked]
> Subject: Re: [Isms] Multiple access control models
> 
> Dave,
> 
> Forwarded message:
> > From: "David B Harrington" <[email-masked]>
> > To: <[email-masked]>
> > Date: Wed, 24 Aug 2005 17:14:53 -0400
> > Subject: [Isms] Multiple access control models
> > 
> > Hi,
> > 
> > I think #1 can be achieved by describing in an ISMS 
> security model how
> > the vacmSecurityToGroupTable gets populated by additional 
> sources, and
> > augmenting the VACM MIB module with source information; 
> this info can
> > also provide the information necessary to delete 
> session-specific rows
> > when the session closes. 
> > 
> > There are two major architectural problems with this 
> approach - it is
> > totally dependent on VACM being the only ACM model the solution
will
> > work with, and any security model that utilizes AAA to populate
the
> > table creates dependencies between specific models in the security
> > subsystem and specific models in the AC subsystem. That is 
> contrary to
> > the RFC3411 architectural philosophy.
> 
> Note that the vacmSecurityToGroupTable is defined in RFC 3415
> (i.e., in VACM, not in *any* security model) and is not referenced
in
> any other SNMPv3 RFC.  Thus, "describing in an ISMS security model
how
> the vacmSecurityToGroupTable gets populated by additional sources"
is
> obviously broken.
> 
> If #1 is achieved by a solution which has problems, then by 
> definition,
> that solution will have problems.  But that's the solution's 
> fault, not
> #1's fault.
> 
> If instead, "how the vacmSecurityToGroupTable gets populated by
> additional sources" is defined as part of VACM, then there are no
such
> problems.
> 
> Also, I think the way in which multiple access control models can
> co-exist is for the particular Access Model (used to resolve an
> "isAccessAllowed" test) to be determined by the securityName, i.e.,
> the Access Control Model is determined by 
> (securityModel,securityName).
> So, for example:
> 
> -- today:           (USM, fred) uses VACM 
>           and       (USM, joe) uses VACM 
> -- add in future:   (TMSM, fred) uses VACM
>           and       (TMSM, joe) uses the XXX Access Control Model
> 
> where the XXX Access Control Model would have its own MIB table
> corresponding to vacmSecurityToGroupTable, and each
> (securityModel,securityName) would either have a row in
> vacmSecurityToGroupTable or in XXX's corresponding table, not in
both.
> keith.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 27 Aug 2005 16:21:02 +0200

Inline

> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of David B Harrington
> Sent: Thursday, August 25, 2005 20:02
> To: 'Keith McCloghrie'; [email-masked]
> Subject: RE: [Isms] Multiple access control models
> 
> 
> Hi Keith,
> 

Well... are you sure?

I know that in many implementations, the VACM tables get populated
from both config files and from possible SNMP SET commands.

If people follow some of the suggestions in the appendices of both
RFC3414 and RFC3415, then they may possibly (at install time) ask
a few questions (in CLI mode I guess) from the installing-person and
based on his/her answers, several entries may get populated in
the VACM and USM tables.

SO there you have 3 ways that vacm tables get populated these days
I think. And currently we do NOT differentiate as to where that
information comes from. So when you read the VACM tables, you
cannot (for sure) say how the entries got created.

So for me it is not so clear yet that we cannot have some SSH/RADIUS
paramters/attributes to cause implied populations of various tables
at session setup. And similarly such entries could be destroyed when
the session gets broken. Of course we need to work that out, but
I would not a priori claim that it is against the architecture.

Maybe I am missing things that you see. If so, pls explain.

> attributes for authorization?

I do not yet know that answer. Because I do not understand the SSH/RADIUS
mechanisms and paramters and attributes well enough yet.

Bert

---

From: "Nelson, David" <[email-masked]>
Date: Mon, 29 Aug 2005 10:37:57 -0400

David Harrington writes...

> Lacking such a concrete proposal, I suggest the new charter focus on
> message security issues, as covered in TMSM and the SSH model, and put
> the authorization issue off until we have a concrete proposal to start
> from.

I disagree.  If this work is out of scope of the charter, we're going to
have a hard time discussing it on the mailing list.  I think our recent
history bears me out here.  So then it becomes a chicken-and-egg issue.
We can't discus authorization because it's not in the charter and we
can't add it to the charter until we have a concrete proposal.  :-(