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

From: Kent Watsen <[email-masked]>
Date: Wed, 13 May 2020 22:13:06 +0000

Hi Rob,

Before makeing the edits to conform to Option #3 (remove “keygen”), I wanted to follow-up on a comment you made before:

> One question I have, is whether the crypto-types could still define identities for the base algorithms. 

I know that it’s not what you had in mind, but one possible half-step is as follows...

In ietf-crypto-types.yang, define two base identities: 

     identity symmetric-algorithm {
        description "Base identity for symmetric algorithms.";
      }

      identity asymmetric-algorithm {
        description "Base identity for asymmetric algorithms.";
      }

And then, wherever there is an “algorithm” node, change its definition as follows:

OLD:

    leaf algorithm {
      type isa:symmetric-algorithm-type;
      mandatory true;
      description
        "The symmetric key’s algorithm.";
    }

NEW:

    leaf algorithm {
      type identityref {
        base symmetric-algorithm;
      }
      mandatory false;
      description
        "The symmetric key’s algorithm.";
    }

That the node would be “mandatory false” is not a big deal as the node’s existence in the configuration model serves a very passive role, just relaying anecdotal information.   Truly, the only place where the node MUST be set is in the keygen RPCs (e.g., generate-asymmetric-key).  These RPCs would be defined later, and of course would set the “algorithm" input node to “mandatory true”, where it’s needed.

PROs:
   - enable apps to create proprietary identities that work with the standard model
   - maintain placeholders to where the all the “algorithm” nodes are locations
   - negate needing to augment-in the “algorithm” nodes later

CONs:
   - will likely lead to confusion as there is no way to set a correct value until
     someone defines the concrete identities.

Thoughts?

Kent // contributor

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 14 May 2020 11:45:49 +0000

Hi Kent,

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

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?

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.e

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.

Rob
// As an individual contributor

From: Kent Watsen <[email-masked]>
Sent: 13 May 2020 23:13
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting

Hi Rob,

OLD:

    leaf algorithm {

NEW:

    leaf algorithm {
      type identityref {

PROs:

CONs:

Thoughts?

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 May 2020 17:14:32 +0000

Hi Rob,

> (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 define…

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.

Kent // contributor