For the implementation, when the VACM authorization checking is done
over the outgoing trap/inform there are not reference to engineID. So,
should we consider that all the users used to send informs have the same
security level? Even when the USM allows to define the same securityName
with a different engineID to have a different security level.

The example for this will be:

informUser1:NM1engineID ---> authPriv
informUser1:NM2engineID ---> noAuthNoPriv

group 3 informUser1 authPriv_group (no reference to engineID

In this example the informUser1:NM2engineID won't be able to send

I think that the RFC is expecting all the users that have the same
securityName to have the same securityLevel but there isn't a defined
mechanism to force that in the RFC. Is this a correct interpretation?


> -----Original Message-----
> From: Wes Hardaker []
> Sent: Friday, April 06, 2007 2:05 PM
> To: Dave Shield
> Cc: Wes Hardaker; Passera Pablo-APP015;
> Subject: Re: vacm notification access
> >>>>> "DS" == Dave Shield writes:

> DS> We'll need to tread carefully, though. There will be
> DS> hundreds of existing installations that are working quite
> happily,
> DS> and we'll need to ensure that a default config continues to send
> DS> traps.
> DS> (I realise that such an approach is an anathema to
> security experts,
> DS> but said security experts don't typically maintain the
> users list!
> DS> ;-) )
> Actually, not necessarily... The point is that you don't do
> something the user's didn't expect. I'm quite sure when a
> user says "create a trap sink with community XXX" it would
> expect those to be authorized to go out.
> (what is wrong, is that we allow incoming MIB SET requests
> configure a system that allows traps to go out without
> checking the authorization to do so).
> --
> Wes Hardaker
> Sparta, Inc.

Take Surveys. Earn Cash. Influence the Future of IT
Join's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
Net-snmp-coders mailing list