Re: [netconf] ietf crypto types - permanently hidden

tom petch <ietfc@btconnect.com> Fri, 22 March 2019 16:28 UTC

Return-Path: <ietfc@btconnect.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 927FB13121E for <netconf@ietfa.amsl.com>; Fri, 22 Mar 2019 09:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 S2vASyFDk0Pe for <netconf@ietfa.amsl.com>; Fri, 22 Mar 2019 09:28:21 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30093.outbound.protection.outlook.com [40.107.3.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56521311AA for <netconf@ietf.org>; Fri, 22 Mar 2019 09:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+wOX6aP93Zc3QVcJtqlogPAO1sQiIlptPS+Hg5ukGeg=; b=REBtJcp+ygAE6Aoeb4hZV0KrM6Jena+tAbhbeLX5Ssd03i7m9tE6yXOc8ARx+LjSeP/8f2L9K1A0o+MxTC3C+phQ52ka/6w59ybo4qHSg+3QGqXjo2LKe3/AMVmfucRzhmOnfD3EqrpxQ2h4me+cw3ZP2tvo/j2G5yGZpLvouhY=
Received: from VI1PR07MB5744.eurprd07.prod.outlook.com (20.177.202.24) by VI1PR07MB4893.eurprd07.prod.outlook.com (20.177.200.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.14; Fri, 22 Mar 2019 16:28:15 +0000
Received: from VI1PR07MB5744.eurprd07.prod.outlook.com ([fe80::4532:1dbd:fc8e:9bad]) by VI1PR07MB5744.eurprd07.prod.outlook.com ([fe80::4532:1dbd:fc8e:9bad%6]) with mapi id 15.20.1750.010; Fri, 22 Mar 2019 16:28:15 +0000
From: tom petch <ietfc@btconnect.com>
To: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= <balazs.kovacs@ericsson.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Kent Watsen <kent@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AQHU4MxAQ+h2g0iALUGyp0wBm3vjjQ==
Date: Fri, 22 Mar 2019 16:28:15 +0000
Message-ID: <00b701d4e0cb$e79e9660$4001a8c0@gateway.2wire.net>
References: <VI1PR07MB4735863E79020AD84C4FDF9483420@VI1PR07MB4735.eurprd07.prod.outlook.com> <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de> <VI1PR07MB47355E3E3C5D703122258C2583430@VI1PR07MB4735.eurprd07.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0467.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a2::23) To VI1PR07MB5744.eurprd07.prod.outlook.com (2603:10a6:803:98::24)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 51b586be-5faf-4847-14da-08d6aee3627e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4893;
x-ms-traffictypediagnostic: VI1PR07MB4893:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <VI1PR07MB4893CB2C61EA983AD26D9851A0430@VI1PR07MB4893.eurprd07.prod.outlook.com>
x-forefront-prvs: 09840A4839
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(366004)(376002)(346002)(199004)(189003)(13464003)(51444003)(6306002)(86152003)(7736002)(50226002)(8936002)(61296003)(106356001)(105586002)(53936002)(81156014)(81166006)(6436002)(6512007)(9686003)(8676002)(6246003)(229853002)(966005)(4720700003)(478600001)(14454004)(110136005)(54906003)(316002)(1556002)(44736005)(2906002)(6486002)(5660300002)(68736007)(6116002)(3846002)(66066001)(305945005)(62236002)(44716002)(66574012)(84392002)(52116002)(86362001)(446003)(476003)(14496001)(81686011)(81816011)(76176011)(26005)(186003)(25786009)(99286004)(486006)(14444005)(256004)(4326008)(71200400001)(71190400001)(53546011)(6506007)(102836004)(386003)(97736004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4893; H:VI1PR07MB5744.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 4sazlXp6oJsoyMtUMWWnS0XqmEFwSj5GrAeXMvJEhdI28vGzGn/xdocxRxv0kH3yupH2DWhMw1eYSHMN2Dnwry5FUGZyMi1cjZmZy4G8vSYexrrFA+fjwTuj3sJ/Wmbx34/cv5aPDgUtEvgalcgxlKia8aVrfOiFZR6xH3OszD/LJtO2pTqN2isrRqiGcYLybyo59BP7Emk9Zt7sLweT+Dw5N9o9PDkY47scuojbBSi4Fm2b1g7OQc1ROKb7Xd9obZLDZd+KTkUzMuX+mC+qjxYcjpLswnzgn1UEh+TnZTG+c1UZwnK8LYPVXXPLudFWR8pRqsWd3EtnMqM5QJ5jFlgJnoqouOkpovDN7bc3Gci9oEgWNapdxsIMttfsSrGWhcXYdHV6cBmrq/7gXbFDdWzB/kVNWZ85nFcSqRFY75w=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <CB7F86933DC8DC49ADD5790922D2A157@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 51b586be-5faf-4847-14da-08d6aee3627e
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 16:28:15.6545 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4893
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/on0ouHZ1EAzLOIT4Oz_AHdLL8K0>
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, 22 Mar 2019 16:28:24 -0000

----- Original Message -----
From: "Balázs Kovács" <balazs.kovacs@ericsson.com>;
Sent: Friday, March 22, 2019 12:44 PM

Hi,

I would really prefer the definition for 'hidden' as 'not accessible via
YANG protocols'. The explanation is that regardless of what method I use
to create/store the private keys, I still might not want the operator to
generate keys outside of the device or configure binary secret strings.

<tp>

I think that the meaning of the term 'hidden' varies depending on which
part of the I-D you are reading.  The term is absent from the referenced
RFC, 8017 and 5915, which is probably not a coincidence.  Rather, the
terminology of the literature is of a key pair, made up of a public and
private key so the action
generate-hidden-key {
probably means generate-key-pair; but, in other places, the word
'hidden' clearly has different semantics and would probably best be
replaced by something else, such as inaccessible.

Tom Petch

I considered TPM protection for hidden keys is an option or example so
far, which adds limitations or additional complexity for moving keys,
but should not be the only option for hidden keys. The descriptions
mention TPM as example, then the rest of the text should align also to
keep that as example.

Br,
Balazs

-----Original Message-----
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;
Sent: Thursday, March 21, 2019 4:29 PM
To: Balázs Kovács <balazs.kovacs@ericsson.com>;
Cc: netconf@ietf.org; Kent Watsen <kent@watsen.net>;
Subject: Re: [netconf] ietf crypto types - permanently hidden

I agree, I do not understand the second sentence either. My problem is
that I do not know what a 'real' private key is, are hidden keys
somewhat unreal? Or is "not hidden" = "real"?

The last sentence can probably be fixed; I think the intention was to
say that you can't backup and restore hidden keys by retrieving
configuration and restoring the configuration.

In general, I think we need a definition what a hidden key is. Is
something not exposed via a YANG interface a hidden key (but it may be a
regular key when using other device access methods)? Or do we require
that a hidden key is generally protected? I assume some people want to
have flexibility here but from the viewpoint of a security administrator
it matters a lot whether 'hidden' means 'generally not accessible' or
only 'not accessible via YANG protocols'.

The description of install-hidden-key seems to indicate a key is already
'hidden' if it only exists in <operational>. Is this really a 'hidden'
key or more an 'ephemeral' key?

/js

On Thu, Mar 21, 2019 at 02:23:27PM +0000, Balázs Kovács wrote:
> Hi,
>
> 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, or if
the device or the model allows I could even switch to non-hidden key, I
believe, by providing the binary. 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. I would prefer to
remove this sentence and leave backup considerations to implementations.
>
> Could these changes be done?
>
> Br,
> Balazs

> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


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

_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf