Re: [netconf] ietf crypto types - permanently hidden

Andy Bierman <> Thu, 02 May 2019 00:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50BDD1201A6 for <>; Wed, 1 May 2019 17:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FEmlNLKTlGWj for <>; Wed, 1 May 2019 17:43:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB2601200A3 for <>; Wed, 1 May 2019 17:43:52 -0700 (PDT)
Received: by with SMTP id k8so575031lja.8 for <>; Wed, 01 May 2019 17:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Wed, 01 May 2019 17:43:39 -0700
Message-ID: <>
To: Kent Watsen <>
Cc: "Rob Wilton (rwilton)" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000008237470587dcedc2"
Archived-At: <>
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 May 2019 00:43:55 -0000

On Wed, May 1, 2019 at 5:34 PM Kent Watsen <> 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.


> Kent // contributor