Subject: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 19 May 2011 12:15:41 +0200

Sofar, it seems no-one has rected to the below.

Please, please, we can hardly imagine no-one has any opinions
on these topics. We are a WG, that means we need to discuss
and try to come to consensus on these matters.

Bert and Mehmet

-------- Original Message --------
Subject: 	[Netconf] Access Control Issues/Question
Date: 	Fri, 01 Apr 2011 10:49:34 +0200
From: 	Bert Wijnen <[email-masked]>
To: 	Netconf <[email-masked]>

WG participants,

Pls comment on this open issues that Martin presented
in his suggested new/improved approach for NACM rule
definitions at our meeting yesterday. The slides
are here:
    http://tools.ietf.org/agenda/80/slides/netconf-1.pdf

- Is two levels of nesting enough?
- A common (?) use case is to define one rulelist for
   a task, and let some groups access it read-write,
   and some read-only. This is not directly supported
   – you would need to define two different rule-lists,
     e.g. routing- admin and routing-read.
   By moving the allowedgroups check from the rule to the
   rulelist, we loose some flexibility. If we really need
   special handling of a rule for some group, this rule
   needs to be defined in a separate rule-list.
- Would it be useful with any objects to help debug a
   NACM configuration?
   - rpc get-rules group-name --->  list of rules
   - rpc check-path group-name path --->  rule execution trace

Bert and Mehmet

---

From: Kent Watsen <[email-masked]>
Date: Tue, 24 May 2011 15:02:09 -0700

The reason I don't have an opinion about the proposal presented in the slides is because I have a larger issue with the I-D as a whole:

