Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <kent+ietf@watsen.net> Fri, 24 May 2019 20:18 UTC

Return-Path: <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E544D12004C for <netconf@ietfa.amsl.com>; Fri, 24 May 2019 13:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5bRFtqvC29J for <netconf@ietfa.amsl.com>; Fri, 24 May 2019 13:18:44 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4399120345 for <netconf@ietf.org>; Fri, 24 May 2019 13:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1558729122; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=LAR+0s4mdVBc/YspGYwh5OgbQzv+5umyZ8VyZdRLR1Q=; b=DLfn1F9/Y36Nj+nSP7ODA13mARF1RVmMQt/dNqNSTetMT0VHyVlSus+f2D8EaM1p soGhaXn2RC9cr2DOY54n7hZyqqEgoT7EOcF3SDTrO/x7I4A7FnYvwlAqZHZG9FjLaeV ihSYyptjSBqU+YmulR5uiXuCpFyMclkjXCDxYv9w=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC1FEB00-3ED2-4835-91D2-F1552FF06B78"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 24 May 2019 20:18:42 +0000
References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> <e6930b6e52a642bda9f1bd76731ce9c3@XCH-RCD-007.cisco.com> <20190507.141926.1879619200930898148.mbj@tail-f.com> <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com> <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de> <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com>
To: "netconf@ietf.org" <netconf@ietf.org>
In-Reply-To: <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com>
Message-ID: <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@email.amazonses.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.05.24-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/OKkxqRv4jtdLIIaIcIlGcSGvBfg>
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2019 20:18:48 -0000

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 <kent+ietf@watsen.net>; 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
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf