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

From: "Nelson, David" <[email-masked]>
Date: Fri, 19 Aug 2005 13:27:31 -0400

Bert Wijnen writes

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

That aligns with what I was thinking.

> Anyway, we have lots of work to do there I think

Yes.

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

This is a method of obtaining some of the benefits of ISMS, without
having to implement ISMS.  I think that ISMS, at a very high level,
effectively moves the mapping of the specific usernames to generic
usernames (roles) out of the NMS and into the AAA server.

> As long as we can define a way to do that without having to
> touch many many places inside an SNMP implementation.

The devil is always in the details.  It is well that we understand the
high level issues and work required so that we don't charter goals that
are too difficult to achieve.

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

Yes, I agree that is the desired approach.

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