[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: architecture and security

On Mon, Apr 10, 2006 at 12:03:54PM -0700, Randy Presuhn wrote:

> > Given the desire "to make part of management information
> > such as that for a single interface available to users
> > of that part and not to other users", SNMPv3 attempts
> > to do this via setting up VACM authorization rules.
> > The result is an inconsistent set of management info.
> ...
> 
> How so?

I tend to agree with Dave Perkins.

I have recently looked at a different problem, namely the
anonymization (or pseudonymization) of management traffic and
configurations and it is virtually impossible to get this right since
information leaks through very easily (just consider an IPv6 address
derived from an IEEE MAC address which is then used to derive an
SnmpEngineID - and now your task is to anonymize the MAC address).
While it might be possible to get things right for a given device with
enough man-power for standard read-only tables (and I very much doubt
that someone is willing spending this money for a single device while
the next device means you have to repeat major parts of the exercise
due to many private MIB objects), things melt down quite quickly once
you face tables where users can name entries or even put descriptions
or other opaque things into an agent. Operationally useful names
usually carry quite a bit of context (this is exactly why they are
useful to operators) and so it is very likely that information leaks
through these descriptions.

Talking about VACM: VACM fails by design when it comes to situations
where the item you want to base your access control decision is not in
the OID.  No, I am not asking for a VACM++ - this would only help in
theory and make things worse in practice.

I believe that in practice, we need the implementations to help us do
the right thing for a given set of well understood and defined
profiles. Dave's idea to provide views by means of virtualized devices
surely sounds interesting, although probably too far reaching for IETF
work.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>