1. It's unclear why this problem needs to be solved.

  The I-D says:

  "The standardization of network configuration interfaces for use with
   the NETCONF protocol requires a structured and secure operating
   environment, which promotes human usability and multi-vendor
   interoperability.  There is a need for standard mechanisms to
   restrict NETCONF protocol access for particular users to a pre-
   configured subset of all available NETCONF operations and content."

  And:

  "There is a need for inter-operable management of the controlled
   access to operator selected portions of the available NETCONF content
   within a particular server."

  But I don't understand it - but this might be due to my view that 
  NetConf is primarily for NMSs (see my #3).

2. It seems unlikely device vendors will implement it.

  This YANG module can be optionally advertized.  What motivation do 
  device vendors have to implement it? - especially as it may conflict
  with their native RBAC model or interoperability with external
  authorization servers.

3. It seems unnecessary to support NMS applications.

  I can't speak for all, but our NMS expects to configured to log into
  devices with a root-like account.  Customers configuring a centralized
  management system want the NMS to "own" the box and then provide its
  own RBAC abstraction via its UI.  An NACM solution wouldn't have much
  impact on our NMS.  Furthermore, the user account the NMS logs into 
  the device with is typically the only one on the device that is ever
  used, so an NACM solution would again not have much use.

Sorry to hold my thoughts for so long, but I wasn't sure how the I-D was going to shape up.  Now that I see where it's going, I find I have some reservations for it...

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert (IETF) Wijnen
Sent: Thursday, May 19, 2011 6:16 AM
To: netconf
Subject: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question

Bert and Mehmet

-------- Original Message --------
Subject: 	[Netconf] Access Control Issues/Question
Date: 	Fri, 01 Apr 2011 10:49:34 +0200
From: 	Bert Wijnen <[email-masked]>
To: 	Netconf <[email-masked]>

WG participants,

   - you would need to define two different rule-lists,

Bert and Mehmet

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Tue, 24 May 2011 15:24:36 -0700

>    NetConf is primarily for NMSs (see my #3).

What if there are multiple NMS applications, and the database subtrees they need
do not really overlap?  What if the people using these apps need to login to them,
so there really can be different classes of users.

There may be a mix of operators (on lo-touch objects) and applications
(on hi-touch objects) so assuming a framework with just 1 NMS and no operator
applications using NETCONF is not 100% realistic.

Assuming all users can have all access to all operations and all data
is not a good solution.  Assuming a vendor-specific RBAC implementation
will deal with it just proves there is a need for a standard solution.

>    with their native RBAC model or interoperability with external

We are working with our NETCONF stack vendor to get this implemented in products.

What motivation does a vendor have to implement any standard, except that
they want to converge on a single solution.

>    used, so an NACM solution would again not have much use.

Assuming root access for all NETCONF write activity is not good enough
for the standard.  Using just 1 role for 'edit' vs. multiple roles
is a site-specific decision.  The standard should support the ability
to restrict a role to specific operations and specific data.

> Sorry to hold my thoughts for so long, but I wasn't sure how the I-D was going to shape up.  Now that I see where it's going, I find I have some reservations for it...

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 24 May 2011 15:40:40 -0700

> assuming a framework with just 1 NMS and no operator

This is just my experience.  Of course, our customers usually leave open
CLI/WebUI access but, presumably, the access-control for those interfaces
is not impacted by NACM (right?)

> Assuming a vendor-specific RBAC implementation will deal with it just
> proves there is a need for a standard solution.

What I would like to see is a standard RBAC/ACM abstraction that would 
apply to all interfaces.  That is, vendors would read/write the IETF
namespaced ACM data-model to/from their internal data-model, such that
it affects all user interfaces.  This is the pattern that I wrote about
here:

  http://www.ietf.org/mail-archive/web/netconf/current/msg06925.html

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 24 May 2011 16:16:34 -0700

> is not impacted by NACM (right?)

not officially.

>    http://www.ietf.org/mail-archive/web/netconf/current/msg06925.html

This is a message on the system notifications draft...

It is too difficult to write adequate standards that apply to unspecified
proprietary CLI or other UI interfaces.

We will map the same data model ACM rules for CLI and NETCONF access
for the portions of our implementation where the NETCONF and CLI data models
are basically the same.  But it is outside the scope of the NETCONF WG charter
how this is done.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 24 May 2011 22:41:55 -0400

>will deal with it just proves there is a need for a standard solution.

My assumption is that the admin that configured the application's
user permissions will give it sufficient to perform whatever actions
are needed/desired, and the number of admins using netconf to provision
that initial access will be extremely low.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 May 2011 09:38:12 -0700

Whether the admin uses a proprietary data model or a standard data model
to configure the application's permissions is a business/technical
decision each vendor can make for themselves.

How often access control is configured is relative to the applications
in use.  You have made it clear that you do not see any need to
have a standard access model and you are happy continuing to use your
own data model.

At this point the charter discussions are over for NACM.
If other people think we should rewrite the charter or throw
out the work item, they should speak up sooner rather than later.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Shafer
Sent: Tuesday, May 24, 2011 7:42 PM
To: Andy Bierman
Cc: netconf
Subject: Re: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question

Thanks,
 Phil

---

From: Kent Watsen <[email-masked]>
Date: Wed, 25 May 2011 10:59:17 -0700

>This is a message on the system notifications draft...

It is, but it presents a vision for having number of standard models (i.e. modules/capabilities) for managing the whole device, not just a view as seen via NetConf.  Note that the list includes "user management", which is much of what the NACM I-D provides...

> proprietary CLI or other UI interfaces.

I didn't mean to imply that.  I meant that the standard model would reflect access to the data, regardless which interface is used to access the device. 

> are basically the same.  

Yes, exactly, this is what I'd hope

> But it is outside the scope of the NETCONF WG charter how this is done.

I agree that *how* it's done is out of scope, but that it *is* done is what I want.   I want the access-control to apply the device as a whole, not just when accessed via NetConf.

PS: Going back to by first post on this, I wrote "It's unclear why this problem needs to be solved".  I should take that back.  I do want standard models for many device features, including access-control or, with a slightly increased scope, user-management.