Subject: [Isms] RE: Keep the agent simple; was RADIUS is not a trusted third party

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 26 Apr 2005 14:10:58 -0400

>>But that was the whole problem! Admins did NOT want to enter a new set
>>of user-names and passwords in each agent, and then manage the lists.
>
> Perhaps you miss my point.  The problem I first heard Wes articulate
was the
> need to update all (eg) 1000 agents when one of the (eg) 150 end-users
of the
> SNMP manager changed.  I am saying don't bother.  Predefine users
(user1 to
> usern) in the agent independent of the end-users, the operator
customises
> shared secrets for as many or as few as he requires at installation of
> the agent and only changes them in accordance with security policy
(monthly,
> yearly, after a security breach, never).  This keeps the agent simple.

Perhaps you miss my point. Because the above is _precisely_ what
operators do _not_ want to do.

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

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Tue, 26 Apr 2005 12:28:02 -0700

Good point.  I am glad that Tom brought up this important issue 
about user management, and I'd like to elaborate this point
a little bit.

I guess we all agree that with the growing sizes and complexity 
of today networks, network management is moving toward end-to-end, 
service-oriented, not just individual device mgmt.  Opearators 
now-a-day are increasingly using centralized applications (such 
as Cisco Works, etc.) to manage the networks as a whole instead of 
dealing directly with the devices individually.  

Old Model:

User <--> SNMP Manager <--> SNMP Agent (Device)

New Model:

User <-> Client Console <-> Centralized Server <-> SNMP Agent

These centralized servers (Cisco Works, HP OpenView, etc) often 
provide web-based and/or GUI interface and have their own user 
auth & access control.

Doing user access control at the centralized manager instead
of at the device (instrumentation) level has many advantages:

1. The centralized manager has a global view of the network
as well as the global security policies, so it can provide
a more complete and consistent user access control.  

2. Easy to manage.  There is one/a few centralized server(s), 
so adding or changing users is simpler.  Integration with AAA 
(radius/tacacs+) is also much easier (only a few, not thousands, 
of AAA clients to manage).

So as Tom pointed out, it's better to configure SNMP agents
with just one or a few predefined "users", mainly to auth b/w 
the centralized manager and the agents.  The "real" end users
are handled by the centralized managers, not by the individual
devices.  

Ultimately, we may not even need the concept of a "user" at
the SNMP instrumentation (agent) level.  Some simple scheme 
such as a community-based access control can be used as an 
alternative to the user-based access control model.  But 
that's a different topic...

Just my 2c.

Khanh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Tuesday, April 26, 2005 9:30 AM
> To: Blumenthal, Uri; [email-masked]
> Subject: [Isms] Keep the agent simple;was RADIUS is not a 
> trusted third party
> 
> <in-line>
> 
> (I keep falling behind with all this:-)
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Blumenthal, Uri" <[email-masked]>
> To: "Tom Petch" <[email-masked]>; "Nelson, David"
> <[email-masked]>; "Khanh Nguyen (khanhvn)" 
> <[email-masked]>; <[email-masked]>
> Sent: Thursday, April 21, 2005 11:43 PM
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
> 
> 
> But that was the whole problem! Admins did NOT want to enter 
> a new set of user-names and passwords in each agent, and then 
> manage the lists.
> 
> Perhaps you miss my point.  The problem I first heard Wes 
> articulate was the need to update all (eg) 1000 agents when 
> one of the (eg) 150 end-users of the SNMP manager changed.  I 
> am saying don't bother.  Predefine users (user1 to
> usern) in
> the agent independent of the end-users, the operator 
> customises shared secrets for as many or as few as he 
> requires at installation of the agent and only changes them 
> in accordance with security policy (monthly, yearly, after a 
> security breach, never).  This keeps the agent simple.
> 
> An end-user accesses the manager using its customary user id, 
> is authenticated by a security server which grants permission 
> for an SNMP session and which creates an SNMP sesssion key 
> based on the secret shared between security server and agent 
> (but not with the manager).
> 
> The manager/security server have more work to do but that is 
> ok, there are few of them, often surrounded by operational 
> staff (at least compared to agents) so increase the workload 
> there to keep the agent simple.
> 
>