{131} Trap Object Security

[Bob Stewart <[e-mail]>]

Date: Tue, 10 Jan 1995 16:37:44 -0800
From: "Jeffrey T. Johnson" <jjohnson>
To: [e-mail]
Subject: SNMPv2-Trap-PDU can provide unauthorized access to data
Cc: jjohnson

{ Chair's note.  This was delayed due to California weather conditions, so
  I have Jeff a break.  Plus he has a point. }

Item:  SNMPv2-Trap-PDU can provide unauthorized access to data
Area:  Protocol Operations
Level: Minor  (does anal retentive have a hyphen in it?)

Section 4.2.6 of draft-ietf-snmpv2-proto-ds-00.txt defines the mechanism by
which SNMPv2-Trap-PDUs are transmitted.  The destination(s) to which traps
are sent is determined by consulting the aclTable and finding all the entries
which satisfy several conditions.  Condition 3 specifies that the
notification's administratively assigned name must be present in the
aclResources corresponding MIB view.  Condition 4 specifies that if an
OBJECTS clause is present in the NOTIFICATION-TYPE macro, then the
correspondent variables must all be present in the MIB view corresponding to
aclResources.  These two conditions can be used to prevent certain traps
(or traps containing certain data) from being sent to specific destinations.

The rules for constructing the variable-bindings field specifies
that the first two variables should be sysUpTime.0 and snmpTrapOID.0.
Next, if an OBJECTS clause is present in the NOTIFICATION-TYPE macro,
then each corresponding variable is copied, in order, to the variable-
bindings field.  *Finally, at the option of the SNMPv2 entity acting in
an agent role, additional variables may follow in the variable-bindings
field*

It is this last clause which presents the problem.  Specificially, the
conditions for sending a trap do not prevent the trap from being sent
even if any of these additional variables are not present in the
MIB view corresponding to aclResources.  If that's too many "not"s, then
let me rephrase by saying that if any of these additional variables
are not present in the MIB view corresponding to aclResources, then the
trap is still allowed to be sent.

Solution 1:
Leave the text as is.  This is not a problem, it is a feature.

Discussion 1:
If this is a feature, I'd like it explained a bit better


Solution 2:
Modify the text to specify that the additional variables may be added
to the variable-bindings field only if the variable is present in the
MIB view corresponding to aclResources.

Discussion 2:
This implies that the variable bindings must be built with knowledge
of the MIB view.  In my experience, the variable bindings are usually
built without knowledge of the view.


Solution 3:
Modify the text to specify that if the agent adds objects to the variable
bindings, then the SNMPv2-Trap-PDU will only be sent if it meets the
added condition that the variables are all present in the MIB view
corresponding to aclResources.

Discussion 3:
This seems the most "logical" to me.  A subagent can build the trap variable
bindings, and the master agent only sends the trap to those destinations
which have *all* of the variables in their view.


Solution 4:
Don't allow agents to add objects to the variable bindings

Discussion 4:
This has the elegance that when a management application receives
a trap, it knows exactly what objects will be present in the
variable bindings.  Further, if a vendor wishes to provide additional
information, it may do so via an enterprise-specific trap.