Subject: [Isms] SNMPv3 security; the fundamental flaw?

From: "Tom Petch" <[email-masked]>
Date: Sun, 1 May 2005 19:01:06 +0200

Thinking about the recent posts, I think the problem with USM is that it tries
to do too much, to do things that were better done, or done better, elsewhere,
at least nowadays.  The wish of organisations to use the same end-user names
everywhere is understandable but the consequence with USM is that the SNMP
private 'databases' must be updated whenever people come or go or change jobs or
update security credentials; for many, the price is too high.  But there is more
to it than that.

Every SNMP manager (command generator) I see runs on a server platform -
Microsoft Windows 200x Server, IBM AIX or z/OS et al - and these have their own
authentication - of considerable strength - and authorisation - to a very fine
level of detail - offering organisations a range of solutions commensurate with
their security policies, based around a security server (usually a physically
separate box).  Microsoft have been doing this for 10 years, IBM for longer.

By the time a request gets to the API of the command generator, it has been
secured better than we are likely to do using a private database.  In wrapping
this up in SNMP, in SMI and MIB, we have put a barrier around SNMP security
impenetrable to those who do not understand SNMP.  If someone working on the
security of a Microsoft or IBM et al server could see clearly what we were
doing, they might well say, why bother?

All that is needed is a Something to put in the SNMP PDU that can authenticate
the PDU to the command responder and index into the authorisation there.  This
can be done by a call to the security process (task, daemon) of the SNMP manager
server which has links into the organisation-wide security system.  And if the
command responder is also on a server platform, then it can use the Something in
the same way.  All that is needed from us is the definition of the Something in
the PDU that is acceptable to the security processes of different manufacturers.

Where we should then focus, because Microsoft, IBM et al may not, is on the
command responders which run on non-server platforms, like a workgroup switch or
access router with a 68000 chipset, where the mention of Diffie-Hellman is
likely to engender a response of 'come back in a month when I have had a chance
to think about it'.  It is unreasonable to expect these to integrate with the
organisation-wide security system or even to maintain a subset of end user name,
security credentials etc to be updated promptly whenever anything changes.  Or
if that is what the security policy demands, then put in a Windows 2003 Server
with loads of interface cards and configure it as a router - problem solved.

Nor do I see it as practical to download the end user name and security
credentials dynamically into the command responder whenever that end user wishes
to access an SNMP agent.

Rather we need a simpler range of security commensurate with the other
capabilities of an entry level box.  My thinking - as I have expressed before -
is of a basic level consisting of a shared secret with the security server (not
with the SNMP manager-server) which is then used to generate session keys for a
small fixed set of userids; not as secure as USM but much more secure than some
systems I see.  This can be a one touch solution; the secret can be randomised
by engine id (as Khanh suggested), to vary with box type (switch, router,
firewall) etc.

The security can be increased by a two-party protocol (not three) between box
and security server to update the shared secret(s) when required (after a
breach, at irregular intervals etc).  This could be extended to amend other long
term information, such as user id to VACM group name mapping  But if it is not a
server platform, then it has these fixed user ids, not the organisation wide end
user names.

The issue is how to map end user name into the fixed user id.  The security
server must allocate the user id (since the user id is the key into VACM and
authorisation) and pass it to the SNMP manager server which generates the PDU.
All soluble, especially if use is made of the existing server infrastructure.

It was David's question about the logging, and could not the SNMP manager put a
corrupt securityName into the PDU that made me think this through.  Of course it
could, but if you have successfully attacked one of these servers, then the
organisation will have a lot more than SNMP to worry about.  This network of
servers, communicating with a security server, using proprietary or standard
protocols, is what I always see, in any organisation which takes security
seriously; it is the foundation of that organisation's security and I take its
integrity for granted; and so to integrate SNMP security needs more than just
reusing user names and security credentials, it means integrating with that
network of servers.

Tom Petch

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

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 2 May 2005 09:23:02 -0700 (PDT)

HI,

Take a look at slides 3 and 4 from the presentation that I gave at
the WG meeting....
http://www3.ietf.org/proceedings/05mar/slides/isms-2/sld3.htm

These slides don't include the elaboration that I provided.

However, I believe that they do highlight a couple of
key points.

First, most of what a manager (which is a colection of
management apps) does is poll for statistics and status.
This is important - it doesn't have the identity of a user
when it does this, and must use its own identity. The
colected data can be later (maybe months later, or
maybe just a few minutes later) viewed by many
different users. When they do, there is no interaction
with SNMP agent(s). Likewise, there may be programs
that are set up to be run when certain events occur.
These are primarily automated. Whose identity should
they be run with? There are many other examples that
can show that the identity used in SNMP operations
is not a user (since there is no user present
when the SNMP app runs). The identity may be
of the manager (the collection of mgmt apps),
or could be named per mgmt app.

However, for non routine and "real-time" management
apps, such as those used for trouble shooting, or
for "overriding" the configuration at managed systems,
it is probably appropriate to use the identity
of the user instead of the identity of the SNMP
manager (or SNMP mgmt app). An example of
a "real time" mgmt app is a "MIB browser" -
a program that allows a user to view and
possibly set the value of any allowed instance
of management info. 

"Purpose built" mgmt apps need access only the
instances of mgmt info needed to perform a
specific purpose. For auditing, it's important
to know who initiated (started) it (if its
start is not automated). However, unless you
are "debugging" the mgmt app (or the SNMP agent),
it's generally not important to track each
SNMP operation.

In summary, it appears to me that much that
has been done with SNMP is overly biased 
to support MIB browsers, and in support of
complete management systems.

Regards,
/david t. perkins

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 2 May 2005 19:37:13 +0200

Does this relate to the post you made in February asking about managed system
identity?  If so, I had not made the connection until now. (And I never did see
a response).

The more security-conscious organisations I have seen always run automated
processes under a user id because that is the way the security system is set up,
to check authorisations etc.  If you are not an authorised user, you cannot
start a task, execute the relevant code, such as an SNMP manager.

I used to see role-based ids (independent of a
human being) but that is now seen as too insecure, and so now there is (usually)
an
accountable human being under whose id the automated tasks run.  It might for
example be the person who created the automation script, it might be the person
who raised the change request which set the process going.  And of course these
people change roles, leave the organisation etc but the principle remains, there
is always someone accountable.

And I agree, once collected, the data is available for months and years for all
sorts of uses, SLAs, capacity planning and so on.  And again, I see that as
available only to authorised users ie the default is you cannot access any
'system' databases unless the system authorises your user id to do so.

All of which is highly secure and needs nothing from isms to remain so:-)

Tom Petch