Subject: [netconf] crypto-types and keystore comments

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Nov 2019 13:56:49 +0100 (CET)

Hi,

I have some comments on draft-ietf-netconf-crypto-types-12 and
draft-ietf-netconf-keystore-14.

o  Is the key-format there to support multiple formats for the same
   kind of key (e.g., ssh key), or is it there to be able to have
   different kinds of keys in the same list?  (Or both?)

   I.e., is the intentation that a client can freely pick any
   private-key-format (that is supported by the server), regardless of
   how the key is used?

o  One idea that was floating around was to have separate keystore
   lists for different things (see the ML archives, e.g. some mails in
   the thread "crypto-types fallback strategy").  I.e. instead of the
   current:

   +--rw keystore
      +--rw asymmetric-keys
      |  +--rw asymmetric-key* [name]

   we would have something like:

   +--rw keystores
      +--rw ssh-keystore
      |  ...
      +--rw tls-keystore  // x509-keystore?
         ...

   If we don't have to support multiple formats for the same kind
   of key, I don't think we need the key-format in this case.

   With the current design it is not obvious to me how I can find all
   ssh keys, for example.

   This said, *if* we use a single generic list, I think the list in
   the current model works fine.  It is a bit complicated, but some
   complexity is inevitable with a generic model like this.

o   iana- modules

  The iana modules have a list of supported algorithms, e.g.:

       list supported-asymmetric-algorithm

  I mentioned this before - I don't think a global list like this is
  sufficient.  For example, perhaps my TLS code supports "secp521r1",
  but my SSH code does not.

And some random small things I noticed:

o  ssh-public-key-format

  The crypto model has:

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

  I think that this should be:

    description
      "The binary public key data for an SSH key, as
       specified by RFC 4253, Section 6.6, i.e.:

         string    certificate or public key format
                   identifier
         byte[n]   key/certificate data.";
    reference
      "RFC 4253: The Secure Shell (SSH) Transport Layer
                 Protocol";

  Note that the public key format in 4716 is textual:

    ---- BEGIN SSH2 PUBLIC KEY ----
    Header-tag ':' ' ' Header-value
    BODY
    ---- END SSH2 PUBLIC KEY ----

  Where BODY is:

   The body of a public key file is the base64 encoded ([RFC2045])
   public key data as specified by [RFC4253], Section 6.6:

         string    certificate or public key format identifier
         byte[n]   key/certificate data

  So with your current definition we would take this textual format
  (that has the key base64-encoded), and base64 encode the whole
  thing (includign the already base64-encoded key).

o  subject-public-key-info-format

  The crypto model has:

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

  Should this be "DER encoded"?

  (this and other defintions have references to RFCs in the
  description; they should be moved to proper "reference" statements)

