RE: architecture and security

["Kent Watsen" <kwatsen@juniper.net>]

Yikes - there is slight misunderstanding; I was using NSM's NB API by
example - since we have already solved this problem.  I am in no way
trying to suggest or advocate a proxy from NSM's client to the device.

I was addressing your "Access control is backwards" concern by
explaining that it is a non-issue as the device only needs to auth the
initial subscription request - any matching events the device generates
are implicitly authorized to go to all subscribers of that event.  Thus,
all access-control is still "forwards"

Kent



-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] 
Sent: Thursday, April 06, 2006 12:53 PM
To: Kent Watsen
Cc: Netconf (E-mail)
Subject: Re: architecture and security

Kent Watsen wrote:
> NSM also supports notifications thru its northbound interface.  The
way
> that we address access control is by authorizing the subscription
> request.  This approach has proven ideal for us as it:
> 
>   1. limits the system to only having to test client-initiated
requests
>   2. enables the system to add "implicit-filters" to the requests
>   3. eliminates the system from having to apply filters to the
responses
> 
> To understand the desire for implicit filters, please consider that
the
> system may implement granular access-controls such that an
authenticated
> user may only have access to a subset of a data repository.  For
> instance, the user may only have access to a particular virtual system
> (i.e. virtual router); from the user's perspective, the subscription
> might be to "all events" but, upon receiving the request, the system's
> access-control module might add an implicit-filter so that the request
> then reads "all events where event->vsys == user->vsys" - after having
> modified the incoming request, the access-control module can than pass
> the request down into the system, which can remain unaware of
> access-control issues...

I need to understand this architecture better.
The WG agreed that a user-based access control model
needs to be supported, but we never specified the details.


So "user A" connects to your NB NSM API to receive notifications.

The NSM (as "user B") has a SB session to a netconf agent configured
to send notifications.

Then "user C" connects to the netconf agent and causes a notification
to be generated.

Let's use the (unexplained) example in sec. 5.1 of the draft.

The agent knows that user C has access to this <config> data.
How does the agent know that the information in the <data> element,
such as the operation performed, the interface name, or the mtu,
can be viewed by user B?  How does the your NSM make sure that
user A has proper access to this data?

I think the netconf standard architecture needs to account
for the user C -> B scenario, but avoid proxy in the model
at all costs (i.e., leave C -> B -> A out of the model).
I think the access control granularity needs to be per-object
at least, and per-instance in some use cases.



> 
> 
> Kent
> 

Andy


> 
> 
> 
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
On
> Behalf Of Andy Bierman
> Sent: Thursday, April 06, 2006 8:21 AM
> To: Netconf (E-mail)
> Subject: architecture and security
> 
> Hi,
> 
> I think the architecture for netconf notifications needs more
attention.
> The current draft tries to fit notifications into the existing model
> for remote procedure calls.  The <rpc-one-way> is supposedly just
> like a regular <rpc>, except it goes from the agent to the manager,
> and there is no return value.  Also, the WG decided (based on
> Junoscript experience) that returning <ok> was better than
> no return value -- we explicitly don't want a 1-way-rpc --
> in either direction.
> 
> 
> There are 2 major problems with this architecture:
> 
> 1) Headers are different becase the messages are different;
>    Notifications have different general characteristics
>    than RPC requests, so the headers will be different
>    (e.g., no timestamp in an RPC request like a notification)
> 
> 2) Access control is backwards;
>    It doesn't make sense to apply access control to the '1 way RPC'
>    in the same sense as a regular RPC.  It is the manager who is
>    supposed to have access granted to view specific agent data -- not
>    the agent that is supposed to have access granted to
>    send the manager specific agent data.
> 
> 
> Even though the term <rpc-one-way> is being removed, and the
> message will be called <notification> instead (as it is on
> page 17), we still need a secure architecture which scales well,
> and will support a user-based access control model.
> We need to think of how notifications fit into the base
> netconf protocol, as well as existing security and NM protocols.
> Operational issues and common use cases (e.g., building power-cycle)
> need to be addressed.
> 
> Once the requirements and architecture are understood,
> we will be able to simplify and focus the API.  It isn't
> acceptable to come to the conclusion that a feature is
> a 95% lose-lose scenario, but we should do it anyway.
> 
> 
> Andy
> 
> 
> 
> --
> 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/>
> 
> 

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