Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

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