Subject: RE: [Isms] securityName

From: "Nelson, David" <[email-masked]>
Date: Wed, 27 Jul 2005 14:31:45 -0400

Juergen Schoenwaelder writes...

> I believe that the rest (that is the definition of suitable vacm
views)
> is rather static and on most devices will not change much during the
> lifetime of the device.

I agree that this is the most likely scenario.

> I also believe that a wildcard authenticated
> user via mechanism xyz maps to group abc is going to be rather static
> in most installations and hence it can be configured like all the
> rest of VACM.

Here, I beg to disagree.  My vision of authorization is that access
control levels or policies are assigned to individuals based on their
role within the organization.  While everyone in a particular
organization may authenticate via the same method, they may have
differing roles which require a different access control policy to be
applied. 

> Sure, having the capability to retrieve VACM rules from a trusted AAA
> server would be nice. I doubt, however, this is as crucial for this
> work to succeed than some of the other people here. Anyway, if this
> is crucial, then I think the proper solution is to fix the charter.

Retrieving the actual VACM table entries is not something that ISMS
needs to solve, IMHO.  As you say, these tend to be relatively static,
based on pre-defined roles, such as Help Desk Support vs. Network
Administrator.  I do think that the *binding* of the securityName to
whatever "name" might be used to index locally stored access control
rules should be provided as part of the authentication method.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2005 23:32:07 +0200

> differing roles which require a different access control policy to be

[...]

> rules should be provided as part of the authentication method.

To implement what you are asking for without changing the current SNMP
architecture, one could probably map, within the security model, the
authenticated user identities to security names using an N:1 mapping
function. The VACM security name to group mapping would then likely be
a static 1:1 mapping. In other words, the users "joe" and "fred" would
be mapped to the security name "helpdesk" within the security model
while the VACM security name to group mapping would most likely map
1:1 the "helpdesk" security name to the "helpdesk" VACM group.

Note that with USM, we currently have the N:1 mapping in VACM and the
1:1 mapping within USM. The approach sketched above would use the VACM
N:1 mapping effectivly as a 1:1 mapping and move the real mapping into
the security model.

The community-based security model (RFC 2576) actually supports N:1
mappings of community strings to security names. The intended usage,
as I recall, was to map community strings of the form "joe@bridge1"
and "joe@bridge2" to the security name "joe" and the two contexts
"bridge1" and "bridge2", but there is nothing which prevents you from
mapping the community strings "joe" and "fred" to the security name
"helpdesk" as far as I can tell. The reverse mapping for outgoing
notifications, where the architecture just gives you a security name,
is simply solved by using the first matching user identity.

>From an architectural point of view, I don't really see a problem to
achieve an N:1 mapping of users to roles within a security model - I
believe RFC 2576 already sets a precedence (even though the community
security model has probably not been used in this way so far).

Am I missing something? Dave Harrington, what do you think?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Kaushik Narayan <[email-masked]>
Date: Wed, 27 Jul 2005 14:54:02 -0700

Hi David,

>rules should be provided as part of the authentication method.

I am not sure that we want to use "roles" for the binding since that
is embedded within the access control system and the authorization
model being employed. The user group on the other hand is probably
more appropriate binding.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 28 Jul 2005 02:51:28 -0400

Hi Juergen,

-- requirements for a hack --

What you suggest is equivalent to passing the groupname via the
securityName parameter.
As you point out, for an outgoing request (e.g. notifications, there
needs to be a way to convert from group in the securityName to a
model-specific identity (e.g. user). This is true not only for
notifications but also for requests. You suggest selecting the first
match. Ultimately, this means all members of a group would use the
same identity. 

I'm not sure how authentication would work for a TMSM approach, if the
SSH user used for authentication is in fact a different user,
especially if a CHAP authentication is used to establish a session.
For this reason, the securityName really needs to identify the
principal, not just a group mapping. 

It might be ok to pass both the principal and group(s) in the
securityName. However, if we modify the semantics of securityName,
then all RFC341x references to securityName will subsequently be
wrong.

We could add a groupName(s) parameter to the ASIs, or use global
variables in the form of a user-to-group mapping MIB that can be
accessed by both authentication and access control subsystems. Shared
MIB modules proved problematic in SNMPv2, but if we standardize it and
make the objects definitive such that different security models and
different access control models cannot modify/overload the semantics
of the objects in the table, we should be able to avoid the
side-effects problem of SNMPv2.

I suggest that the cleanest way to do this is to develop a separate
MIB module that mirrors the vacmSecurityToGroupTable fields, and that
may be used by future security models to provide the user-to-group
mapping, and can be used by future access control models to get group
information from those securityModels that support the new MIB. 

We can add an appendix that contains directions for coexistence with
VACM that suggests simply copying the rows from the new MIB into the
vacmSecurityToGroupTable, and ensures fate-sharing between the tables.
Or we could develop an updated VACM that simply uses the new
security-model-and-access-control-model-independent table instead of
the vacmSecurityToGroupTable.

Using a new MIB module allows us to support non-security-model
configuration of the table (e.g. using SNMP or CLI scripting, or a
dynamic mechanism to supplement an authentication mechanism that
doesn't do authorizations) if there are circumstances that warrant
such an approach (such as a requirement for no dependencies on
external security infrastructure), yet allows new security models to
populate the MIB module dynamically.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Wednesday, July 27, 2005 5:32 PM
> To: Nelson, David; Dave Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] securityName
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jul 2005 09:50:07 +0200

> match. Ultimately, this means all members of a group would use the

I did not say that selecting the first one is the solution - I just
mentioned that this is what the communiy-based security model does.
If the user identity to security name mapping resides on an AAA
server, then there might be other mappings that are more suitable.
But yes, reversing an N:1 mapping has its issues.

> principal, not just a group mapping. 

Not sure I understand your concerns here. You authenticate a user and
an AAA server provides a user to security name mapping.

> then all RFC341x references to securityName will subsequently be

Why? Does RFC 341x say somewhere that the security name must directly
identify a principal?

> side-effects problem of SNMPv2.

But both options are in fact changing the architectural interfaces.

> populate the MIB module dynamically.

My understanding is that we have the desired N:1 mapping table in VACM
and the only concern that I heard hear on this list is that people do
not want to touch this table when they add/remove users and they
prefer that this mapping actually comes from say an AAA server. How
does introducing another table solve that problem?

I see these options:

a) provide a mechanism to retrieve (at least parts of a) VACM configuration
   from an AAA server (not in our charter)

