Re: [netconf] latest update to crypto-types and keystore drafts

Kent Watsen <kent+ietf@watsen.net> Tue, 06 August 2019 15:26 UTC

Return-Path: <0100016c678a0e03-1e8334ab-4af3-426b-b0fa-73988d324a46-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 A031812039D for <netconf@ietfa.amsl.com>; Tue, 6 Aug 2019 08:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 48QRkMjc8NS3 for <netconf@ietfa.amsl.com>; Tue, 6 Aug 2019 08:26:38 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0CC12038D for <netconf@ietf.org>; Tue, 6 Aug 2019 08:26:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565105196; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=G94XStIZr2+BPufTC8FYS5G275TafgGkzCHD/d0zd80=; b=TEYogBGKgp3+XsS0VU7i3QpZxqSegpvJu/e8eDP4mNwDVbJwPsu0gEorSMPRKNEK OuDd/lU5ZfgkKeijTSMC1K3e/B8H4lk/YIFCcHD3HykL3b3YiAx1FE6+ogHeOxLPRmm xWbIlFOyl7ef+tM5xcn0aPxAPhcUmVvUMFDWcAMY=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016c678a0e03-1e8334ab-4af3-426b-b0fa-73988d324a46-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_75F5EE29-C110-4B7D-8EB7-C20E0C6D11C1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 6 Aug 2019 15:26:36 +0000
In-Reply-To: <VI1PR07MB4735A5E44BC4ED30BC4D696D83D50@VI1PR07MB4735.eurprd07.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= <balazs.kovacs@ericsson.com>
References: <B8F9A780D330094D99AF023C5877DABAA49BA5A2@nkgeml513-mbx.china.huawei.com> <0100016bb4e4e11b-6cbb1c43-dea2-4c3f-a908-4a9ecfc69589-000000@email.amazonses.com> <VI1PR07MB4735C489562D237D5A72B24383D90@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016c54bba638-1b5714c0-bd81-473a-b6f7-71f5ab0033ba-000000@email.amazonses.com> <VI1PR07MB4735AE58A2FC2778EE03DD7E83DA0@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016c631aac91-86a67985-7e50-47ef-924d-8477383fd479-000000@email.amazonses.com> <VI1PR07MB4735A5E44BC4ED30BC4D696D83D50@VI1PR07MB4735.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.08.06-54.240.8.96
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/iR0VsSV7ovXHVOx_zG62Mh4q310>
Subject: Re: [netconf] latest update to crypto-types and keystore drafts
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: Tue, 06 Aug 2019 15:26:40 -0000

Hi Balazs,

I'm unclear if there is a request for a change of any sort here.   One thing that you may be hinting at is that, while the operator can install an operator key, there is no current mechanism to enforce that keys are encrypted with it, or even at all.   

I'm currently unsure if there should be a knob/feature for this.  Perhaps servers should just trust the clients?  Most clients will be wrapped inside a controller/NMS app, and thus may restrict/enforce as needed via their interfaces to the human-operators.  Would this be good enough?

Kent


> On Aug 6, 2019, at 3:11 AM, Balázs Kovács <balazs.kovacs@ericsson.com>; wrote:
> 
> Hi Kent,
>  
> Yes, sorry. This addition of symmetric-key is still to new to me. I meant the equivalent of clear and NACM protected key under symmetric keys. Which is just called ‘key’ in draft-ietf-netconf-keystore-12.
>  
> The reasons could be: the TPM or equivalent key may not exist or may not be present in keystore (which are roughly the same); or since the encryption of the operator-key is all up to the client, the client may just not implement encryption with the TPM or equivalent hidden public key as the client does not see extra security gains with that (the operator-key was created outside anyhow so it is already known by the client).
>  
> Br,
> Balazs
>  
> From: Kent Watsen <kent+ietf@watsen.net <mailto:kent+ietf@watsen.net>> 
> Sent: Monday, August 5, 2019 8:46 PM
> To: Balázs Kovács <balazs.kovacs@ericsson.com <mailto:balazs.kovacs@ericsson.com>>
> Cc: netconf@ietf.org <mailto:netconf@ietf.org>
> Subject: Re: [netconf] latest update to crypto-types and keystore drafts
>  
>  
> 
> 
> On Aug 5, 2019, at 3:58 AM, Balázs Kovács <balazs.kovacs@ericsson.com <mailto:balazs.kovacs@ericsson.com>> wrote:
>  
> Hi Kent,
>  
> Yes, it makes.
>  
> I assume the “secret” symmetric key could be just equally configured as normal private-key since the key is coming from outside, depending on the taste of the client if it is just a NACM protected normal private-key or an encrypted key.
>  
> Since a symmetric key have "secret" value more so than "private" value, if we replace "private-key" with "secret-key" above, then yes, I agree.  Stated more plainly, a platform that doesn't have a TPM (or equivalent) protected asymmetric key, could instead protect the operator's symmetric key using NACM (i.e., only the crypto-officer/ restore-session can access it).  Is this what you mean?
>  
> 
> 
>  
> Br,
> Balazs
>  
>  
> Kent