Re: access control on the <eventStreams> data model

[Balazs Lengyel <balazs.lengyel@ericsson.com>]

Hello Andy,
Your proposal that access control should be on individual notification level instead of stream 
level is sensible. But
1) As we do not yet define access control, I would like to avoid having SHALL or MUST 
statements rather use MAY or SHOULD. At this point access control can reject anything.
2) I see a (not very strong) use case for stream level access control.
- separate stream for security data, only available to security administrators
- nodes administered by multiple administrators with separate streams
While this all can be solved by a notification level access control I still assume that access 
control might work on stream level.

I propose to change 3.2.5.1:
"The Netconf server MIGHT/SHOULD omit streams from the list, if the NETCONF session does not 
have sufficient access control privileges to subscribe to a stream."

In chapter 2.2 we should include:
"Even if a subscription succeeds individual notifications are still subject to access control. 
If any data in a notification is restricted by access control from being delivered to the 
NETCONF session the sending of the whole notification SHALL/MAY be stopped."

Balazs

Andy Bierman wrote:
> Hi,
>
> Sec. 3.2.5.1 says
>
>   The returned list must only include the names of
>   those event streams for which the NETCONF session has sufficient
>   privileges.
>
> Yet, sec. 2.1 (on create-subscription) does not mention access
> control at all. It does not even mention that the RPC can fail
> due to access control.
>
> This requirement for <eventStreams> puts an unreasonable burden
> on agent implementations to maintain special access control
> mechanisms for this data model.  Normally, the agent only
> has to check if the manager has read access to the requested
> nodes.  This text would require special code to hook into
> the notification subscription code to enforce this rule.
>
> It is not even clear that access control "by stream" even
> makes any sense.  Access control by namespace and element name
> within the data stream makes sense.  What if the same data
> can appear in multiple streams?  It is also more robust
> to simply exclude restricted data from the particular subscription,
> rather than reject the entire subscription, because the manager
> has access to most (but not all) of the possible data that
> could be generated in a stream.  This is how access control
> works in SNMP.  If you to a getnext or getbulk, it skips restricted data,
> rather than rejecting the PDU with an error.
>
> IMO, the restriction in 3.2.5.1 should be removed.
> The only real requirement is that a session must have sufficient
> access rights to receive the <notification> data, or it is not delivered.
>
> 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/>

--
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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