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

From: Wes Hardaker <[email-masked]>
Date: Mon, 01 Aug 2011 09:27:18 -0700

>>>>> On Fri, 29 Jul 2011 12:31:19 -0400, "Bert (IETF) Wijnen" <[email-masked]> said:

BW> Pls review BEFORE or BY August 1 if you have not already done so.
BW> A "I read it and see no issues or have no concerns" is also very welcome!

I read this document on the way home.  There is no really easy way to
say this, so I'll be blunt: this document is not ready to go forward.
I'm very happy that this document exists and is trying to go forward,
and I very much want a standardized access control model, so I'm making
this statement even knowing it'll hamper my desire to get something
standardized.

Though I have technical comments too, the real show-stoppers were the
document layout and readability.  I started marking up the paper with
editorial notes and wording suggestions, but eventually started marking
only the major issues.  So the items listed below are a summary of the
larger issues I have and I skipped documenting my minor-edits.

Unfortunately, my available time in the next month especially is pretty
much non-existent (which is why I read it on the plane: I knew I
couldn't get to at all otherwise).  I'd love to help out with some real
edits, but my time [and job] won't permit it.  I feel guilty dropping
this on the doorstep, but I don't have another alternative.  I suppose
that gives you the right to say "not helpful" and delete this message :-)

== Document structure issues ==

* Document structure: requirements vs NACM definition

  The document actually tries to do 2 things: 

     + define a set of requirements that every netconf ACM must fulfill
     + define an instance of a netconf ACM that meets some of the requirements

  The problem is that the document isn't divided into parts that make
  this double-role readable.  Section 2 is listed as "access control
  design requirements" but isn't really worded with an introduction that
  indicates this and is also sprinkled with text that seems to apply to
  the specific implementation of the requirements too (eg, 2.4.1 isn't
  really a requirement but is one implementation).

  IMHO, if we need to define a set of requirements they should really be
  in a separate draft.  The choices I see to go forward:

  1) split the requirements into a second draft
  2) remove the requirements and don't try to state what NACM is being
     held up against.
  3) do a really good job separating them from the NACM specific implementation

* Section 2 even starts off with an "Editor's note", which made me
  immediately wonder if I really was reading the "last call" document,
  but I checked in the second airport to confirm I really was reading
  the most recent version.  Multiple other "Editor's notes" exist in the
  document as well and certainly shouldn't be there.

* Figure 1 makes no sense as currently drawn.  It likely needs some
  missing arrows or something (and it's also not referenced anywhere in
  the text).

* Notification content is referred to in a number of places restricting
  access on "event types" but doesn't discuss other included data that
  will go along inside the notification.

== Technical Reservations ==

* I'm not convinced, but not against, that a single ACM model should be
  applied across candidate, running and startup.  I could see not
  wanting people to copy the config from running to startup, eg.

* I'd make the text more clear about that access control is only applied
  to netconf sessions.  In a few places it says things like "after
  boot", etc, but the wording is fuzzy.  Simply stating that it is only
  applied to operations received over the netconf protocol would make it
  more clear.

* the security considerations needs to discuss that the protocol can be
  used to probe for information via some of the error/no-error cases
  that are discussed in a few places.

* The whole "read and execute" by default still makes me cringe inside.
  Especially with the execute bit being on by default.  The ACM should
  stop a user from executing a command that twiddles configuration,
  because the write-access implemented within an rpc operation would be
  trumped on data-modification.  But I could certainly see people
  defining dangerous execute operations that don't twiddle config.  EG,
  does the equivalent of "<interface-down>" actually modify config data
  (insert long standing debate about control vs config data here).  Or
  what about "<clear-counters>" (which hasn't been written yet, but
  thinking about the future is critical in cases like this).

  Fortunately, not every system user will have netconf access without
  being assigned into a group.  This is straight forward for groups that
  were configured manually, but is much less so for group memberships
  configured via RADIUS or another "central server" outside the box.

* 2.4.4 (copy-config) needs a discussion on data deletion too.

* 2.4.4 (copy-config) discusses that a operator MUST have full read
  access but doesn't say what happens when an operator doesn't.

* 2.9 (data shadowing) fails to bring a clear point to the text and
  seems to be discussing actually two different topics.

* 3.1.3 (Message Processing Model) Is figure 2 a netconf standard
  processing model?  Is implementing this flow as is a requirement?  The
  document doesn't state this (or is it an "example" model).

