Re: [netconf] ietf crypto types - permanently hidden

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 29 March 2019 20:53 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 646D412036F for <netconf@ietfa.amsl.com>; Fri, 29 Mar 2019 13:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 F_bwItIw7hLK for <netconf@ietfa.amsl.com>; Fri, 29 Mar 2019 13:53:26 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32EE120366 for <netconf@ietf.org>; Fri, 29 Mar 2019 13:53:25 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 24C0B6CF; Fri, 29 Mar 2019 21:53:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id OhjnqTFWw_N4; Fri, 29 Mar 2019 21:53:18 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Mar 2019 21:53:18 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id D09F3200A8; Fri, 29 Mar 2019 21:53:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id diTm0feoxKsL; Fri, 29 Mar 2019 21:53:18 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 1EA73200A7; Fri, 29 Mar 2019 21:53:18 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 29 Mar 2019 21:53:17 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 0B8493007A4129; Fri, 29 Mar 2019 21:53:16 +0100 (CET)
Date: Fri, 29 Mar 2019 21:53:16 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Balázs Kovács <balazs.kovacs@ericsson.com>, tom petch <ietfc@btconnect.com>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Kent Watsen <kent+ietf@watsen.net>, Balázs Kovács <balazs.kovacs@ericsson.com>, tom petch <ietfc@btconnect.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <VI1PR07MB4735863E79020AD84C4FDF9483420@VI1PR07MB4735.eurprd07.prod.outlook.com> <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> <VI1PR07MB47355E3E3C5D703122258C2583430@VI1PR07MB4735.eurprd07.prod.outlook.com> <00b701d4e0cb$e79e9660$4001a8c0@gateway.2wire.net> <01000169ac01ff08-27f75526-1e78-461a-be8e-9737cf762edf-000000@email.amazonses.com> <VI1PR07MB47351FF76BBF6C56AC6E64B5835E0@VI1PR07MB4735.eurprd07.prod.outlook.com> <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/xo9y2ckuiJ1g7LvlsXyF0a4NWpM>
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, 29 Mar 2019 20:53:30 -0000

I agree, I think we need to distinguish

- upload of keys
- generation of keys on the box that become (protected) configuration
- generation of keys on the box that will to into hardware protected
  storage (and never be accessible)

and the creation of a private key that becomes (protected)
configuration is similar to the creation of a user account, where an
unused uid is allocated that becomes configuration.

/js

On Fri, Mar 29, 2019 at 08:25:26PM +0000, Kent Watsen wrote:
> Hi Balazs,
> 
> > In some implementations I can understand that backup/restore is via YANG interface, but backup/restore is possible by other methods too.  On the other hand, the private key material should be created and kept on the owner device according to best security practices and certification done by for example a certificate signing request.
> > 
> > In that sense the generate-hidden-key action and the CSR creation action are solving the most common need for handling keys, and that is really regardless if the key is stored in a TPM, a file system, or centralized KMS.
> 
> True.
> 
> > I personally was fine with 'hidden' and I was also ok with the current actions, it was only the descriptions that seemed to be restrictive to TPM usage, thus I was asking some clarification. However, if 'hidden' is not true this way, then just call it 'generate-key'. Would that then create a binary string for the 'private-key' in operational too instead of 'permanently-hidden' thus you are referring to a 3rd option?
> 
> As I understand it, your intention is to have users 1) use actions to generate private keys and CSRs and 2) that the private-key value is otherwise inaccessible to the users.   I don't believe you have a concern with the keys being "configuration" (since the nacm:default-deny-all makes the value inaccessible), and that the only bad part with the current model is that the user has to pass the private key value, which is bad because a) they are aware of the private key value and also it's possible that the private key value they generate is poor quality (e.g. having low entropy).
> 
> This is effectively what was defined on page 22 in https://tools.ietf.org/html/draft-ietf-netconf-keystore-00 <https://tools.ietf.org/html/draft-ietf-netconf-keystore-00> (we moved to the current strategy in the next version of that draft where (surprise!) the enum was called "INACCESSIBLE".   Some more history is here: https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez48 <https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez48>.
> 
> The main problem with this is actions don't typically create configuration, though we certainly could define this action as doing so (i.e., it locks <running> when called)...and we might even see ourselves doing this even for keys that are *interactively* generated by a cryptographic processor.  Of course, any keys generated by the vendor during manufacturing (i.e., the IDevID key) would still be operational state.
> 
> In order to support systems that have crypto processors, since it may not be desirable to use the cryptographic processor for all keys, we need either a parameter or another action to direct the system to use the crypto processor to generate the key.
> 
> Regarding what does "inaccessible" mean, the intention is that the value is not accessible for reasons beyond access control, with this driving use-case being a cryptographic processor.   Since the term (inaccessible) is being used in a YANG module, it stands to reason that it applies to all YANG-driven interfaces and that there is no statement regarding how it may or may not be "inaccessible" in other interfaces.  That said, the goal of YANG modules is to model reality, not just a view presented by YANG-driven interfaces, and I imagine great confusion ensuing if mismatches exist across interfaces.
> 
> I agree that the description statement for the "permanently-hidden" enumeration can be improved, how about this?
> 
>     leaf private-key {
>       nacm:default-deny-all;
>       type union {
>         type binary;
>         type enumeration {
>           enum permanently-hidden {
>             description
>               "The private key is inaccessible due to being
>                protected by the system (e.g., a cryptographic
>                hardware module).";
>           }
>         }
>       }
>       ...
>     }
> 
> Notes:
> 
> 1) I removed the "It is not possible to configure a permanently hidden key, as a real private key value must be set." text because it was confusing and yet what's intended is self-evident (i.e., the leaf is a union of a value and an enum, only one can be passed).
> 
> 2) I removed "Permanently hidden keys cannot be archived or backed up." text because it was a bit overreaching.  As mentioned, even TPM-protected keys can be backed-up/restored if shrouded and the restoration is to the same machine.  The more correct statement is "RMA workflows are limited", but it doesn't need to be said here.
> 
> 
> If the goal is to open up these actions for general use, I think that we SHOULD update them to generate *configuration*.   Clearly the intent is that keys are configuration, use of the action should be seen as supporting a best practice, but otherwise shouldn't change the characteristic that interactively-generated keys are configuration.
> 
> Thoughts?
> 
> Kent // contributor
> 
> 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>