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

From: "Juergen Quittek" <[email-masked]>
Date: Sun, 21 Aug 2005 13:47:11 +0200

Woul it be acceptable for everybody if we replaced 
"securityName and groupName" with 
"securityName and other SNMP parameters"?
 
    Juergen

________________________________

From: [email-masked] on behalf of Nelson, David
Sent: Fri 19.08.2005 19:27
To: Wijnen, Bert (Bert); [email-masked]
Subject: RE: securityName/groupName [was RE: [Isms] ISMS charter discussion]

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

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

---

From: "David B Harrington" <[email-masked]>
Date: Sun, 21 Aug 2005 13:06:40 -0400

I prefer the "other SNMP parameters" wording.

David Harrington
[email-masked] 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Quittek
> Sent: Sunday, August 21, 2005 7:47 AM
> To: Nelson, David; Wijnen, Bert (Bert); [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Sun, 21 Aug 2005 22:31:58 -0400

>>>>> "Juergen" == Juergen Quittek <[email-masked]> writes:

    Juergen> Woul it be acceptable for everybody if we replaced
    Juergen> "securityName and groupName" with "securityName and other
    Juergen> SNMP parameters"?

I'm a bit concerned about over-broad wording.  Wording so broad that
redefining VACM was inc scope is clearly too broad.  Also, is there
anyone who supports remapping securityname instead of the group name?
I am concerned that I may have accidentally given support to a
specific proposal when what I cared about was giving support to
solving a generic problem without supporting a specific solution.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 22 Aug 2005 15:42:16 -0400

Hi Sam,

The mapping from a model-specific identity to a securityName is
model-specific by definition. There are issues associated with using
securityName in a manner that loses granularity. If the remapping is
done within the security model and the security model addresses those
issues adequately, I see no problem. If the remapping is done inside
the ACM model and the ACM addresses these issues adeqautely, I see no
problem. 

I think remapping securityName instead of groupName is fine to keep as
an option, but I definitely prefer a groupName mapping to overloading
securityName.

dbh 

> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Sunday, August 21, 2005 10:32 PM
> To: Juergen Quittek
> Cc: [email-masked]
> Subject: [Isms] Re: securityName/groupName
>