Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting

Kent Watsen <kent+ietf@watsen.net> Thu, 14 May 2020 17:14 UTC

Return-Path: <01000172142e349b-b5a2b343-02d4-43d2-84d9-dd0e42c44cd9-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 E20D83A0C16 for <netconf@ietfa.amsl.com>; Thu, 14 May 2020 10:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 4PaiJcW52Qwr for <netconf@ietfa.amsl.com>; Thu, 14 May 2020 10:14:33 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554B23A0C15 for <netconf@ietf.org>; Thu, 14 May 2020 10:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1589476472; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=6YBHhpssQj1SAWbUlczDz8qyelZ3dgNntAzZh3BJSLM=; b=HVQQT/KwQBQ/bh68YeP+m26IsQwbxt598f1dl5zn7OruqFxUUnj36shr2FDIuSqJ 21pYbEe4REk43qyAUWRxQ5MgPYdAIfWPhyF9hvAzawX3Hb8KAjg1e2VcSNhO5AoR1w/ OehIhb0oWkOf5BQgadR5Wwp71E1yBcs1yA7707Js=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000172142e349b-b5a2b343-02d4-43d2-84d9-dd0e42c44cd9-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_106CD682-E94C-49A2-AD73-50E687377732"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 14 May 2020 17:14:32 +0000
In-Reply-To: <MN2PR11MB4366D2A91F5017A2EEA793C6B5BC0@MN2PR11MB4366.namprd11.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, "Salz, Rich" <rsalz@akamai.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
References: <0100017199cd7580-240a83ae-9934-4af3-a0e3-3b063286059f-000000@email.amazonses.com> <20200421063956.fgczjrjhh6ppjhnp@anna.jacobs.jacobs-university.de> <010001719d195262-4f097864-625d-437f-8e15-a79c4498342e-000000@email.amazonses.com> <MN2PR11MB4366810254654BAD3A07915AB5AF0@MN2PR11MB4366.namprd11.prod.outlook.com> <010001721019329c-2f818f0f-e2d7-48aa-b513-d4380e88b830-000000@email.amazonses.com> <MN2PR11MB4366D2A91F5017A2EEA793C6B5BC0@MN2PR11MB4366.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.05.14-54.240.48.90
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/eUcWEnccj2h9lGq9U4FMqOmUM1I>
Subject: Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting
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, 14 May 2020 17:14:36 -0000

Hi Rob,


> I’m not sure that I have sufficient knowledge to properly comment on this point: “enable apps to create proprietary identities that work with the standard model”.
>  
> If feels to me that the ultimate solution here is that the individual protocols define protocol specific algorithm identities.  But it is unclear to me (i) whether it is helpful for those protocol specific algorithm identities to derive from a base generic algorithm identity or not, and (ii) whether it is helpful for those algorithm specific identities to be able to inherit a base algorithm specific identity.
>  
> As more concrete examples:
> (i) Would be helpful for an ssh “rsa4096” identity to derive from “ssh-asymmetric-algorithm” which itself derives from “asymmetric-algorithm”?

Assuming a future effort mimicked Option #2, then "yes”, as I’d expect an "ietf-ssh-common:generate-asymmetric-key” RPC to contain an “input” node that is an identityref to the “ssh-asymmetric-algorithm” identity.


> (ii) Or would be helpful for an ssh “rsa4096” identity to derive from both “ssh-asymmetric-algorithm” and also a base cypto “rsa4096” identity that derives from “asymmetric-algorithm”?

Assuming a future effort mimicked Option #1, then this might make sense.


> (iii) Or is it just sufficient to have an ssh “rsa4096” identity derive from a “ssh-asymmetric-algorithm” base identity?

Assuming the future effort mimics Option #2 again, this would NOT make sense, as we’d want the protocol-independent base identity (e.g., asymmetric-algorithm) so that a protocol-independent identityref could exist in the "symmetric-key-grouping" and “asymmetric-key-pair-grouping” groupings, which are use by, e.g., Keystore, which is protocol-independent.


> If the answer is (ii) then I think that there is also a further question as to whether the base “asymmetric-algorithm” identity should be defined in crypto-types.yang or in the IANA registry defined YANG file that defines the base identities?

I didn’t catch the first part, but gist is clear.  I think that defining the protocol-independent base identities in ietf-crypt-types is safe or, rather not something I’d consider worthy of an IANA registry.  There are very few cryptographic algorithm types and rarely is a new one defined.


> Even if we can figure out what the identity hierarchy should look like, I’m not sure whether it makes sense to still define the “algorithm” leaf nodes in the groupings.  If they are only really truly required for the key generation rpcs then perhaps they are not required in the other places at all.

TL;DR;   It seems okay to drop the “algorithm” node from the "symmetric-key-grouping" and “asymmetric-key-pair-grouping” groupings.  The UI experience isn’t overly compromised, and the security is the same.

Think about this from a device administrator’s perspective using CLI or a GUI interface looking at a screen presenting the contents of the Keystore.  If the UI logic is smart enough, almost in all cases, it can extract a suitable algorithm identifier from the binary key directly.  That is, most of the "key formats” embed an identifier inside the binary structure.  The only case where this is not true is for symmetric keys that are configured using Octet Strings, which are generally more common than using the OneSymmetricKey format.  

The Octet String format is literally just a block a random bytes for the symmetric key; the only metadata that can be extracted from an Octet String is its length, but it is unknown if, e.g., a 24-byte octet string is being used for AES-256 or ChaCha20-Poly1305.  So, in this case, the UI could only at best display the symmetric key’s length.

That said, in general, all symmetric and asymmetric keys SHOULD be encrypted by the public part of a “hidden” asymmetric key (e.g., a built-in IDevID cert), in which case the encrypted keys would HAVE to use the OneSymmetricKey and OneAsymmetricKey formats, respectively…and thus the UI experience could always be good.  

In case this best practice is not followed (i.e.,the keys are NOT encrypted), then the server would have to entirely rely on access control (e.g., NACM) to protect the keys from accidental disclosure.  But that’s just the way it is, and how I imagine it is implemented on most equipment out there.


> At the moment,  I’m leaning towards leaving this out, and solving this in the future.  If we don’t put anything in, then we can’t accidentally constrain a future solution.

Okay.


> Rob
> // As an individual contributor

Kent // contributor