b) do a N:1 mapping from user identities into security names in the
   ISMS security model (rather than doing a 1:1 mapping like USM)

c) generally change the SNMP architecture providing new or extended
   ASIs to actually make this mapping something between the security
   model and the access control model (not in our charter)

There are now technical pros and cons for all these options and there
are process (charter) issues to consider. There was also the other
option (not sure it really counts as an option):

d) provide a wildcard mapping extension to VACM which can be exploited
   to map all security name with the same security level and security
   model together into a vacm group (works only on simple setups where
   you basically do not distinguish between different MIB views for
   authenticated users - but perhaps this is a low hanging fruit that
   covers most existing VACM configurations anyway)

Any other options to consider which I forgot to list?

/js

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 28 Jul 2005 18:42:57 +0200

Juergen

To clarify, when you say security level, I take it you mean

3.4.3.  securityLevel
      -  noAuthNoPriv
      -  authNoPriv
      -  authPriv
As you say, it is just about feasible.  I see current proprietary management
systems with three levels, for general user, configuration change and system
change (software, security, passwords) which maps ok (although a spare would be
nice).  But I seem to recall a post from Sharon saying seven would be needed.

Tom Petch

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 28 Jul 2005 11:06:34 -0700

Hi Juergen,

>1:1 the "helpdesk" security name to the "helpdesk" VACM group.

I think this approach would be counter productive since we overload the
notion of a securityName to identify not the client principal but his "role".
I think it would be a lot cleaner if we were to allow group mapping to
happen external to the access control system.

regards,
   kaushk!

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jul 2005 20:19:56 +0200

> To clarify, when you say security level, I take it you mean

Yes, I mean security level as defined in the SNMPv3 architecture.

> As you say, it is just about feasible.  I see current proprietary
> management systems with three levels, for general user,
> configuration change and system change (software, security,
> passwords) which maps ok (although a spare would be nice).  But I
> seem to recall a post from Sharon saying seven would be needed.

And here is a misunderstanding I think. The security level describes
the amount of protection on the wire. You seem to assume that the
security level somehow implies what someone is allowed to do, which
would be an authorization level, something that does not exist in
SNMPv3 since this is actually handled by the access control model.

What you descibe above sounds like a typical CLI course grain access
control model where the device implementor is basically in charge to
ensure that access control is properly enforced for the N defined
authorization levels (usually hard-wired for the different objects).

Since we are not chartered to discuss the merits of VACM nor not
VACM I better suppress any comments on the merits and pitfalls of
these two different approaches.

/js

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 29 Jul 2005 09:23:10 +0200

Juergen

I am confused.

Rereading my previous e-mail, I do mean what I said.  I believe I understand the
difference between security level on the wire and authorisation/access control
and use them in the same sense as you.. I have read and still read your option
d) as proposing that securityLevel on the wire should
be used to determine the group name and hence the access control in vacm.

So consider that option e) and please give me an alternative explanation for
what you described as

"d) provide a wildcard mapping extension to VACM which can be exploited
   to map                       all security name with the same
   security level              and security  model together
   into a vacm group      (works only on simple setups where

   you basically do not distinguish between different MIB views for
   authenticated users - but perhaps this is a low hanging fruit that
   covers most existing VACM configurations anyway)"

which I read as a proposal to map (one of three) security level into a (one of
three) vacm group but which you say does not:-(

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 31 Jul 2005 18:04:52 +0200

On Fri, Jul 29, 2005 at 09:23:10AM +0200, Tom Petch wrote:
> Juergen
> 
> I am confused.
> 
> Rereading my previous e-mail, I do mean what I said.  I believe I
> understand the difference between security level on the wire and
> authorisation/access control and use them in the same sense as 
> you.. I have read and still read your option d) as proposing that 
> securityLevel on the wire should be used to determine the group
> name and hence the access control in vacm.
> 
> which I read as a proposal to map (one of three) security level into a
> (one of three) vacm group but which you say does not:-(

Sorry, I did not see the context of your statement. So yes, d == e
(and I am not sure this really is an option).

/js