Subject: access control on the <eventStreams> data model

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jul 2007 13:09:03 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 12 Jul 2007 13:50:23 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Netconf (E-mail)" <[email-masked]>
> Sent: Thursday, July 12, 2007 1:09 PM
> Subject: access control on the <eventStreams> data model
...
> rather than rejecting the PDU with an error.
....

But, FWIW, that's not how access control for notifications works in SNMP.
RFC 3413 3.3 (2)

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jul 2007 14:28:20 -0700

> But, FWIW, that's not how access control for notifications works in SNMP.

Do you mean para 2:

    Notification originator applications require a mechanism for
    identifying the management targets to which notifications should be
    sent.  The particular mechanism used is implementation dependent.
    However, if an implementation makes the configuration of management
    targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module
    described in this document.

I think you mean para 4, point 2:

    (2) The appropriate set of variable-bindings is retrieved from local
        MIB instrumentation within the relevant MIB view.  The relevant
        MIB view is determined by the securityLevel, securityModel,
        contextName, and securityName of the management target.  To
        determine whether a particular object instance is within the
        relevant MIB view, the isAccessAllowed abstract service interface
        is used, in the same manner as described in the preceding
        section, except that the viewType indicates a Notification-Class
        operation.  If the statusInformation returned by isAccessAllowed
        does not indicate accessAllowed, the notification is not sent to
        the management target.

The difference seems to be that (on a PER-NOTIFICATION basis)
the entire PDU is dropped if any data within it is restricted.
This is fine -- easier on the agent than pruning the restricted data
and sending the rest.

But this is much different than refusing to let the manager see
the name of the stream or rejecting the <create-subscription>
because individual notifications may not be delivered.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 12 Jul 2007 17:51:52 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "Netconf (E-mail)" <[email-masked]>
> Sent: Thursday, July 12, 2007 2:28 PM
> Subject: Re: access control on the <eventStreams> data model

...
...
> I think you mean para 4, point 2:

yes
 
...
> This is fine -- easier on the agent than pruning the restricted data

yes, particularly in the case of SNMP where the NOTIFICATION-TYPE
may specify mandatory variable bindings, but other stuff may be
included by an implementation.

> because individual notifications may not be delivered.

Since it's reasonable for permissions to change over time,
I think it makes no sense to block creation of a subscription
based on whether the notifications that could be generated
in the future might be blocked at the moment.  Particularly in
the case of creating a subscription with respect to things
that might not exist at the moment.  But that having that kind
of flexibility might be an SNMP-centric view of the world.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jul 2007 21:52:22 -0700

> of flexibility might be an SNMP-centric view of the world.

not SNMP-centric. NM-centric.
Common sense network management.
Perhaps if there was an actual security model for NETCONF,
it might be more clear that per-notification access control
(send or drop decision per PDU) is all that is needed here.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Jul 2007 10:40:35 +0200

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

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Jul 2007 10:53:27 +0200 (CEST)

> access rights to receive the <notification> data, or it is not delivered.

I fully agree with Andy.  (Incidentally, this is how I have currently
implemented the eventStreams datamodel...)

/martin