Re: [netconf] ietf crypto types - permanently hidden

Balázs Kovács <balazs.kovacs@ericsson.com> Fri, 22 March 2019 12:44 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 5A7A5126D00 for <netconf@ietfa.amsl.com>; Fri, 22 Mar 2019 05:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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 header.b=Hqb46foI; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ivfidMtd
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 Ae2habq2TJJt for <netconf@ietfa.amsl.com>; Fri, 22 Mar 2019 05:44:09 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 745BF12426A for <netconf@ietf.org>; Fri, 22 Mar 2019 05:44:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1553258647; x=1555850647; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Wy8KL9bi5XrSVQLPxxy6cVQRqHpG5PLC0pZFUSMZ/RM=; b=Hqb46foIeNJjp19hdBZpP2fD0ngwryM6f2ysyn5H7kIQ79xqh9oIOnDwsRzX5KGu ip+r/ExTGjND6E2ICmHy2wuj9aA+aOJwkvKZ3jG8hRu0sa0Q0e1BP9RSs4WoFzF6 MyK8ZL0D0BOyoe/MFyrjGSwz4UrrbusAIFWJPlyHV8k=;
X-AuditID: c1b4fb2d-fafff70000002218-13-5c94d8976ce3
Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 47.F6.08728.798D49C5; Fri, 22 Mar 2019 13:44:07 +0100 (CET)
Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 22 Mar 2019 13:44:06 +0100
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 22 Mar 2019 13:44:07 +0100
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Fri, 22 Mar 2019 13:44:06 +0100
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=Wy8KL9bi5XrSVQLPxxy6cVQRqHpG5PLC0pZFUSMZ/RM=; b=ivfidMtd0kTQNOekYY6CUVsOdYpFFwD1f5s9TN6WUxDCKFCwJG+bNfKMYG3c+wd9FWDdjmLio3/y8B8L5rmLRxCuz63TKStelpBB7nrwg/STfV5/aP36e6kHhmLXljpc8XZN77ry17vIxf9HkyaQll9efUeO4u9YHkhV5oZBFn0=
Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB4591.eurprd07.prod.outlook.com (20.177.56.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.16; Fri, 22 Mar 2019 12:44:05 +0000
Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::807b:cd48:c48:cf03%4]) with mapi id 15.20.1730.013; Fri, 22 Mar 2019 12:44:05 +0000
From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= <balazs.kovacs@ericsson.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: "netconf@ietf.org" <netconf@ietf.org>, Kent Watsen <kent@watsen.net>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAACqnQAACvdhTA=
Date: Fri, 22 Mar 2019 12:44:05 +0000
Message-ID: <VI1PR07MB47355E3E3C5D703122258C2583430@VI1PR07MB4735.eurprd07.prod.outlook.com>
References: <VI1PR07MB4735863E79020AD84C4FDF9483420@VI1PR07MB4735.eurprd07.prod.outlook.com> <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190321152920.jdkny7szk7ik3sp4@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [89.135.192.225]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: abc3ac6f-cf2d-4cf6-0150-08d6aec411f8
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4591;
x-ms-traffictypediagnostic: VI1PR07MB4591:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <VI1PR07MB45918DA13E8C9ED61E33ABC883430@VI1PR07MB4591.eurprd07.prod.outlook.com>
x-forefront-prvs: 09840A4839
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(39860400002)(346002)(396003)(13464003)(199004)(189003)(106356001)(99286004)(2906002)(55016002)(4326008)(6306002)(9686003)(105586002)(66066001)(66574012)(6246003)(6116002)(3846002)(53936002)(6916009)(97736004)(68736007)(8676002)(81156014)(81166006)(8936002)(305945005)(7736002)(74316002)(33656002)(25786009)(6436002)(256004)(14444005)(14454004)(478600001)(229853002)(966005)(86362001)(476003)(71190400001)(71200400001)(11346002)(446003)(316002)(53546011)(6506007)(102836004)(76176011)(26005)(5660300002)(52536014)(6346003)(186003)(7696005)(54906003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4591; 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)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: OZhYE/cijrVZQOXcrPm6O1kJEx/tHj/eWgLq3JOzM2BXTtcG6C/MC8ZRCg2ohBYhrtdvfOXJ3qZ2ajb9KEoLvWkEhohsF6RThzR1LIcARdfCEec0TUcHab8/RCCbgzzGUgcQc+k9zEJ6d6VJf25A0EVU2ElfQi9tcKXcp427xmCDeDp7alXymOLgIwlgkAqhbZpzm9jcGWOb+3nv2yMmHNcoZ44BfgSo0CRq3dTsb4WknfXxrfG000LVIgH1PKyPz+Ac7STtbkTh8LCKtR3A/WgkEjHCoPFpctvbUm02tfRD4qlEF370m0ibBJn3Fkann9i0DJqJTpyEMBaJnM52/Rt1asY5C0DB6Y+Rd2mUVswPAKWJJ17tbzCrm/jJPS/WHXyCL+5KC9jrwPOPzhrgHwa3dzuDStAY8sTlYavHjEQ=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: abc3ac6f-cf2d-4cf6-0150-08d6aec411f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 12:44:05.6752 (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: VI1PR07MB4591
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA03Se0hTURgA8M69e1ytwXFqfqwHdCGChdrrDzEVhYRZZv0VYaOcelNRp+xO SYtcxqCpoKAjJ+Vz+JwxTbIkwRfk/KOHINjU1KaZSWVTFHFp3s6C/vud7/vOd853OAwtLxMr mAytntNpNVmsxFdkud5bGPx4skp9yjziHzbRtYXC2pzz0jBz95Q4mlZZrVuUyj4Qp3KNlkiv 0om+EalcVkY+pwuNSvJNn7G+p3L7jt75vtkpNaCfQSXIhwF8DiZq2+kS5MvI8QiC4S8OSkjI 8QaCobcJJLHn34NzYpKwUtD+OVSwCFfQMDZaRIoqKfiw/gCRxRyCT7YRJFRJcCwsWrakggNw NJS/KJUIprEKyurL/9ofR8KMrVxMaqLgmamNIg6H6VY3IqcdB2uTaa8Pw8iwGpaN2eRCDQje GGgh7IOvQFVPtBBG+CBsjtkoclIQOBfqKDIxBuvrdzRxICy7dsTELFR/c3p9BMbrShHxZZh9 tCQVxgL8EYFnvNvbSAmWqRavFbDp+iUlzoTapmZv/DAUD1aLyeZdMXy1r3pfkYOWTiOqQCE1 /12QOAQmzVUS4pPQ3LBCC5ZhP3BYFkT1SNSOAnmO57PTzpwN4XQZKTyfow3RcvputPdHBnu2 g1+ijpWYIYQZxB6QJQ1UqeViTT5fkD2EgKHZAFnfjUq1XJaqKSjkdDm3dHlZHD+EDjEiNkjm kfup5ThNo+cyOS6X0/3LUoyPwoBCB4qUHvfwxeWmtSzRWmXPtqLIVtd+rW0n9ry2l32lX2+y TIu2/eIuNZ6IV1qOL87Pe4xPHbPsbVdUR6XBod5vN5uU+QmquzFxef2Jx+7jJ2zrMuqKzo4c f15fXBN/T5MM8fihO0K+L865Yb/pSu73NBo7L7h3U1Z/hC+ZWBGfrjmtpHW85g+ZBOjfHwMA AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/7VIL4RojbZ1Oeg8FkuCFxO4gIo0>
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 12:44:13 -0000

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.

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