Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/listinfo/netconf