Subject: securityName/groupName [was RE: [Isms] ISMS charter discussion]

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 19 Aug 2005 18:39:35 +0200

Inline

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]
> Sent: Friday, August 19, 2005 16:59
> To: Wijnen, Bert (Bert); Juergen Quittek; [email-masked]
> Subject: RE: [Isms] ISMS charter discussion
> 
> 
> Bert Wijnen writes...
> 
> > We do not have the concept of "securityGroup" in SNMPv3 ...
> 
> So I've clearly picked up an incorrect term from another thread in on
> this list.
> 
That is OK David.
I just wanted to be sure we are not talking about some new form
of groupName but about the groupName as currently known in VACM.

> > In SNMP we control access based on the groupName or the "who"
> > (among other things). See RFC3415 page 8.
> 
> I believe I should have said groupName.  The intent was to re-use an
> existing mechanism.
> 
OK, good to hear.

> > In the case of USM we use the securityModel (USM) and the
> > userName in the msgSecurityParameters (securityModel-specific
> > parameters inside a SNMPv3 Message) which gets mapped (1-1)
> > into the security-model-independent securityName.
> > The securityModel and securityName are used to map to a
> > groupName, which is then one of the keys to find out
> > if access can be granted.
> 
> I am suggesting, however, that we allow the AAA-provisioned
> authorization attributes to map into groupName.  That may require a
> modification to the API between the access control module and the
> security module.  It would certainly not affect the SNMP over-the-wire
> protocol definition.
> 

I am not sure yet I understand what you want to do.
If you look at the figure on page 24 of RFC3411, then you can
see that we do not have an API (or ASI as we call it because
it is only meant to be a logical interface between modular
pieces of our technical specifications and not intended to
mandate an implementation API) between the security module and
the acces control module. Instead, the applications (like
the CommandResponder and the NotificationOriginator) call the
the access control module with arguments they have received
via internal mechanimsms (securityName, Groupname, viewName
etc, see RFC3415 for details).

So my question is how do we populate the existing MIB tables
like the VACM table to prepare for access. And then when a
SNMP message comes in, what information can we extract out
of that messages (either the SNMPv3 message itself, in any
(SSH or Radius specific) securityParamters that can easily
map onto the internal data structire (concepts) of 
securityModel, secuirtyLevel, securityName? Or maybe when
the message comes in (over SHH),  we can populate some
of those internal things (securityModel, securityLevel and
securityName) so that fruther down all works fine.

It could be that when we get the session setup call and
we check with RADIUS, that at that point we populate some
of the internal MIB tables with (temporary maybe) securityName
and mapping into a group) and then decide that the session
must use some specific (temporary) userName (in the security
Paramters of the SNMPv3 message) that maps to the proper
securityName that was instantiated in the VACM tables for
this session. Anyway, we have lots of work to do there I 
think

> > If the securityModel is gonna be (for example)
> > SSM (SSH-based Security Model), then we have the securityModel.
> > We then need to decide how we map the SSH identity (correct term)
> > into a securityName. Once we have those two, I think it is
> > a matter of populating an entry (entries) in the
> > vacmSecurityToGroupTable and bingo, we're all set.
> 
> I agree that operators will continue to populate the VACM table as they
> do (or do not) today.  Today the mapping from securityName to groupName
> is stored in the local non-volatile storage of the managed entity.  I
> think that constitutes an impediment to deployment and a scalability
> issue that ISMS needs to address.
> 
> It seems to me that are three choices:
> 
> (a) In practice, the securityName will be limited to a small number of
> values that describe roles within and organization structure (e.g.
> help-desk, network-admin), and not individual identities (e.g. dnelson).
> Then, securityName can that be a simple 1:1 mapping into groupName
> (perhaps the equality mapping).
> 

I have sort of preached in the past that I would popolate the MIB
at the managed device with (basically unknow) users and secrets.
They would be know on the managed device and on the NMS station.
They would (in my view) represent roles as you describe).

At the NMS, a user/person logs in (e.g. dnelson) and based on
the credentials he gives he can then act in a particular role.
It would make it so much easier if dnelsen leaves the company and
you need to remove his access rights. You only need to do it on
the NMS(es) instead of having to do it on (hundreds of) thousands
of devices. Same for when a new operator comes and joins the team.

One could imagine a few "crisis or emergency" users that have been defined
and that are under strict control. Such users would be used in firefighting
mode, when the NMS cannot help or is unavailable or has no connectivity to
the device or so. Such special users would eb used rarely (I hope) and
would need to change after they ahve been used.

Oh well... sory for my side-stepping and all that.
But the idea is not bad in my view.

> (b) The mapping between securityName and groupName remains to be
> provisioned as it is done today.
> 
> (c) We allow the AAA server to provision the groupName, centralizing the
> mapping of securityName to groupName in the AAA server, along with other
> access rights information.
> 
> I think that (a) is simple, but has the potential disadvantage of losing
> the individual identity of the user (or command generator).  It may be
> interesting to keep that for auditing purposes, e.g. syslog.
> 

Well, see my rant above. the auditing issue could be handled
on the NMS, but I can see that that might not be sufficient.

> I think that (b) perpetuates an impediment to deployment.
> 
probably

> I think that (c) is almost a simple as (a) and is the best choice.
> 
As long as we can define a way to do that without having to
touch many many places inside an SNMP implementation.
I think at the bginning of my response above, I may have started
to think about how we could do that. The way I describe it there
I think tries to leave VACM alone and instead allow
(at session setup) to populate some entries and maybe assign a dynamic
userName or some such (that maps into a temporrary/dynamic securityName).
That way, the code changes could be localized to where we must add/insert
the new securityModel anyway.

Bert

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

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 19 Aug 2005 10:27:15 -0700

Hi Bert,

Here's how we had proposed in the EUSM draft

    This specification would require a minor modification to the SNMPv3
    VACM processing as defined in [RFC3415]. The current VACM
    specification has the vacmSecurityToGroupTable, this table maps a
    combination of securityModel and securityName into a groupName which
    is used to define an access control policy for a group of principals.
    The EUSM model will have not a Local Configuration Database and
    securityNames, hence there would be no entries in the
    vacmSecurityToGroupTable for the EUSM model.

    The new security model MUST retrieve the groupName for
    the user on successful authentication and the authoritative SNMP
    engine MUST not look up the vacmSecurityToGroupTable to retrieve
    the groupName for a given security Name. In case of RADIUS
    authentication, the groupName MUST be returned by the RADIUS
    server.  It is possible for the RADIUS Server to return a
    groupName that has not been defined on the authoritative SNMP
    engine; in such cases, the vacmAccessTable would not have an entry
    for this group. The authoritative SNMP engine MUST return with a
    noAccessEntry error for the request.
    All other aspects of the SNMPv3 VACM would be applicable to this
    specification. Although the vacmSecurityToGroupTable would be empty
    for EUSM users, it would not effect other VACM tables that depend on
    the groupName. The vacmAccessTable has the groupName as of the
    indexes but the groupName is not dependent on instances in
    vacmSecurityToGroupTable, quoting the statement in [RFC3415],
    "Entries in the vacmAccessTable can use an instance value for object
    vacmGroupName even if no entry in table
    vacmAccessSecurityToGroupTable has a corresponding value for object
    vacmGroupName."

I think this text is relevant to any new security model we define.

regards,
   kaushik!