Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt

From: "Andy Bierman" <[email-masked]>
Date: Wed, 03 Aug 2011 11:33:57 -0700

I do not agree that customers expect a proprietary NMS to be responsible for all RBAC.  Some of our customers insist that device have a configurable RBAC system.  

Our netconf vendor is planning to implement this data model and we plan to deploy it.

Andy

----- Reply message -----
From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, Aug 3, 2011 10:31
Subject: [Netconf] Reminder: WG Last Call for	draft-ietf-netconf-access-control-04.txt
To: "Kent Watsen" <[email-masked]>
Cc: "netconf" <[email-masked]>

On 8/3/11 4:55 PM, Kent Watsen wrote:
> Next I question the utility of the I-D.  IMO, the purpose for common data-models is so an off-box tool (NMS) can interoperate with many devices.  As I wrote before (see above link), this typically results in the NMS logging into*all*  the devices with root-like permissions and then itself presenting its own RBAC model to its users.  With this in mind, it seems that this I-D only impacts tools that talk to one device at a time, such that when it is interacting with the device, it can use the device-provided NACM model to restrict access to stuff in its UI.  This use-case is weak as it seems customers would more likely use a device's native management interfaces (Web, CLI, etc.)
>
> I understand that this I-D is chartered work and my comments aren't very helpful towards reaching that goal, but I can't support this I-D in its current form either knowing that it won't be picked up by Juniper.

Thanks for repeating (and explaining) your statement that you made earlier (as pointed to
by your email) as well. On that earlier note, nobody picked up on that, so my personal
conclusion there is that nobody had similar strong feelings.
At the same time, I guess I can conclude that not many people really object too
strongly either. The latter could be for several reasons:
- they did not see the need to express objection (to your note) because
  they figured the support FOR doing this work was/is much bigger
  than the objections AGAINST this work.
- they do not strongly object and will let the market decide once the
  standard has been approved.
- they certainly do not agree strongly, because if they oppose this work, then
  they SHOULD have made objections at the time we asked if the WG wants to
  be chartered or not.

Personally, I can see the Juniper approach that you describe. And for controlling
user access to the configurations, I think it makes sense. Nonetheless, you want
some access control at every box to make sure that people with sll sorts of client
NETCONF tools do not accidentally access your box.
I also wonder how your/a multi-vendor NMS then deals with getting access to all
boxes of different vendors? Are you going to qwork with all their proprietary
access control mechanisms? Or would you rather prefer one single standard access control
mechanism? I would prefer a standard.

And if I have a multi-vendor NMS station that controls end-user access through the
UI as you suggest, then I will put very strict access control on my managed devices.
I will use the standardized NACM for that. And at the same time, we allow for
people who do not use these fancy (possibly expensive) multi-vendor NMSes to
still do their own thing.

The above was my personal opinion.
The below is my view as co-chair of the WG:

So, unless other people strongly support your view, we will mark your comments
as one viewpoint that has been expressed, and we will (as a WG) continue
to work towards finalizing this WG work item.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 3 Aug 2011 12:23:20 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Bert (IETF) Wijnen" <[email-masked]>; "Kent Watsen" <[email-masked]>
> Sent: Wednesday, August 03, 2011 11:33 AM
> Subject: Re: [Netconf]Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt
>

> I do not agree that customers expect a proprietary NMS to be responsible
> for all RBAC.  Some of our customers insist that device have a configurable
> RBAC system.  
...

In further support of what Andy wrote -

Giving responsibility the access decision function to the NMS
seems seriously at odds with the principle of least privilege.

Randy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 3 Aug 2011 14:23:19 -0700

Bert,

  To your WG co-chair comment, that is how I had hoped it would be interpreted, thanks.

Andy,

  Both NMS and devices must have RBAC systems, at least so long as they're Common Criteria certified.  Our NSM has been able to provide path-based access to configuration for a long time now.  It's necessary for it to do this because it also supports the concept of live configuration templates that are applied to many devices at once.  Further, the NMS supports high-level abstractions that have to be compiled down to device-specific data models, again emphasizing the need for the NMS to implement the RBAC.  I never said devices shouldn't have configurable RBAC systems, only that their RBAC is not configured much in an NMS environment.  Again, I think this I-D may be helpful for new device development efforts, and even for a device-specific EMS, but once you get to the NMS-level, it doesn't matter much anymore since the abstractions negate the need for device-specific interactions.

Randy,

  It is still with the concept with least privilege.  I wrote that the NMS "typically" has root-like access because sometimes a customer can provide a restricted account instead (e.g. for PCI DSS compliance), and we support that case too, but this is exceedingly rare since the reason most customers installed the NMS in the first place was to manage the *entire* device, which requires the root-like access.  One interesting data point to this discussion would be to know what the operator-specific systems are doing - that is, are their systems also typically logging into devices with a root-like account or not...

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Aug 2011 18:04:20 -0700

On 08/03/2011 02:23 PM, Kent Watsen wrote:
> Both NMS and devices must have RBAC systems, at least so long as they're Common Criteria certified.  Our NSM has been able to provide path-based access to configuration for a long time now.  It's
> necessary for it to do this because it also supports the concept of live configuration templates that are applied to many devices at once.  Further, the NMS supports high-level abstractions that
> have to be compiled down to device-specific data models, again emphasizing the need for the NMS to implement the RBAC.  I never said devices shouldn't have configurable RBAC systems, only that
> their RBAC is not configured much in an NMS environment.  Again, I think this I-D may be helpful for new device development efforts, and even for a device-specific EMS, but once you get to the
> NMS-level, it doesn't matter much anymore since the abstractions negate the need for device-specific interactions.
>
>

Some people want a standard RBAC model in the NETCONF server.
Perhaps every vendor will continue using their own data models.
Perhaps not.  We do not standardize NMS applications in the IETF,
so that seems out of scope.

I don't understand the comment about device-specific data models.
The point of a standard data model is to configure access control
for a user/session based on the standard abstraction model, i.e.,
protocol operations, notifications, and YANG datastore content.

Andy

> Randy,
>
> It is still with the concept with least privilege.  I wrote that the NMS "typically" has root-like access because sometimes a customer can provide a restricted account instead (e.g. for PCI DSS
> compliance), and we support that case too, but this is exceedingly rare since the reason most customers installed the NMS in the first place was to manage the *entire* device, which requires the
> root-like access.  One interesting data point to this discussion would be to know what the operator-specific systems are doing - that is, are their systems also typically logging into devices with
> a root-like account or not...
>
>
> Thanks, Kent
>
> _______________________________________________ Netconf mailing list [email-masked] https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 3 Aug 2011 19:54:26 -0700

Hi -

> From: "Kent Watsen" <[email-masked]>
> To: "netconf" <[email-masked]>
> Sent: Wednesday, August 03, 2011 2:23 PM
> Subject: Re: [Netconf] Reminder: WG LastCall for draft-ietf-netconf-access-control-04.txt
...
>   It is still with the concept with least privilege.  I wrote that the NMS
> "typically" has root-like access because sometimes a customer
> can provide a restricted account instead (e.g. for PCI DSS
> compliance), and we support that case too, but this is exceedingly
> rare since the reason most customers installed the NMS in the first
> place was to manage the *entire* device, which requires the root-like
> access.

As soon as there is more than one NMS, or aspects of the device
are of interest to more than one administrative domain, the argument
that putting the access decision function in the NMS would somehow
be consistent with the principle of least privilege does not hold. 

Randy