Re: [netconf] ietf crypto types - permanently hidden

[Balázs Kovács <[e-mail]>]

Hi Kent,

In case of crypt-hash, I can accept the extension of the crypt(3) schemes with a $0$ that sort of represents a hash() action, since it matches the original crypt(3) syntax.

In this case, I find it awkward to tell what to do with the data (verbs) as prefixes of the data. I personally preferred actions better for this purpose. I assume that this representation also does not change the matter of "actions" affecting configuration (see 'output' values). Also validation of required input and output seems more complicated to me.

The generate action returning the name of the key or optionally creating configuration sounded so far the closest match to me.

I'm also thinking do we need the 'generate-and-not-hide' and the 'install-and-hide' use cases?

Br,
Balazs


From: netconf <[e-mail]> On Behalf Of Kent Watsen
Sent: Friday, May 24, 2019 10:19 PM
To: [e-mail]
Subject: Re: [netconf] ietf crypto types - permanently hidden


The message below was sent two weeks ago.   As a matter of expediency, I will assume there are no objections to this "crypt-hash"-like proposal.

Thanks,
Kent  // contributor





On May 11, 2019, at 12:18 PM, Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:


Hi Juergen,



I discussed this option in my "wide-screen needed" email from last Friday.
There are 3 cases to consider:

1) the manufacturer creates the (most likely "hidden") key pair and associated certificate.
    - these nodes MUST originate in <operational> (origin="system")
    - clients MUST replicate their (potentially encrypted or "permanently-hidden"
      enumerated) content into <running> in order reference the key and/or cert.

The question is what or how much needs replication. We refer to
hardware interfaces created by the manufacturer (and identified during
system startup - or during hotplug procedures) by having a name
binding of config in <running> to operational state in <operational>.
If you configure eth0, then this config binds to an <operational>
interface with the same name. So if there is a key pair created by the
vendor, perhaps all we need is a kind of a name that can be used to
bind the config to the key.

True, it could to a handle, but it's unclear what the handle would be.  We'd probably have to create one just to resolve this issue.



2) the client wishes to generate a key (hidden or not) without ever touching the
  private key.
    - presumably this occurs via a "generate-key" action (open to ideas)
    - this key ultimately MUST be in <running> in order to be referenced by config.

Perhaps the question is whether this is 'the key' or 'the name of the
key'.

Same as above.



    - ideally it shows up in <running> as consequence of invoking the action.
    - less ideal, as in (1), a <get-data>/<edit-data> sequence could be used
      to bring the key into <running>.

Would it help if "generate-key" simply returns a name for the new key?

Perhaps, I'd have to think through it more but, first, I want to dig a little more on the "crypt-hash" approach (see below).



3) the client wished to installed a hidden key.
    - note that we don't discuss installing a non-hidden key here, because
      that is exactly what a standard <edit-config> operation does.
    - presumably this occurs via a "install-key" action (open to ideas)
    - this is a weird case because the client is initially okay with touching the
      private key, but thereafter wants it to be protected by the system.
    - again, as with (2), ideally the key shows up in running as consequence
      of the action, but a round-trip could also get it there.

/js



Switching gears, I'd like to explore more the idea of reverting the 3-tuple back to "mandatory true" as discussed here: https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY but, instead of using `action` statements, perhaps we can use something similar to "crypt-hash".

