Re: [netconf] ietf crypto types - permanently hidden

Andy Bierman <andy@yumaworks.com> Thu, 02 May 2019 00:43 UTC

Return-Path: <andy@yumaworks.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 50BDD1201A6 for <netconf@ietfa.amsl.com>; Wed, 1 May 2019 17:43:55 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 FEmlNLKTlGWj for <netconf@ietfa.amsl.com>; Wed, 1 May 2019 17:43:53 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2601200A3 for <netconf@ietf.org>; Wed, 1 May 2019 17:43:52 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id k8so575031lja.8 for <netconf@ietf.org>; Wed, 01 May 2019 17:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cJITYUppbMs9K4lq4bcZj2uRj3j5Bf0U7tkjTQ+TYKI=; b=kMnVFtkQdBy5h4XYvSSVLygiNeM69jRG8UJA9iGVpHSlWydGAN67oGyfjKi/eZ/9P+ 2jfdizeU3upZg6VdxTNG8GxRa/5yUf4qkKzkdvkl3l/Koa0b5F2KluYWfbE+Wwl8ZMW3 PsWs910wFRfLFyscjavl9ui9mVvq/WktOS68coGHUchYgISvTgdUK3nFztn6BfmLLoe4 5+gm9oS+2W1bkgCrpnTvRHcUx4h87IwYqdCbqJSCTqhDvX17uIP6FHhvk8ZMdm8T8QRw Z55mJFfwF+iPIjLk4AiWgM+1CLYthrV2yu2FGEBL7dbpE0hyDDnvC0p/bCKvf4iJYLD4 VbyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cJITYUppbMs9K4lq4bcZj2uRj3j5Bf0U7tkjTQ+TYKI=; b=oFSZys362UZ5GOFz0zJmJ5RLF2Qub51uukG4vOYL2pchbWdeYWt43UE8O4sFid51iK /GHTmhgfHisEIlome9u8B4Vb6/tTv+WzFqLGzrCCQ34e/TPH4JPHlog5Z88s+Fl3OuKX OS6Sh+zNbrHJz0peoNrY7ufoQSBc+AuwdZhnpG+4Kp+E81i2TxTqwGSWSE0vho4iJEQW Eyod4LTLKXZ7dNjF2M0vP/AW3vhL/bvlvUJ4FGQTOgtEZ2pN+JTdeCjDJh2lRm7mFgmC OF+VVs5xDcEiH4LjghIQSV8qTtSKAkQ3dv0JDbkfogaQMFwz3m34Wx9ImitnIdwIt+Ba mVeQ==
X-Gm-Message-State: APjAAAVmOm6tR/WBygiv3OrVXXX2L7al2hBt5Ag3dzy0fu/6go4NtsRf X/8sux87jKkx1Ib+frLsJj8YTcfEaCmyGlpyUqKb6g==
X-Google-Smtp-Source: APXvYqxNC6tGF6zA4nzHoEw8WuvyDq53nGaYu1VUfU4Ix5BswIYqRlOL9ShHqeRWrRgYMlIwx+0O9koBc9hGXlxVdMY=
X-Received: by 2002:a2e:85d2:: with SMTP id h18mr224340ljj.128.1556757830835; Wed, 01 May 2019 17:43:50 -0700 (PDT)
MIME-Version: 1.0
References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <VI1PR07MB47353B20AF138B5B8B702285833A0@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <acef56d17fc64102ae24bb8fcb8c828d@XCH-RCD-007.cisco.com> <CABCOCHS=mETbXUNm4pC45HPLtLu-r6QfX6xQAWCGxb7jfR19_w@mail.gmail.com> <0100016a75f6a814-773436bf-9706-443a-b59e-3c5747566859-000000@email.amazonses.com>
In-Reply-To: <0100016a75f6a814-773436bf-9706-443a-b59e-3c5747566859-000000@email.amazonses.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 1 May 2019 17:43:39 -0700
Message-ID: <CABCOCHSvi3WUcSbWO4CX7WKeVsYBNjtt8OvHZNbSdL1i+oLe8Q@mail.gmail.com>
To: Kent Watsen <kent+ietf@watsen.net>
Cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008237470587dcedc2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/uIO88lXdUVcWtWfxN6c4PmQxfec>
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, 02 May 2019 00:43:55 -0000

On Wed, May 1, 2019 at 5:34 PM Kent Watsen <kent+ietf@watsen.net>; wrote:

>
> The document-oriented configuration came from a requirement identified
> at the IAB Network Management Workshop (way back when).
> It is critical for rebooting, swapping out a defective device, etc.
>
>
>
> Regarding the document-model concern, here is a line of thinking that may
> help this discussion:
>
> We recently removed the "cannot be backed-up language" because there may
> be a way for a device to backup a permanently hidden key, even when
> protected by a TPM.
>
> Specifically, a TPM (I don't know about other crypto processors) is able
> to encrypt TPM-protected keys (using yet another TPM-protected key called
> the storage root key, SRK), thus the key (albeit encrypted) CAN be backed
> up, but it CAN ONLY be restored on the device having the originating TPM.
>
> Thus, instead of using the enum "permanently-hidden", the value of the
> *encrypted* key could be safely provided.
>
> Perhaps we could model the 'private-key' value after iana-crypt-hash and
> prefix the base64-encoded binary private key value with some special (not
> legal base64) value indicating that the key is 1) encrypted and 2) can only
> be restored on the originating device.  Ideally, the prefix identifies the
> device (or, better, the crypto processor), lest there is any confusion.
>
> As for "swapping out a defective device", the above idea doesn't support
> that workflow, but I think that the inability to do a full RMA is given
> with the meaning of a "permanently-hiddden" key already and, anyone that
> creates such a key does so with that understanding.   What it does support,
> though, is the full restoration of the device after a hard-drive
> replacement (or reformat) using a standard "configuration" document, which
> seems better than what we have now with the "permanently-hidden" enum.
>
>

This requirement led directly to the ability in NETCONF to do a simple
<get-config> and
stuff the returned data into an <edit-config> or <copy-config> request.


>
> The "server created config" problem could be viewed as an access control
> problem.
> There are proprietary YANG extensions that implement this approach.
>
>
> I don't understand, can you provide examples?
>

We have a "user-write" extension that can override NACM and prevent client
access to server-created configuration.

http://www.netconfcentral.org/modules/yuma-ncx/2015-10-16#user-write.704


Andy


>
>
>
> Kent // contributor
>
>