Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <kent+ietf@watsen.net> Thu, 21 March 2019 15:11 UTC

Return-Path: <01000169a0cef427-41bd3e75-23f6-4ce7-831e-81ec4b6b0d6f-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 5F6C21311C4 for <netconf@ietfa.amsl.com>; Thu, 21 Mar 2019 08:11:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 iapcjlnHjh2z for <netconf@ietfa.amsl.com>; Thu, 21 Mar 2019 08:11:54 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA47F1311C5 for <netconf@ietf.org>; Thu, 21 Mar 2019 08:11:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553181111; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=hxb7BmYG7aIL7H48wgu6kfgcYZFDjynt6B5zA3LG/Aw=; b=FaD0Ft09nflWhxus7KUMFtP2/Ntxdd6sRXDdruwwL/OTtwKO4jqImxs4HRgwqfPA jTHSCVRfRCANs+1HH1nadMIt1lXchNmkp6bZfRDr9DYj1alBzTx+N1PR1HQW6IJiixp Ygno8OE/2+feGLixn3qSDCeNW+GBXVFkvW70OCwM=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000169a0cef427-41bd3e75-23f6-4ce7-831e-81ec4b6b0d6f-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_93843DAB-D38C-457B-BFAA-27A6F9B4EC0D"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 21 Mar 2019 15:11:51 +0000
In-Reply-To: <VI1PR07MB4735863E79020AD84C4FDF9483420@VI1PR07MB4735.eurprd07.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= <balazs.kovacs@ericsson.com>
References: <VI1PR07MB4735863E79020AD84C4FDF9483420@VI1PR07MB4735.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.03.21-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/oyrDO-qb_e-LVXIBzToINfmXfd4>
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: Thu, 21 Mar 2019 15:12:02 -0000

[CC-ing Henk, who knows a little about TPMs]


Hi Balazs,

> The ‘generate-hidden-key’ action is meant for cases when the key must be generated in the device and not the operator is configuring it. The ‘generate-hidden-key’ is said to produce a ‘permanently-hidden’ asymmetric key. The description of ‘permanently-hidden’ is as follows:
>  
>                 "The private key is inaccessible due to being
>                   protected by the system (e.g., a cryptographic
>                   hardware module).  It is not possible to
>                   configure a permanently hidden key, as a real
>                   private key value must be set.  Permanently
>                   hidden keys cannot be archived or backed up.";
>  
> Th second sentence doesn’t sound right. I can create a permanently hidden key any time by calling the ‘generate-hidden-key’ action,

True, but *when* the action is called is not pertinent, right?

> or if the device or the model allows I could even switch to non-hidden key, I believe, by providing the binary.

How would you get the binary?   Yes, some implementations, as a hack, MAY not actually use a cryptographic processor, but that is besides the point.   The intent with this action statement is that a cryptographic processor IS used and that the private key is forever hidden.


> So I find the second sentence irrelevant in this description.
>  
> More importantly, I find the “Permanently hidden keys cannot be archived or backed up” statement false. Isn’t that implementation specific how archiving is done? If a device puts the hidden keys on some storage, it may still be possible to back them up.

Maybe.  I am aware that e.g., TPMs, have the ability to backup a key but, I think that doing so necessitates that the key is encrypted with the SRK (storage root key) such that only the same TPM chip can decode it (Henk, can you check me on this statement?).  To this end, I agree that the last sentence is too strongly worded.

> I would prefer to remove this sentence and leave backup considerations to implementations.

Remove or replace, let's keep the conversation going. 


> Could these changes be done?

Sure, pending the outcome of this thread.


Kent // contributor