>From RFC 7317:

    typedef crypt-hash {
      type string {
        pattern
          '$0$.*'
        + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
        + '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
        + '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
      }
      description
        "The crypt-hash type is used to store passwords using
         a hash function.  The algorithms for applying the hash
         function and encoding the result are implemented in
         various UNIX systems as the function crypt(3).

         A value of this type matches one of the forms:

           $0$<clear text password>
           $<id>$<salt>$<password hash>
           $<id>$<parameter>$<salt>$<password hash>

         The '$0$' prefix signals that the value is clear text.  When
         such a value is received by the server, a hash value is
         calculated, and the string '$<id>$<salt>$' or
         $<id>$<parameter>$<salt>$ is prepended to the result.  This
         value is stored in the configuration data store.
    <snip/>


Note that the last sentence says "stored in the configuration data store".
So how about this (note: all 3 values are "mandatory true"):


   leaf algorithm {
     nacm:default-deny-write;
     type asymmetric-key-algorithm-ref;
     mandatory true;
     description
       "Identifies the key's algorithm.";
   }


   leaf public-key {
     nacm:default-deny-write;
     type union {
       type binary;
       type string {
         pattern
         + '<value-to-be-generated(-and-hidden)?>'
         + '|<value-to-be-hidden>[A-Za-z0-9+/]+[=]{1,3}';
       }
     mandatory true;
     description
       "
       Binary is used for a standard configuration value.

       Prefix values are used to support special use-cases as follows:

         <value-to-be-generated(-and-hidden)?>

           An input value that is used to request the system to
           generate the key-pair.

           Without the optional '-and-hidden' postfix, the generated
           key pair is stored in the configuration data store.  This
           is used to support the security best practice use case
           whereby the client doesn't touch the private key.

           With the optional '-and-hidden' postfix, the key pair is
           generated in such a way that it will thereafter be reported
           either using '<permanently-hidden>' or '<encrypted by='*'>'.

           When the '<value-to-be-generated(-and-hidden)?>' prefix is
           used, it MUST be used in both the 'public-key' and 'private-
           key' values.

         <value-to-be-hidden>[A-Za-z0-9+/]+[=]{1,3}

           An input value that is used to request the system to
           store the provided key-pair in such a way that it will
           thereafter be reported either as '<permanently-hidden>'
           or '<encrypted by='*'>*'.

           Following the prefix is the base64-encoded value of the
           public key.

           When the '<value-to-be-hidden>' prefix is used, it MUST be
           used in both the 'public-key' and 'private-key' values.
       ";
   }


   leaf private-key {
     nacm:default-deny-all;
     type union {
       type binary;
       type string {
         pattern
           '<permanently-hidden>'
         + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'
         + '|<value-to-be-generated(-and-hidden)?>'
         + '|<value-to-be-hidden>[A-Za-z0-9+/]+[=]{1,3}';
       }
     mandatory true;
     description
       "
       Binary is used for a standard configuration value.

       Prefix values are used to support special use-cases as follows:

         <permanently-hidden>

           An output value that is used by the system to indicate
           that the private key value is not available in any form.

         <encrypted by='*'>[A-Za-z0-9+/]+[=]{1,3}

           An output value that is used by the system to indicate
           that the private key value is encrypted using the key
           identified by the 'by' attribute.

           Following the prefix is the base64-encoded value of the
           encrypted private key.

         <value-to-be-generated(-and-hidden)?>

           An input value that is used to request the system to
           generate the key-pair.

           Without the optional '-and-hidden' postfix, the generated
           key pair is stored in the configuration data store.  This
           is used to support the security best practice use case
           whereby the client doesn't touch the private key.

           With the optional '-and-hidden' postfix, the key pair is
           generated in such a way that it will thereafter be reported
           either using '<permanently-hidden>' or '<encrypted by='*'>'.

           When the '<value-to-be-generated(-and-hidden)?>' prefix is
           used, it MUST be used in both the 'public-key' and 'private-
           key' values.

         <value-to-be-hidden>[A-Za-z0-9+/]+[=]{1,3}

           An input value that is used to request the system to
           store the provided key-pair in such a way that it will
           thereafter be reported either as '<permanently-hidden>'
           or '<encrypted by='*'>*'.

           Following the prefix is the base64-encoded value of the
           private key.

           When the '<value-to-be-hidden>' prefix is used, it MUST be
           used in both the 'public-key' and 'private-key' values.
       ";
   }



Kent // contributor


_______________________________________________
netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf