Re: [netconf] crypto-types fallback strategy

[tom petch <[e-mail]>]

<inline tp>

----- Original Message -----
From: "Kent Watsen" <[e-mail]>
Sent: Tuesday, October 01, 2019 5:43 PM

Thanks for pointing that out, Tom.  I was going to say something along
these lines in a response to Juergen.    The net is that partitioning
identities along protocol boundaries is misdirected.  We need to focus
on the algorithms, not the cipher suites.

Going back to the primary goal, we care about is how to use the
"algorithm" field to identify the format of the public and private key
fields.  To this end, the field could be called a "key-format" instead.
There is a secondary goal to pass an "algorithm" parameter into the
'generate-symmetric-key' and 'generate-asymmetric-key' actions, but
maybe the problems can be separated?

In OpenSSL, the commands are:

1) `openssl genrsa -out rsa_private_key.pem 2048` creates an
RSAPrivateKey (from RFC3447)
2) `openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem`
creates a SubjectPublicKeyInfo (from RFC5280)
3) `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem`
creates an ECPrivateKey (from RFC5915)
4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem`
creates a SubjectPublicKeyInfo (from RFC5280)

OpenSSH, the commands are:

1) `ssh-keygen -t rsa -b 4096 -C "[e-mail]"` creates an
RSAPrivateKey (from RFC3447) and a proprietary public key file format.
2) `ssh-keygen -t ed25519 -b 4096 -C "[e-mail]"` creates
an ECPrivateKey (from RFC5915) and a proprietary public key file format.
3) `ssh-keygen -e [-m RFC4716] -f <private-key-file>` exports the public
key format described by RFC 4716.

Disclaimer: (2) is just a guess, based on (1), which I haven't tested
myself yet.


In order to just identify the format, perhaps we use something like the
following, which could be in ietf-crypto-types:  (Note I added
OneSymmetricKey and OneAsymmetricKey formats as well.  That is, with
this approach, it's not an "either-or" tradeoff, both can be defined.)


    /*** all key format types ****/

    identity key-format-base {}
    identity public-key-format { base "key-format-base" }
    identity private-key-format { base "key-format-base" }
    identity symmetric-key-format { base "key-format-base" }


    /**** for private keys ****/

    identity rsa-private-key-format { // used by SSH and TLS
        base "private-key-format";
        description "An RSAPrivateKey (from RFC 3447).";
    }

    identity ec-private-key-format { // used by SSH and TLS
        base "private-key-format";
        description "An ECPrivateKey (from RFC 5915)";
    }

    identity one-asymmetric-key-format {
        base "private-key-format";
        description "A OneAsymmetricKey (from RFC 5958).";
    }

    identity encrypted-private-key-format {
        base "private-key-format";
        description "A CMS EncryptedData structure (RFC 5652) containing
a OneAsymmetricKey (RFC 5958).";
     }


    /**** for public keys ****/

    identity ssh-public-key-format {
        base "public-key-format";
        description "The public key format described by RFC 4716.";
    }

    identity subject-public-key-info-format {
        base "public-key-format";
        description "A SubjectPublicKeyInfo (from RFC 5280).";
    }


    /**** for symmetric keys ****/

    identity symmetric-key-format {
        base "symmetric-key-format";
                description "An OctetString from ASN.1.";
            // Knowing that it is an "OctetString" isn't really helpful.
            // Knowing the length of the octet string would help a
little, as it relates to the algorithm's block size
            // We may want to only (for now) use
"one-symmetric-key-format" for symmetric keys.
            //     ^---- the usability issues Juergen mentioned before
only applies to asymmetric keys?
    }

    identity one-symmetric-key-format {
        base "symmetric-key-format";
        description "A OneSymmetricKey (from RFC6031).";
    }

    identity encrypted-symmetric-key-format {
        base "symmetric-key-format";
        description "A CMS EncryptedData structure (RFC 5652) containing
an OneSymmetricKey (RFC 6031).";
    }


then, the public-key grouping might look like:

  grouping public-key-grouping {
    description
      "A public key and its associated algorithm.";
    leaf key-format {
      nacm:default-deny-write;
      type public-key-format;
      mandatory true;
      description "Identifies the format key's binary data value.";
    }
    leaf public-key {
      nacm:default-deny-write;
      type binary;
      mandatory true;
      description
        "The binary value of the public key.  The interpretation
         of the value is defined by the 'key-format' field.";
    }
  }

and the key-pair grouping might look like:

  grouping asymmetric-key-pair-grouping {
    description
      "A private key and its associated public key.";
    uses public-key-grouping;
    choice private-key-type {
      mandatory true;
      description
        "Choice between key types.";
      leaf private-key {
        nacm:default-deny-all;
        type binary;
        description
          "The binary value of the private key.  The interpretation
           of the value is defined by the 'key-format' field.";
      }
      leaf hidden-private-key {
        nacm:default-deny-write;
        type empty;
        description
          "A permanently hidden key.  How such keys are created
           is outside the scope of this module.";
      }
    }
  }

and the symmetric grouping might look like:

  grouping symmetric-key-grouping {
    description
      "A symmetric key and algorithm.";
    leaf key-format {
      nacm:default-deny-write;
      type public-key-format;
      mandatory true;
      description "Identifies the symmetric key's format.";
    }
    choice key-type {
      mandatory true;
      description
        "Choice between key types.";
      leaf key {
        nacm:default-deny-all;
        type binary;
        description
          "The binary value of the key.  The interpretation
           of the value is defined by the 'key-format' field.";
      }
      leaf hidden-key {
        nacm:default-deny-write;
        type empty;
        description
          "A permanently hidden key.  How such keys are created
           is outside the scope of this module.";
      }
    }
  }



To put an end to this email, recall above it was said that the secondary
goal is to pass an "algorithm" parameter into the
'generate-symmetric-key' and 'generate-asymmetric-key' actions (what
kind of key to generate, right?).   Most of the above regards the key
formats (not algorithms, though the OneSymmetricKey and OneAsymmetricKey
structs do self-identify their algorithms).   I don't have an answer for
this yet, but maybe we can mimic some aspect of the above for it?

Comments?

<tp>

Kent

I am still unclear about the big picture.  Are you saying that the other
lists of algorithms - MAC, hash, signature etc - would no longer be in
this I-D?  Or if they are still there, how are they going to be used

I see the role of what you list above in the client-server modules but
not a usage for the other lists.

Tom Petch

Kent // contributor



> On Oct 1, 2019, at 6:58 AM, tom petch <[e-mail]> wrote:
>
> <inline tp>
>
> ----- Original Message -----
> From: "Kent Watsen" <[e-mail]>
> To: "Juergen Schoenwaelder" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>;
> <[e-mail]>
> Sent: Tuesday, October 01, 2019 1:38 AM
>
>> On Sep 27, 2019, at 1:46 PM, Schönwälder, Jürgen
> <[e-mail]> wrote:
>>
>> On Fri, Sep 27, 2019 at 03:53:51PM +0000, Rob Wilton (rwilton) wrote:
>>> I basically agree with what Martin is saying.
>>
>> So do I.
>
> Hmmm...
>
>>> Either one YANG module containing all of the crypto identities, or a
> few YANG modules as previously suggested.
>>
>> It may make sense to split by security protocol.
>
> That would go some towards addressing Rich's concern.  Presumably we
> would have one module each for SSH  and TLS algorithms.  That said, to
> Rich's concern, there is a constant churn with them.  This churn
> concerns two activities:  the removal and addition of algorithms.
Both
> occur at protocol-version boundaries and, perhaps, other times as
well.
> This suggests to me that we could further refine the identities by
> protocol version, something like this:
>
> In ietf-crypto-types:
>
>    identity base-alg {}
>    identity tls-alg { base "base-alg" }
>    identity ssh-alg { base "base-alg" }
>
> In ietf-tls-1.1-types:
>
>    identity tls-1.1-alg { base "ct:tls-alg" }
>    <a bunch of tls-1.1 identities here>
>
> In ietf-tls-1.2-types:
>
>    identity tls-1.2-alg { base "ct:tls-alg" }
>    <a bunch of tls-1.2 identities here>
>
> etc.
>
> <tp>
>
> Kent
>