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

From: "Tom Petch" <[email-masked]>
Date: Thu, 28 Apr 2005 16:01:51 +0200

<inline>
Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
Sent: Tuesday, April 26, 2005 10:51 PM

> Comment #1:
> One intention of the SNMPv3 approach was to enable logging of changes,
> including logging the securityName of the security principal. In your
> solution, there would be no security principal known at the agent, so
> audit logs could not be done. Is this correct?

Logging is possible.  securityName is not stored in the agent but is known (and
authenticated) to SNMP manager and security server, so the manager can put it in
the security parameters to enable logging; but it is the userj identifier that
is used for security checks at the agent on the incoming messages.

> Comment#2:
> Some applications already provide for user authentication via a
> centralized server, and then use the identity of the application as
> the SNMPv3 user. This allows for a very limited number of SNMPv3 users
> at the agent, while allowing user-specific authentication at the
> application. The application authorizes the authenticated user to
> utilize its user-independent application identity for SNMPv3.
>
> Your suggestion depends on a third-party server to provide a similar
> mapping between the authenticated-user at the application and a
> user-independent identity temporarily assigned by an
> authentication/authorization server used as the SNMPv3-user. Is that
> correct?
>
Yes (with the caveat above that the manager can include the end user name in the
message for eg logging).

It doesn't have to be a third party security server, it is just that everywhere
I go that is what I see ie noone logs onto a free standing Unix box using Unix
authentication prior to using Cisco Works, NetView, OpenView (and yes I know my
terminology is not what the vendors would like me to use:-).  Rather that that
Unix (or Microsoft or IBM ..) box is networked with others to a central security
server which keeps the authentication and authorisation for the end users.  So
it does not matter where I am in the organisation, the server I access finds out
that TP377 is allowed to user SNMP read access but not write, Telnet but not to
the firewalls, etc etc

Bundling the security server into the SNMP server as a single standalone box is
a subset of this and seemed a less flexible architecture.

<snip>

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

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 28 Apr 2005 13:58:54 -0400

Hi Tom, 

> is used for security checks at the agent on the incoming messages.

In this approach, is there any authentication of the securityName in
the security parameters, to ensure that the securityName and the
assigned userj identifier refer to the same security principal? If I
control the application, can I authenticate to get a userj identifier,
and then use a securityName of "Tom Petch" so your name gets logged
rather than mine when I do something I shouldn't? How does the SNMP
agent prevent such a misleading thing form occuring, or, if the agent
cannot detect and prevent this, how does an admin uncover this
deliberately misleading tactic?

> a subset of this and seemed a less flexible architecture.

When you say "SNMP server" are you referring to a manager (entity
acting as a command generator) or an agent (entity acting as a command
responder)?

David Harrington
[email-masked]