Subject: partial locking and access control

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Dec 2007 09:10:52 -0800

Hi,

The requirement about 'must have enough access rights'
to get a partial lock is problematic.

In order to accept this requirement, I have to accept the fact
that NETCONF has a proprietary access control model, instead
of no access control model at all, and I don't.

The standard access control model in NETCONF is that every user has
access to every part of every configuration database.  That means
that any user can partial-lock anything, unless it is already locked.

(BTW, checking partial locks at configure time doesn't work
for nodes that match the Xpath expression at access time,
but did not exist at partial-lock config-time.  The config-time-only
for arbitrary Xpath approach is completely broken for this reason.)

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: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Dec 2007 18:41:42 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> access to every part of every configuration database.

Are you saying that in order to be RFC 4741 compliant, an
implementation MUST NOT have a (proprietary) per-user access control
model?  That is definitely not my understanding, and I'd be very
suprised if any netconf implemention works that way.

> but did not exist at partial-lock config-time.

What do you mean "doesn't work"?  When the XPath is evaluated, a node
set is returned.  Those node are locked.  This is the design.  What
exactly "doesn't work"??

> The config-time-only

Please clarify "completely broken".

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Dec 2007 10:05:54 -0800

> suprised if any netconf implemention works that way.

No, I am saying that if you want to make a standard
for partial locking, that it can only rely on mechanisms
defined in standards.

Having an 'access-denied' error-tag in NETCONF that supports
proprietary access control models is not the same thing as
defining a requirement in a standard that assumes some
unspecified access control model will be in place.

> set is returned.  Those node are locked.  This is the design.  What

There are Xpath expressions that can specify nodes without parent
nodes.  What if the agent adds nodes to the configuration database
(e.g., card insertion), which adds nodes that match such an
Xpath expression.  Then a proprietary <edit-config-with-Xpath> RPC
is used to modify that node.

Also, what if another session issues a <partial-lock> that matches
this new node, but none of the nodes locked in the first partial-lock
RPC (by the other session).  This new node would of matched the
original Xpath expression had it existed at the time.

When a manager application looks in the NETCONF monitoring DM
and gets all the partial lock information, how does it know
that this new node is not part of the partial-lock that
the agent says matches the lock request?

> Please clarify "completely broken".

A 2nd partial-lock request which matches a new node
is granted, even though it also matches the first partial-lock
that includes this new node in its Xpath expression,
but not actually in the partial-lock.

I think an operator issues a lock that matches the new node,
it expects the lock to work when access to the
locked data is requested, regardless of when the lock was granted.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Dec 2007 20:03:16 +0100 (CET)

> for partial locking, that it can only rely on mechanisms

Ok.  I'd be happy to remove this text.

> original Xpath expression had it existed at the time.

Sure, but since it didn't, it wasn't locked.

> the agent says matches the lock request?

This is an argument I understand :)  And I even think that it is
probably more useful to be able to monitor those locks correctly, then
having the generic XPath lock feature.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Dec 2007 11:27:35 -0800

> having the generic XPath lock feature.

I want the partial lock to only be a super-simple Xpath
expression that only includes the QNames and [index1='foo'][index2='bar']
type of expressions.  It would be good if access-control works the
same way, if there ever is a standard for NETCONF access control.

Fancy stuff like "lock all the interfaces to Chicago that
have the 'gold-service' feature enabled" can wait
for Version 2 of the standard.  Start simple and prove
that this approach is secure and interoperable.

I don't mind defining a safe subset of Xpath that MUST be supported
by every agent, just like <lock>.  I have an objection making
full Xpath mandatory for RFC 4741 compliant agents.

Unless the WG re-releases NETCONF-1 as a new version of the protocol,
requiring full Xpath, and then obsoletes RFC 4741.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Dec 2007 20:38:06 +0100 (CET)

> same way, if there ever is a standard for NETCONF access control.

Agreed.

> that this approach is secure and interoperable.

Ok.

> full Xpath mandatory for RFC 4741 compliant agents.

That was never the intent of course.  partial-locking is an optional
capability.  And the intention was also to support the general xpath
part only if your implementation also supported the :xpath
capability. 

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 07 Dec 2007 15:00:03 -0500

>access to every part of every configuration database.

If every user had access to every part of the config, we wouldn't
need the "access-denied" error-app-tag.

There is no standard access control model in NETCONF.  Access
control is left to the implementation, which will hopefully
ape whatever's in the CLI.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Dec 2007 11:52:28 -0800

> part only if your implementation also supported the :xpath

To be clear.
I think it is a great draft and I hope it approved quickly.
Starting simple will make that much easier.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 10 Dec 2007 14:29:30 +0100

Hello Mark,

General) We retrieve a list of Netconf data model descriptions. These might be Yang modules or 
XML Schemas or something else.

The document should be merged with the netconf-monitoring draft.

Ch 1.) The Hello should contain the capabilities related to data models as well. See Netconf 
standard:
    5.2.  Data Modeling
"The device uses capabilities to announce the set of data models that the device implements..."

Ch. 1.1.1 last requirement)
a means to advertise the availability/location of the formal data model descriptions

Ch 3.1) Use simple get. We don't want new get-A, get-B, get-C operations for each new bit of data.