* 3.1.3 (and other places) mentions that the close-session message is
  exempt from processing.  I think it'd be easier to define a list of
  message types that *don't* get access control processing with only a
  single entry in it for the time being.  But doing it this way would
  let other documents add to the list, if need be, and the named list
  could be used consistently in the rest of the document.

  Sub question: is the <hello> message technically an RPC message or not?
  (I didn't read other documentation to find out).

* 3.1.2 (users) needs to discuss naming conflicts.  I believe the
  document intentionally shys away from this, but that doesn't solve the
  problem.  At a minimum the security consideration section needs to
  mention that users coming in over the different channels may have the
  same user name since the users are not zoned by incoming protocol.

* 3.2.5.3 write-default switch: does this apply to create, update and
  delete uniformly.  If so, it needs to be stated.

* 3.3.2 session establishment: why is the prohibition against sensitive
  data in the capability elements a SHOULD NOT and not a MUST NOT?

* 3.3.5 and following: the rules don't discuss what happens when data
  exists in the config that doesn't exist (but maybe should).  IE, what
  happens when the access-operations node doesn't exist?  The default
  for a access-operations is a '*' but what if a user deletes the config
  node?

  (the answer is probably mostly obvious but needs to be stated; though
  some would argue that if the result is supposed to be a 'deny' and
  there is missing data, then it should always deny by default because
  the rule is broken and you shouldn't skip it, where as a 'permit' rule
  should deny by default with missing data)

* The "secure" and "very-secure" names are cute, but they're generally
  meaningless to the reader.  I'd suggest renaming them to keywords that
  include the functionality underneath.  Maybe:

     secure        -> nacm:default-deny-modification
     very-security -> nacm:default-deny-all

* yang model:

** user-name-type max: implementations must support any string length
   that a transport model returns for a user name?  Even if it's really
   long (consider a base64 name of an x.509 certificate; yes I realize
   this example is silly).

** node-instance-identifier

   So xpath 1.0 is required for nacm, right?  What happened to the whole
   "we can't make everything require xpath because it's too much
   overhead" from the early netconf days.  Or is it expected that
   devices that don't want to do xpath won't want access control mechanisms?

* installing yang models into devices may change the security
  ramifications on the system.  EG, if the internal implementation is
  reading yang modules to apply access control settings on (IE, they're
  not hard-coded but the definitions are read from a .yang file itself),
  then a user might have a way to install a new version of the module
  without the yang:very-secure flags, etc, thus suddenly allowing
  access.  I'd mention this in the security considerations at a minimum.

* somewhere (security considerations) should mention that when editing
  rules on the running config container, it is critical to insert rules
  in an order that doesn't give access to users by mistakenly inserting
  the permissive rules before the denial rules.  There is a paragraph in
  the security considerations that hints at this, but I'd make it more
  clear by stating "operators should insert denial rules first" or
  something and specifically mention that the running container is
  critical to get right.

* the security considerations (and maybe elsewhere) should discuss data
  references, where dealing with external keys, etc, are explicitly
  spelled out.

* might want to list rollbacks, etc, somewhere as write-operations that
  need to be checked too.

* Nowhere does it discuss what it means to lock (or partial-lock) a
  container when you don't have access to the whole container.

* If the exmaples in A.3 don't have an end "deny-all" rule or
  "permit-all" rule, then text needs to be inserted stating what will
  happen to help the user understand the dependency on the global flags,
  etc.

* A.3, example rule-list #2: access-operations is 'exec' but the comment
  talks about writing.

* A.3, since the "monitor" group is used in many places to provide more
  than just monitoring access, I'd suggest renaming the group to
  "limited" or something.

-- 
Wes Hardaker
SPARTA, Inc.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 01 Aug 2011 09:46:34 -0700

On 08/01/2011 09:27 AM, Wes Hardaker wrote:
>>>>>> On Fri, 29 Jul 2011 12:31:19 -0400, "Bert (IETF) Wijnen"<[email-masked]>  said:
>

I think you should review the next version.
Many of the issues you raise are going to be addressed,
and were already raised by Juergen.  Will will look at
your new issues as well.

The normative text will be moved from the objectives section,
but a separate draft for objectives is already out of scope.

>    document as well and certainly shouldn't be there.

This was resolved at the WG meeting and will be finalized in the next rev.

>    missing arrows or something (and it's also not referenced anywhere in

It will be redrawn, along with some changes to fig. 2

>    will go along inside the notification.

this inside data is out of scope.
NACM only filters notifications on event type, not the contents.
Same for protocol operations that do not touch a datastore.

One lesson from VACM: you can make access control so hard to use,
that it doesn't get used.

>    Sub question: is the<hello>  message technically an RPC message or not?

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 01 Aug 2011 14:14:16 -0700

AB> The normative text will be moved from the objectives section,
AB> but a separate draft for objectives is already out of scope.

Just make sure it's *really* clear that you're defining ACM requirements
in the same document as you're defining an ACM itself.

AB> This was resolved at the WG meeting and will be finalized in the
AB> next rev.

FYI, I should have mentioned I had to miss both the netconf and netmod
meetings because of conflicts with real paid work (which always has to
take priority).  Sorry if I've mentioned things that were already
mentioned there.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 01 Aug 2011 14:18:26 -0700

> in the same document as you're defining an ACM itself.

OK -- that is the plan.

> take priority).  Sorry if I've mentioned things that were already

Well it would have helped to have a f2f discussion on these issues,
even in the hallway.  At least you read the draft on one of your flights.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 3 Aug 2011 07:55:48 -0700

> Pls review BEFORE or BY August 1 if you have not already done so.
> A "I read it and see no issues or have no concerns" is also very welcome!

I continue to struggle with why this is an important problem to solve (see http://www.ietf.org/mail-archive/web/netconf/current/msg06962.html).

First off, from an implementation perspective, I feel that this I-D would only be implemented for green-field developments.  Having a common access-model for those systems would be nice indeed, but I don't imagine any existing Juniper or similar gear ever supporting it.  This means it has little impact for a multi-vendor NMS, which is my focus.  Keep in mind that this data-model is different than others that we might talk about in that it's not just an abstraction, it goes to the core of how the device works.  Presumably this I-D only impacts the NetConf interface, but vendors will likely not see it that way after needing to pass a Common Criteria certification.

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,
Kent

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 03 Aug 2011 19:31:35 +0200

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.)
>

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

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 04 Aug 2011 09:11:01 +0200

We did not get any requests for extension of the WGLC end date.
So WGLC has ended for this document.

The authors will address all comments with a new revision.

Bert and Mehmet

On 7/29/11 6:31 PM, Bert (IETF) Wijnen wrote:
> WG participants,
> I case you need a couple of days extra time (and commit a date for
> your review), we're willing to consider a short extension.
>
> Bert and Mehmet
>
> -------- Original Message --------
> Subject:     [Netconf] WG Last Call for draft-ietf-netconf-access-control-04.txt
> Date:     Wed, 13 Jul 2011 16:53:24 +0200
> From:     Bert (IETF) Wijnen <[email-masked]>
> To:     netconf <[email-masked]>
>
>
>
> Dear WG participants,
>
> This document was published mid-June, and we have not had much comments
> sofar. So we conclude it must be ready for WG Last Call.
>
> This is a formal WG Last call for draft-ietf-netconf-access-control-04.txt
> Please review and send any comments BEFORE August 1.
> Best would be if you can send it BEFORE July 24, so that we can discuss
> any open issues during our Netconf session at IETF81 in Quebec.
>
> Bert and Mehmet
>
>

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 04 Aug 2011 09:16:39 +0200

My quick evaluation as co-chair:

- quite a set of good comments/concerns from various reviewers
    will be addressed by editors/authors in a new revision
- we got a commitment from our Securoty Advisor (Tim Polk) that he will review
    as well and give us feedback. If he is timely, then authors will address his
    comments in new revision. If not, then he will review the next revision
- The comments from Kent Watson ("abandon this I-D and this work, it is
    not needed") was already brought up when we started/chartered the work.
    Nobody seems to have picked up on that and so Kent seems to be the
    lonely dissenter in this case. So I consider this matter closed
    and I read WG consensus that the WG DOES want to finish and standardize
    this work.

Bert (speaking as co-chair)

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 4 Aug 2011 17:50:53 +0200

>     and I read WG consensus that the WG DOES want to finish and
standardize

This is also my understanding.

Mehmet 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> ext Bert (IETF) Wijnen
> Sent: Thursday, August 04, 2011 9:17 AM
> To: netconf
> Subject: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access-
> control-04.txt
> 
> - we got a commitment from our Securoty Advisor (Tim Polk) that he
will
> review
>     as well and give us feedback. If he is timely, then authors will
address
> his
> >> Subject:     [Netconf] WG Last Call for
draft-ietf-netconf-access-control-
> 04.txt
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Aug 2011 10:38:59 -0700

Just to be clear, I didn't say to abandon it.  I just said it wasn't an important problem to Juniper, which is why I was neither supporting or not-supporting it.  Same as in the WG meeting in Quebec, I neither raised my hand in favor or against it...

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Thursday, August 04, 2011 11:51 AM
To: netconf
Subject: Re: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access-control-04.txt

Mehmet 

Behalf Of
will
address

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 4 Aug 2011 20:22:57 +0200

OK, Thanks Kent, that is a clearer statement (at least in my ears/reading).

Bert
----- Original Message ----- 
From: "Kent Watsen" <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>; "netconf" 
<[email-masked]>
Sent: Thursday, August 04, 2011 7:38 PM
Subject: Re: [Netconf] Finished WG LastCall 
fordraft-ietf-netconf-access-control-04.txt

> Just to be clear, I didn't say to abandon it.  I just said it wasn't an 
> important problem to Juniper, which is why I was neither supporting or 
> not-supporting it.  Same as in the WG meeting in Quebec, I neither raised my 
> hand in favor or against it...
>
> Thanks,
> Kent
>
>
> Subject: Re: [Netconf] Finished WG Last Call 
> fordraft-ietf-netconf-access-control-04.txt
>