Re: [netconf] ietf crypto types - permanently hidden

Balázs Kovács <balazs.kovacs@ericsson.com> Wed, 03 April 2019 11:18 UTC

Return-Path: <balazs.kovacs@ericsson.com>
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 94DE01200C3 for <netconf@ietfa.amsl.com>; Wed, 3 Apr 2019 04:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 FpdMn5jqBB3c for <netconf@ietfa.amsl.com>; Wed, 3 Apr 2019 04:18:21 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10046.outbound.protection.outlook.com [40.107.1.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8848F120111 for <netconf@ietf.org>; Wed, 3 Apr 2019 04:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WUqw5hoossB8R6JZjbTfI182kkbH8tj6ebbcpBljRAk=; b=MiungL3VrRz44/7QzKrvwPzylAIiKW9Odo59VC4vsMV2g4sIsU0NzLGEQZYi46fumXM4DWBxWFEwPx5zV0mhe2RwYvICV35BVVi43wgVXeA02j8HqyMdtvlfl9+fIUb8j+suY5GcUFjqd11ZKFuZn6LHEVW1mAAI2uEWAQWEGR4=
Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB3117.eurprd07.prod.outlook.com (10.175.242.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.8; Wed, 3 Apr 2019 11:18:17 +0000
Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::209a:6999:a1c2:ba2]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::209a:6999:a1c2:ba2%2]) with mapi id 15.20.1771.006; Wed, 3 Apr 2019 11:18:17 +0000
From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= <balazs.kovacs@ericsson.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Kent Watsen <kent@watsen.net>, tom petch <ietfc@btconnect.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpABvbIeAAFYG6nAA2eMuAAAA+NkAAOYBpZA=
Date: Wed, 3 Apr 2019 11:18:17 +0000
Message-ID: <VI1PR07MB4735C10E9118AD8AAAE98F1B83570@VI1PR07MB4735.eurprd07.prod.outlook.com>
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> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com;
x-originating-ip: [89.135.192.225]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 28bb3c8f-8500-4fa9-cc20-08d6b826126c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB3117;
x-ms-traffictypediagnostic: VI1PR07MB3117:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <VI1PR07MB3117CB65FAD72E015893E18183570@VI1PR07MB3117.eurprd07.prod.outlook.com>
x-forefront-prvs: 0996D1900D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(396003)(346002)(39860400002)(51444003)(13464003)(199004)(189003)(561944003)(316002)(486006)(7736002)(14444005)(86362001)(229853002)(256004)(33656002)(446003)(11346002)(478600001)(6116002)(97736004)(3846002)(66066001)(105586002)(52536014)(53546011)(106356001)(102836004)(6436002)(25786009)(26005)(6306002)(2906002)(110136005)(7696005)(76176011)(476003)(186003)(9686003)(305945005)(93886005)(2501003)(55016002)(71200400001)(81156014)(81166006)(5660300002)(53936002)(14454004)(66574012)(966005)(8676002)(71190400001)(6246003)(68736007)(99286004)(8936002)(74316002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3117; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: u1vAMINLqEoE42eDPqQnMvN1Lz/COVvtK3zlywCXhspbyEZ9kpwUGBjBPulrqQhgn6j0NbIO83O6eePJqE/qXI+QpbTxa9m87qvquh/daLDSlKMxKdyFfVirnHWnRbc/SDZqUv+DrbSeU0cXOA+PHFzk5GuJHdifWBVUeYgWIBz5K9s5OCUgX1zmSh0aVpqaZwIaQcVq6JWRFQ2AoehCggqdHOn3KduP2KifKrv9POSPy4FjMHSpjDc8L9cySAslsF148ws/WwqeagBjvZQxlf++st1veYqxRrCGUGDRPCQeOnn5Yxw3wEAkdg7csNN+B3E2K5j6EpHspTFtM6CL7Q/41er573o8ONIhCG9sgGB10KutlcSZU9o72MGiATEA3ikymwDGjWb/dSLwm2eJGVG+lRungBrhlV+32dflhb4=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 28bb3c8f-8500-4fa9-cc20-08d6b826126c
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 11:18:17.5160 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3117
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/zXSTgQYJ0rb0UqnthcPxx-TPvtg>
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: Wed, 03 Apr 2019 11:18:24 -0000

Hi,

I agree with Juergen's view to add possibility of generating keys with an action that becomes (protected) configuration.

See more below.

/Balazs

> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;
> Sent: Friday, March 29, 2019 9:53 PM
> To: Kent Watsen <kent+ietf@watsen.net>;
> Cc: Balázs Kovács <balazs.kovacs@ericsson.com>;; tom petch
> <ietfc@btconnect.com>;; netconf@ietf.org
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> 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).

Yes. Correct. 

> >
> > 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/OtYAlqLmlErfCr3Z4mcXqRvez
> 48
> <https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRve
> z48>.
> >
> > 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 see, and agree. With the suggestion to make it mean "inaccessible via YANG interface" I think I rather meant all interface exposed to the same type of actor. For example if YANG interface is an external operator interface, then the key should of course be consistently inaccessible on all other type of external operator interface.

> >
> > 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).
> >

OK.

> > 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.
> >
> >

OK.

> > 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.
> >

I'm fine with your proposal. I have no issues with actions generating configuration (but I never followed the discussions about actions and datastores) --that is relevant for backup--and we see the example of this keystore use case and also the user management use case Juergen brought up.

> > 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/>