Ch 3.2.1.1.1)
I assume the identifier and version are unique only together not one-by-one.
Define what is the identifier? Is it the capability string/XML namespace?
The schemalist should be rather at the location netconf/schemalist similarly to the 
Notification model.
Indent the RPC-reply example!

Ch.4) Discovering the models supported by the node facilitates hacking the node, so access 
control must protect the schemalist.

regards 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: Balazs Lengyel <[email-masked]>
Date: Tue, 11 Dec 2007 16:17:59 +0100

Hello Andy,
 From RFC4741 security considerations:
"Implementors SHOULD provide a comprehensive authorization scheme with NETCONF."
It is true that here we have a SHOULD and not a MUST. So I propose to change the requirement to:

A partial lock MUST fail if:
- The NETCONF server implements access control and the locking user does not have at least some 
basic access rights, e.g., read rights, to all of the datastore section to be locked

As I know our previous security adviser had serious problems with the missing link between 
locking and access control.

Balazs

> that any user can partial-lock anything, unless it is already locked.
[BALAZS]: I think there is no standard access control model in NETCONF, but according to the 
standard there SHOULD be a some kind of access control in the device.

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 11 Dec 2007 18:59:16 +0100

Hello,
I would also like to simplify locking. Also see below.
Balazs

> same way, if there ever is a standard for NETCONF access control.
[BALAZS]: This means you would not allow something like lock all interfaces, or all users? 
(Naturally if there is a container above the individual users this could be still done.)
If I understand you correctly you would only allow the locking of specific individual nodes 
(possibly multiple items). The user would have have to specify the nodes each individually and 
no "groups of nodes" like all interfaces should be allowed.
Once you allow to lock "groups" you immediately have a lot of complications.
> requiring full Xpath, and then obsoletes RFC 4741.
[BALAZS]: Full XPATH will not be mandatory even if you support the partial-lock capability. It 
is still a separate decision if you want to (or not) support the XPATH capability.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2007 11:38:48 -0800

> Andy Bierman <[email-masked]> wrote:

.....
> Sure, but since it didn't, it wasn't locked.

This is an important issue, and demonstrates the problems with
the current approach in the draft.

Let's say an operator locks "*/ifAdminStatus" to make sure that
nobody turns off any interfaces during some network test
or big config change.

Then a new card gets plugged in that creates some new interfaces
like "/interfaces/interface[name='Ethernet1/0']".

The operator wants all ifAdminStatus knobs to be locked.
Except, it not true for this instance:

   /interfaces/interface[name='Ethernet1/0']/ifAdminStatus

There are 2 separate issues here:

   1) Designing a partial locking mechanism that meets operator expectations
   2) Monitoring which nodes are actually locked by a partial-lock operation

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 11 Dec 2007 15:37:04 -0500

>nobody turns off any interfaces during some network test

This example and your "div 7" one both highlight one of the problems
with partial locking.  As a server, my data model may not support
(and I don't want to support) random bits of XPath.   Locking status
fields, etc is just silliness not worth burning code on.

IMHO the data model needs to define what's lockable.  Supporting
random XPath expression locking is way too expensive.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Dec 2007 21:52:01 +0100 (CET)

> nobody turns off any interfaces during some network test

Well, this simply doesn't lock all interfaces as you point out.  This
won't work with the plain instance identifier approach either, if the
operator gets a list of all interfaces from the box and locks them all
explicitly.

>    1) Designing a partial locking mechanism that meets operator expectations

I agree that locking a simple subtree (instance identifier) is simple
and easy to understand.

>    2) Monitoring which nodes are actually locked by a partial-lock operation

Actually, this can still be solved for the general XPath case.  In the
monitoring list of locks, we can simply list all instance identifiers
held by a lock:
   
   leaf-list locked-subtree {
      type instance-identifier;
   }

This is what we'd have to do for the instance-identifier only solution
as well.

This being said, I don't have a strong opinion on this issue.  But I
don't think the arguments I have seen so far says that general XPath
cannot be used.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Dec 2007 21:56:22 +0100 (CET)

> random XPath expression locking is way too expensive.

Note that random XPath is only supported if the :xpath capability is
supported.  Implementation-wise, if your code handles :xpath, it will
not be more expensive to handle random xpath for partial locking.
(That's what we do in our implementation - we just send the xpath to
our xpath evaluator, and it will return a node set.  Each node in the
node set will be locked.  For a xpath filter in a <get>, we just use
the same xpath evaluator but sends the selected nodes in the
rpc-reply).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Dec 2007 15:34:20 -0800

> the same xpath evaluator but sends the selected nodes in the

IMO, random Xpath should be a vendor extension.
Prove that it works for locking (I don't think it does.)

Take the ifAdminStatus example.
This is a valid use-case.
The operator needs to specify the desired lock in a way
that does not change between compile-time, rule-config-time,
and permission-check-time.

The ncx-acm access control model uses a list of QName strings
as one way to specify an rule target.  The QName 'itf:ifAdminStatus'
is sufficient to satisfy this basic partial-lock requirement.

(Maybe if I knew Xpath better I would think it was a hammer
encrusted with such fantastic precious metals that I would
clearly want to smash on more nails with it. ;-)

Andy