o  iana-hash-algs

  This module has a bunch of shake-*:

      enum shake-224 {
        value 7;
        description
          "The SHA3 algorithm with 224-bits output.";

  I think this should be "sha3-224" etc.

  (there are just two shake hash functions defined; shake 128 & 256,
  and they have variable output)

  (and BTW, FIPS PUB 202 doesn't define sha3-128)

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 13 Nov 2019 22:02:04 +0000

Hi Martin,

>   private-key-format (that is supported by the server), regardless of

Firstly, see: https://mailarchive.ietf.org/arch/msg/netconf/5Zpj8Xxh7bHvAJeQf2Lj0t6h8hg <https://mailarchive.ietf.org/arch/msg/netconf/5Zpj8Xxh7bHvAJeQf2Lj0t6h8hg>

That said, there are some limitations that are likely not represented yet.  For instance, an encrypted private key must use "identity encrypted-private-key-format" and an encrypted symmetric key must use "identity encrypted-symmetric-key-format", as there is no way to express it otherwise.

But your question is likely more regarding the other direction, for an *unencrypted" asymmetric key, can a client arbitrarily choose one of the *-private-key-format identities or "identity one-asymmetric-key-format"; likewise, for an *unencrypted* symmetric key, can a client arbitrarily use either "identity octet-string-key-format" or "identity one-symmetric-key-format".

The goal is for the use of OneAsymmetricKey and OneSymmetricKey formats to be an advanced feature.  As said above, these structures must be used for encrypted keys, and should be used for unencrypted key (as the structure carries security attributes not present in the raw formats), but it's more likely that implementations will support the raw formats.

My thoughts are that, if an implementation is updated to support for One[A]SymmetricKey for encrypted keys, then letting a client optionally use One[A]SymmetricKey for unencrypted keys isn't that big of an implementation effort.  Thus I suggest adding features called "one-symmetric-key" and "one-asymmetric-key", and place if-feature statements under these identities so that servers can express when they support them.

>      +--rw tls-keystore  // x509-keystore?

Right, but that approach was deemed not viable before.

>   of key, I don't think we need the key-format in this case.

Maybe.

>   With the current design it is not obvious to me how I can find all

That's because keys don't have to have a set purpose.  For instance, an IDevID shipped with the device could be used for either SSH or TLS.

>   complexity is inevitable with a generic model like this.

Yes and yes.

>  but my SSH code does not.

Yes, well, this is a known problem (e.g., https://github.com/netmod-wg/yang-next/issues/82 <https://github.com/netmod-wg/yang-next/issues/82>).  I realize that you're not specifically talking about feature statements, but it's similar.  One difference between #82 and this is that here, the capabilities are presented in "config false" lists instead, which might bring us to https://github.com/netmod-wg/yang-next/issues/41 <https://github.com/netmod-wg/yang-next/issues/41> again...

>  thing (includign the already base64-encoded key).

I will say that the definition above was given because it is the only *standards* based key that `openssh` can output (i.e., `ssh-keygen -e [-m RFC4716] -f <private-key-file>`).

That said, if you refer to the link I provided at top, it is my belief that the "key-format" node may be extended to support alternate encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM).  To this end, perhaps we could support both the 4716 and 4253 formats. 

>  description; they should be moved to proper "reference" statements)

Yes.  I put together these definitions in as a test/protocol to gauge viability with the plan to enhance the definitions if the WG committed to the approach.   I just added some "FIXME" comments to my local copy.

>  (and BTW, FIPS PUB 202 doesn't define sha3-128)

I don't know.  These are are/were specified by my co-author Haiguang (CC-ed).   Haiguang, can you comment?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Nov 2019 10:05:58 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> Firstly, see:
> https://mailarchive.ietf.org/arch/msg/netconf/5Zpj8Xxh7bHvAJeQf2Lj0t6h8hg
> <https://mailarchive.ietf.org/arch/msg/netconf/5Zpj8Xxh7bHvAJeQf2Lj0t6h8hg>
> 
> That said, there are some limitations that are likely not represented
> yet.  For instance, an encrypted private key must use "identity
> encrypted-private-key-format" and an encrypted symmetric key must use
> "identity encrypted-symmetric-key-format", as there is no way to
> express it otherwise.
> 
> But your question is likely more regarding the other direction, for an
> *unencrypted" asymmetric key, can a client arbitrarily choose one of
> the *-private-key-format identities or "identity
> one-asymmetric-key-format"; likewise, for an *unencrypted* symmetric
> key, can a client arbitrarily use either "identity
> octet-string-key-format" or "identity one-symmetric-key-format".
> 
> The goal is for the use of OneAsymmetricKey and OneSymmetricKey
> formats to be an advanced feature.  As said above, these structures
> must be used for encrypted keys, and should be used for unencrypted
> key (as the structure carries security attributes not present in the
> raw formats), but it's more likely that implementations will support
> the raw formats.
> 
> My thoughts are that, if an implementation is updated to support for
> One[A]SymmetricKey for encrypted keys, then letting a client
> optionally use One[A]SymmetricKey for unencrypted keys isn't that big
> of an implementation effort.  Thus I suggest adding features called
> "one-symmetric-key" and "one-asymmetric-key", and place if-feature
> statements under these identities so that servers can express when
> they support them.

Suppose I want to configure a ssh host-key as the server-identity for
my NETCONF server.  Is the intention that a client can pick either
"ssh-public-key-format" or "subject-public-key-info-format", and the
server must support both?

> That's because keys don't have to have a set purpose.  For instance,
> an IDevID shipped with the device could be used for either SSH or TLS.
> 
> 
> Yes, well, this is a known problem (e.g.,
> https://github.com/netmod-wg/yang-next/issues/82
> <https://github.com/netmod-wg/yang-next/issues/82>).

That is quite different.

You're using a normal config false list for this (which is fine), but
I don't think you can use a single global list like this.

> I realize that
> you're not specifically talking about feature statements, but it's
> similar.  One difference between #82 and this is that here, the
> capabilities are presented in "config false" lists instead, which
> might bring us to https://github.com/netmod-wg/yang-next/issues/41
> <https://github.com/netmod-wg/yang-next/issues/41> again...
> 
> 
> 
> I will say that the definition above was given because it is the only
> *standards* based key that `openssh` can output (i.e., `ssh-keygen -e
> [-m RFC4716] -f <private-key-file>`).

With my proposal you can take the output of this openssh command and
copy & paste the base64-encoded data from this output to a YANG node
using ssh-public-key-format.

With your proposal you have to copy the entire output, base64 encode
it *again*, and then copy & paste that result to the YANG node.

> That said, if you refer to the link I provided at top, it is my belief
> that the "key-format" node may be extended to support alternate
> encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM).
> To this end, perhaps we could support both the 4716 and 4253 formats.

Do we really want to go there?  This is already quite complex, and
having a multitude of optional formats for the same thing may make
things even more complex, to understand and get right.

> Yes.  I put together these definitions in as a test/protocol to gauge
> viability with the plan to enhance the definitions if the WG committed
> to the approach.  I just added some "FIXME" comments to my local copy.

Ok.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Nov 2019 12:35:48 +0000

Hi Martin,

> server must support both?

It's assumed that the client would set the public key using "ssh-public-key-format" (per RFC 4716, as that is the only standards-based public key format that `openssh` is able to export).  While it's possible to convert the public key to a SubjectPublicKeyInfo structure, doing so is unlikely.  In either case, the same data is conveyed.

The issue presents itself when configuring the "server-identity" in ietf-ssh-server, whether a local definition or a reference to a key in the keystore.   A "must" expression could be used to constrain the supported key-formats allowed.   Our modules could hardcode this for all implementations or, if wanting to provide flexibility, we could let implementations augment-in their own 'must' expression.

>> <https://github.com/netmod-wg/yang-next/issues/82>).

How so?  Features are effectively opstate lists too and, in both cases, YANG fails to support granular discrimination. 

> I don't think you can use a single global list like this.

I don't understand this statement.

> it *again*, and then copy & paste that result to the YANG node.

Not true or, rather, the intention is to support native encoding formats, including DER vs PEM, and CMS vs multi-part PEM.   That a text-based format is base64 encoded is not an issue and, IMO, a feature as it escaping concerns when the content is placed in an XML or JSON document.

> things even more complex, to understand and get right.

Binary formats (e.g., DER) are fundamental, but some raised usability concerns, hence the exploration.  As for complexity, how do we know until we try?

>> to the approach.  I just added some "FIXME" comments to my local copy.

It helps immensely when folks can provide spec-text, either on list or as a pull request.

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Nov 2019 14:01:35 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> It's assumed that the client would set the public key using
> "ssh-public-key-format" (per RFC 4716, as that is the only
> standards-based public key format that `openssh` is able to export).
> While it's possible to convert the public key to a
> SubjectPublicKeyInfo structure, doing so is unlikely.  In either case,
> the same data is conveyed.
> 
> The issue presents itself when configuring the "server-identity" in
> ietf-ssh-server, whether a local definition or a reference to a key in
> the keystore.  A "must" expression could be used to constrain the
> supported key-formats allowed.  Our modules could hardcode this for
> all implementations

Ok.  This is worth exploring imo.

> or, if wanting to provide flexibility, we could
> let implementations augment-in their own 'must' expression.
> 
> 
> 
> How so?  Features are effectively opstate lists too and, in both
> cases, YANG fails to support granular discrimination.
> 

My point is really just that a single global list like this is not
sufficient.   It doesn't matter if "feature" has problems; a single
global config false list is not sufficient for what you're trying to
do.

> Not true or, rather, the intention is to support native encoding
> formats, including DER vs PEM, and CMS vs multi-part PEM.

But that would be different key-format identities, right?  The issue
here is about what the specfic format is for ssh-public-key-format.
The format I suggest is also already used in RFC 7317, as was pointed
out before by someone else.

> That a
> text-based format is base64 encoded is not an issue and, IMO, a
> feature as it escaping concerns when the content is placed in an XML
> or JSON document.
> 
> 
> 
> Binary formats (e.g., DER) are fundamental, but some raised usability
> concerns

Do you have a pointer to this?

> , hence the exploration.  As for complexity, how do we know
> until we try?

I think we _are_ trying now...

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Nov 2019 13:40:40 +0000

Hi Martin,

> Ok.  This is worth exploring imo.

I added FIXME comments into all of ietf-[ssh/tls]-[client/server].

> global config false list is not sufficient for what you're trying to

True.  But how can we define a way to get a list per instance?  Should there be a "config false" list wherever the "algorithm" node appears (i.e., put the list into the crypto-type groupings having the algorithm node?)

> But that would be different key-format identities, right?  

I think so, yes.

> The issue

That is the binary encoding for the on-the-wire public key.  Yes, for the binary encoding, this is a great option.  But I thought a goal was to try to use native tool formats when possible.  Not that we want to hardcode to OpenSSH, but `man ssh-keygen`:

     -m key_format
             Specify a key format for the -i (import) or -e (export)
              conversion options.  The supported key formats are:
              ``RFC4716'' (RFC 4716/SSH2 public or private key),
              ``PKCS8'' (PEM PKCS8 public key) or ``PEM'' (PEM
              public key).  The default conversion format is
              ``RFC4716''.  Setting a format of ``PEM'' when
              generating or updating a supported private key
              type will cause the key to be stored in the legacy
              PEM private key format.

> Do you have a pointer to this?

There was an email from Juergen a few months back.

> I think we _are_ trying now...

Fair, but there's yet to be a concrete proposal for how to support, e.g., multi-part PEM encoding and, in particular, how it is distinguished from the PEM encoding of the equivalent CMS.  Presumably it's just another identity, but there maybe more to it...

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Nov 2019 14:47:38 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> True.  But how can we define a way to get a list per instance?  Should
> there be a "config false" list wherever the "algorithm" node appears
> (i.e., put the list into the crypto-type groupings having the
> algorithm node?)

I don't know, probably.  Do we really want that?  Probably not.

This is exaclty why I suggested earlier that we don't spend time
trying to solve this problem at all now.  I'd rather not put in
something that we know doesn't really work.

> That is the binary encoding for the on-the-wire public key.  Yes, for
> the binary encoding, this is a great option.  But I thought a goal was
> to try to use native tool formats when possible. Not that we want to
> hardcode to OpenSSH, but `man ssh-keygen`:
> 
>      -m key_format

But that was based on a misunderstanding.  (or you mean something
else)

> Fair, but there's yet to be a concrete proposal for how to support,
> e.g., multi-part PEM encoding and, in particular, how it is
> distinguished from the PEM encoding of the equivalent CMS.  Presumably
> it's just another identity, but there maybe more to it...
> 
> 
> Kent // contributor
> 

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Nov 2019 15:41:16 +0000

Hi Martin,

> I don't know, probably.  Do we really want that?  Probably not.

Per-instance may be too granular.   If thinking that said curations occur of protocol boundaries, then maybe have a config false list in ietf-ssh-common and ietf-tis-common?   Not perfect, as an application may use more than one SSH library or more than one TLS library, but it's much less likely.

> something that we know doesn't really work.

Wait, no, there is a very real issue here that cannot be ignored.  Or do you feel that we should give up entirely on trying to enable servers to proactively express what algorithms they support?

> But that was based on a misunderstanding.  (or you mean something

Now I'm unsure what you're talking about, do you have a pointer to it?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Nov 2019 16:50:50 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> Per-instance may be too granular.  If thinking that said curations
> occur of protocol boundaries, then maybe have a config false list in
> ietf-ssh-common and ietf-tis-common?  Not perfect, as an application
> may use more than one SSH library or more than one TLS library, but
> it's much less likely.

Yes, better.

> Wait, no, there is a very real issue here that cannot be ignored.  Or
> do you feel that we should give up entirely on trying to enable
> servers to proactively express what algorithms they support?
> 
> 
> 

I am talking about this:
https://mailarchive.ietf.org/arch/browse/netconf/?q=

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Nov 2019 20:03:19 +0100 (CET)

> https://mailarchive.ietf.org/arch/browse/netconf/?q=

Should have been:

https://mailarchive.ietf.org/arch/msg/netconf/G9lHICXD5H9MzQ9D9-xMxdZIJRM

/martin