Subject: [Netconf] keystore issue

From: Kent Watsen <[email-masked]>
Date: Thu, 1 Jun 2017 20:13:43 +0000

In Chicago, I had a slide like this:

  Should ‘private-key’ be a union?

  What should be the treatment for when NACM hides a value, 
  resulting in an invalid response?

      leaf private-key {
        nacm:default-deny-all;
          type union {
            type binary;
            type enumeration {
              enum "RESTRICTED" {
                description
                 "The private key is restricted due to access-control.";
              }
              enum "INACCESSIBLE" {
                description
                 "The private key is inaccessible due to being protected
                  by the cryptographic hardware modules (e.g., a TPM).";
              }
            }
          }
          mandatory true;
          description
            "A binary string that contains the value of the private
             key. The interpretation of the content is defined in the
             registration of the key algorithm.  For example, a DSA key
             is an INTEGER, an RSA key is represented as RSAPrivateKey
             as defined in [RFC3447], and an Elliptic Curve Cryptography
             (ECC) key is represented as ECPrivateKey as defined in
             [RFC5915]";
      }

Martin stated that, for NACM, the entire private-key node would be 
missing, and hence the "RESTRICTED" enumeration would never be sent.

While I'm okay with the core of this statement, and will remove the
RESTRICTED enum from the draft, I'm concerned by the implication that
servers will implement NACM.  

NACM is optional to implement, and I think not widely implemented,
and yet we're putting NACM extensions statements into all YANG modules
with some hope that it might be meaningful to all servers, even those
that don't implement NACM.  We are (at least I am) expecting that
servers implementing some other mechanism will still key off these
NACM extensions, as that is all that there is in these modules.

Currently, the description statement for default-deny-all says:

   If present, *and the NACM module is enabled* (i.e.,
   /nacm/enable-nacm object equals 'true'), the NETCONF server
   will only allow the designated 'recovery session' to have
   read, write, or execute access to the node.  An explicit
   access control rule is required for all other users.

It seems that the description statements should say something that
makes them meaningful to all servers, even those that don't use
NACM.

Thoughts?

Kent

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 1 Jun 2017 17:08:51 -0700

> On Jun 1, 2017, at 1:13 PM, Kent Watsen <[email-masked]> wrote:
> 
> 

I would agree. At the min. the description statement for default-deny-all should remove reference to “and the NACM module is enabled”. By that extension, would we change default-deny-write to also drop reference to a similar statement?

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

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Jun 2017 10:13:59 -0700

On Thu, Jun 1, 2017 at 5:08 PM, Mahesh Jethanandani <[email-masked]
> wrote:

> I would agree. At the min. the description statement for default-deny-all
> should remove reference to “and the NACM module is enabled”. By that
> extension, would we change default-deny-write to also drop reference to a
> similar statement?
>
>

This would be a non-backward-compatible change to NACM.
It is also operationally useful to allow an administrator to disable NACM to
fix a broken NACM configuration (for example).

I strongly oppse this change to NACM.

I don't see any problem having the NACM extension and "restricted" enum.
A server that implements NACM will skip the object and a server that does
not
will return "restricted".  But it would be better to simply not return the
instance
than have enums that mean "not available".

> > Kent

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 2 Jun 2017 19:42:15 +0000

> ...I'm concerned by the implication that

[KENT] How so?  we're just trying to fix the extension statement descriptions to
useful to servers that don't use NACM also...

[KENT] I'm not following, how is this related?

[KENT] Not sure why, but if it's a good reason, then I suggest we define another
set of YANG extension statements that can describe node-sensitivity in an ACM-
independent manner.  To be honest, I've never been sure that default-deny-all
and default-deny-write are sufficient in general.  For instance, why can't I flag
nodes that require elevated privileges, though not necessarily a recovery session?

I don't see any problem having the NACM extension and "restricted" enum.
A server that implements NACM will skip the object and a server that does not
will return "restricted".  But it would be better to simply not return the instance
than have enums that mean "not available".

[KENT] my original idea was to ensure that the data could still be a valid instance
of the model, even when the data is restricted, by replacing it with something that
conforms to the data model.  However, to do this universally would require models
to use a 'union' around the original type and an enum for the node that would be
otherwise restricted.  A different strategy would be needed for containers, lists, and
groupings.  All this seems ugly to me to try to do in an IETF-standard.  I think that
it might be better for each ACM solution to describe how it handles restricted nodes
(NACM snips out the offending node, XYZ replace the offending node with some
special way, etc.).  This is main reason why I removed the RESTRICTED enum...

Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Jun 2017 12:59:51 -0700

