Re: architecture and security

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

This goes back to modeling vs authorization.

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.
Another approach is to create a virtual device
that appears as simple and implements only the
functions that a user is authorized to access
management info. And finally, the management info
can be collected from the device and made available
in another format (and data model).

I see the authorization approach as a temporary
quick fix that sort of works in limited cases.

Regards,
/david t. perkins

On Mon, 10 Apr 2006, Randy Presuhn wrote:

> Hi -
> 
> > From: "Kent Watsen" <kwatsen@juniper.net>
> > To: "Andy Bierman" <ietf@andybierman.com>
> > Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> > Sent: Thursday, April 06, 2006 8:45 PM
> > Subject: RE: architecture and security
> ...
> > 1. When the subscription-request comes in, the system must authenticate
> > that the request only subscribes to events the client is authorized to
> > receive
> >
> > 2. However, when each notification is generated by the system, the
> > system only forwards it to the client if it already has a subscription
> > in place for that kind of event
> >
> > In case you think that I'm contradicting my earlier statement
> > "eliminates the system from having to apply filters to the responses",
> > what I meant to say is that it eliminates *access control* from having
> > to apply filters to the responses.  This is true since any notification
> > matching the subscription request, which was authorized, is also
> > implicitly authorized to be sent to the client
> ...
> 
> It sounds like these access control policies are only in terms
> of the event type, and not in terms of the specific resources
> being managed.  In other words, if Customer A should only
> be able to access interface (a) configuration data,
> and Customer B should only be able to access interface (b),
> and the same event type is defined for both interfaces,
> we'd have a problem.
> 
> Or is this simply one of those things netconf won't support?
> 
> Randy
> 
> 
> --
> 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/>
> 


--
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/>