> useful to servers that don't use NACM also...

The extension statement applies to implementations of NACM. Nothing else.
Put text in the description-stmt if you want server behavior outside of
NACM.

> [KENT] I'm not following, how is this related?

the nacm extensions are only for NACM implementations.
NACM can be enabled and disabled, so this text is needed.

> nodes that require elevated privileges, though not necessarily a recovery

There is just 1 standard access control module for NETCONF and RESTCONF.
it is a SHOULD implement, not MAY implement, for servers.
I see no reason to support proprietary ACMs or start work on a different
standard ACM.

> special way, etc.).  This is main reason why I removed the RESTRICTED

IMO a better data model would be a separate leaf that described the
key-access-type
as normal, restricted, or inaccessible, instead of overloading the first
leaf with
"reasons no instance is here" semantics -- but this info is not very useful
so
I am not suggesting adding a new leaf.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 13 Jun 2017 22:06:37 +0000

Hi Andy,

The extension statement applies to implementations of NACM. Nothing else.
Put text in the description-stmt if you want server behavior outside of NACM.

<KENT> You probably know that NACM is a rather simplistic ACM model.
It might be useful for some NEs (though I don't know who's, I don’t know of
any implementations of NACM), but large-scale controller apps use more robust
models.   The IETF models are only marked up with these NACM extension-
statements.  What do you expect systems not using NACM to do?   The change
I propose is simple and does not break backwards compatibility, but it the WG
decides to not make this change to the NACM draft, then I propose we start
working on another draft that defines generic security assertion statements that
are not tied to any particular ACM implementation.

K.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Jun 2017 15:13:44 -0700

> are not tied to any particular ACM implementation.

I think it is rather easy for a developer to separate the NACM-specific
details.
Another ACM can figure out how default-deny-write and default-deny-all
applies to them.

Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 14 Jun 2017 12:26:03 -0700

> On Jun 2, 2017, at 12:59 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Fri, Jun 2, 2017 at 12:42 PM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
>  
> 

So you are suggesting that we could add something like this to the description of default-deny-all?

"If used outside of NACM module, the extension statement implies that no one has read, write, or execute access to the node. An explicit access control rule is required for all users."

> I see no reason to support proprietary ACMs or start work on a different standard ACM.
> 
> 
>  
> 
> IMO a better data model would be a separate leaf that described the key-access-type
> as normal, restricted, or inaccessible, instead of overloading the first leaf with
> "reasons no instance is here" semantics -- but this info is not very useful so

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Jun 2017 13:26:51 -0700

On Wed, Jun 14, 2017 at 12:26 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> "If used outside of NACM module, the extension statement implies that no
> one has read, write, or execute access to the node. An explicit access
> control rule is required for all users."
>
>

I was suggesting you can add that text to the keystore data model.
It seems rather odd for a YANG module (NACM or any other) to define
what its data model constructs mean in another unspecified system.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Jun 2017 20:39:09 +0000

On 6/14/17, 4:26 PM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

<KENT> Despite the subject line of this thread, what I'm talking about has to do with ALL
YANG modules (not just keystore).   More specifically, per [1], the Security Considerations
in all my drafts, talk about sensitive nodes contained within the modules, and then make a
statement regarding how that node is tagged with a specific NACM extension accordingly.
It just seems a little misleading, perhaps especially to SecDir, that these NACM annotations
have no meaning for systems that don't implement NACM which, as mentioned before, is
every system that I interact with.  Hence my desire to either update the NACM extension
statement descriptions so that they're applicable to systems that don't implement NACM, or
to start a new draft to define (likely better) extension statements that can apply to all systems,
regardless which ACM they implement.

[1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

K.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Jun 2017 14:01:06 -0700

On Wed, Jun 14, 2017 at 1:39 PM, Kent Watsen <[email-masked]> wrote:

>
>
>
>
> On 6/14/17, 4:26 PM, "Andy Bierman" <[email-masked]> wrote:
>
>
>

I don't think the current NACM text is preventing other ACMs from applying
the NACM extensions
to their own system. But I can replace "NACM is enabled" with "the ACM is
enabled".
I don't think any developers are getting stuck over the current text.
They are easily making this adjustment themselves.

There are vendors implementing and shipping NACM.  It is deployed and
available for use.
Whether it is really used by operators or not?  Not sure.

Andy