Subject: [netconf] crypto-types fallback strategy

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Sep 2019 20:05:17 +0000

[warning: wide-screen needed]

Folks,

It seems that there is little appetite to pursue a solution that entails defining many algorithm identifiers/enumerations in YANG.

In Montreal, I presented a "fallback" strategy (see slide 9 here: https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-suite-of-drafts-00 <https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-suite-of-drafts-00>) that sought to leverage ASN.1 structures (that are heavily used by TLS) as much as possible and, in particular, rather than crypto-types defining many algorithms, the YANG module instead uses existing OIDs (ASN.1 object identifiers) to identify the algorithms and ASN.1 structures to encode them.

Testing, I've determined that:

1) `openssl genrsa -out rsa_private_key.pem 2048` creates an RSAPrivateKey (from rfc3447)
     - this is a raw key; there is no OID identifying the structure, or attributes indicating how it should be used.

2) `openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem` creates a SubjectPublicKeyInfo (from rfc5280)
     - the "algorithm" field is "rsaEncryption" (thus indicating how the key is expected to be used)
     - the "parameters" field is NULL (which for some reason is actually the value b'\x05\x00')
     - the "subjectPublicKey" field is an RSAPublicKey (from rfc5480)

3) `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem` creates an ECPrivateKey (from rfc5915)
      - this is a raw key; there is no OID identifying the structure, or attributes indicating how it should be used.

4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem` creates a SubjectPublicKeyInfo (from rfc5280)
     - the "algorithm" field is "id_ecPublicKey" (but, unlike rsaEncryption, this doesn't seem to indicate how the key should be used)
     - the "parameters" field is a ECParameters (from rfc5480) and (for me) contains 'namedCurve' being an OID containing value "secp256r1"
     - the "subjectPublicKey" field is an ECPoint (from rfc5480), which contains the value of a point on the curve.

I've been discussing all this offline with security experts (especially wrt all these ASN.1 structures) Russ Housley and Sean Turner (CC-ed) for about a week now.  I now feel the need to get some WG feedback before proceeding much further...

Here are some options:

OPTION A
========
- Continue pursuing the solution in the draft as is - a holistic mapping of many algorithm identifiers (more than needed for our use).
- Note that everyone that showed interest before haven't been heard from in awhile.

OPTION B
========
- move towards a fallback strategy (two variants are proposed below)
- both variations share the following common attributes:
    a) remove all the crypto-algorithm enumerations from the YANG module (~70% of the lines)
    b) use ASN.1 structures to encode symmetric and asymmetric key, both unencrypted and encrypted.
    c) figure out a plan for SSH later (the risk level is pretty low, e.g., I've seen code to key SSH keys from TLS keys)

Okay, so now for the two variants:  B1 and B2...

OPTION B1  (use raw/native keys)
----------------------------------------------
PROs: mostly supported by OpenSSL command line (see commands 1-4 above) [missing: commands illustrating key-encryption]
CONs: private keys have no way to declare their intended use (encrypt vs sign) or modes (CBS vs GCM).  some usage information could be stored in the public key.  no key usage information stored for symmetric keys.

module: ietf-keystore
     +--rw keystore
        +--rw asymmetric-keys
        |  +--rw asymmetric-key* [name]
        |     +--rw name                                  arbitrary user-set value
        |     +--rw algorithm                             <---- this becomes an OID (e.g., "rsaEncryption")
        |     +--rw public-key                            <---- this becomes SubjectPublicKeyInfo ASN.1 structure
        |     +--rw (private-key-type)
        |        +--:(private-key)
        |        |  +--rw private-key?                   <---- this becomes a raw ASN.1 key (e.g., RSAPrivateKey, ECPrivateKey)
        |        +--:(encrypted-private-key)
        |           +--rw encrypted-private-key
        |              +--rw (key-type)
        |              |  +--:(symmetric-key-ref)
        |              |  |  +--rw symmetric-key-ref?     leafref // ref to another key in keystore
        |              |  +--:(asymmetric-key-ref)
        |              |     +--rw asymmetric-key-ref?    leafref // ref to another key in keystore
        |              +--rw value?                       <--- this becomes an CMS EncryptedData structure containing an OneAsymmetricKey (from rfc5958)
        |
        +--rw symmetric-keys
           +--rw symmetric-key* [name]
              +--rw name                                  // arbitrary user-set value
              +--rw algorithm                            <---- TBD, mostly likely an AlgID value from rfc7210
              +--rw (key-type)
                 +--:(key)
                 |  +--rw key?                              <---- this becomes an OctetString (ASN.1 structure)
                 +--:(encrypted-key)
                    +--rw encrypted-key
                       +--rw (key-type)
                       |  +--:(symmetric-key-ref)
                       |  |  +--rw symmetric-key-ref?      // leafref to another key in keystore
                       |  +--:(asymmetric-key-ref)
                       |     +--rw asymmetric-key-ref?    // leafref to another key in keystore
                       +--rw value?                        <---- this becomes an CMS EncryptedData structure containing an OneSymmetricKey (from rfc6031)

OPTION B2  (use OneSymmetricKey and OneAsymmetricKey)
------------------------------------------------------------------------------------
PROs: private keys can declare their intended use (encrypt vs sign) and modes (CBS vs GCM)
CONs: not supported by OpenSSL command line (but are by languages, e.g., Python)

module: ietf-keystore
     +--rw keystore
        +--rw asymmetric-keys
        |  +--rw asymmetric-key* [name]
        |     +--rw name                                   // arbitrary user-set value
        |     +--rw algorithm                             <---- this could be deleted, or set to the same OID as in B1
        |     +--rw public-key                            <---- SubjectPublicKeyInfo ASN.1 structure  (same as in B1)
        |     +--rw (private-key-type)
        |        +--:(private-key)
        |        |  +--rw private-key?                   <---- this becomes a ASN.1 OneAsymmetricKey (from rfc5958)
        |        +--:(encrypted-private-key)
        |           +--rw encrypted-private-key
        |              +--rw (key-type)
        |              |  +--:(symmetric-key-ref)
        |              |  |  +--rw symmetric-key-ref?      // leafref to another key in keystore
        |              |  +--:(asymmetric-key-ref)
        |              |     +--rw asymmetric-key-ref?    // leafref to another key in keystore
        |              +--rw value?                         <---- CMS EncryptedData ASN.1 structure (same as in B1)
        |
        +--rw symmetric-keys
           +--rw symmetric-key* [name]
              +--rw name                                  arbitrary user-set value
              +--rw algorithm                            <---- this could be deleted, or set to the same AlgID value from B1
              +--rw (key-type)
                 +--:(key)
                 |  +--rw key?                              <---- this becomes a ASN.1 OneSymmetricKey (from rfc6031)
                 +--:(encrypted-key)
                    +--rw encrypted-key
                       +--rw (key-type)
                       |  +--:(symmetric-key-ref)
                       |  |  +--rw symmetric-key-ref?     leafref to another key in keystore
                       |  +--:(asymmetric-key-ref)
                       |     +--rw asymmetric-key-ref?    leafref to another key in keystore
                       +--rw value?                        <---  CMS EncryptedData ASN.1 structure (same as in B1)

In summary:
    - B1 is easier to support unencrypted keys, but fails to support some things important to some security folks (not me).
    - B1 complexity to support encrypted keys is TBD (I'm told OpenSSL command line can do it, but have yet to verify)
    - B2 is preferred by crypto folks, but lack an OpenSSL command line will thwart the development of simple scripts.
    - NC/RC are programmatic APIs, so complexity shouldn't be driving factor, though it may affect solution adoption.

Thoughts?

Kent // co-author

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 11 Sep 2019 20:27:03 +0000

*   It seems that there is little appetite to pursue a solution that entails defining many algorithm identifiers/enumerations in YANG.

I am glad of this.

An important thing to realize is that many cryptographic datatypes were designed for special purposes, and breaking everything down into its component parts defeats some of the security (separating the parameters from an RSA-PSS key, for example), or deployment issues (such as separating the signature from the certificate request or splitting up a CA cert chain into the individual certs).

Do not try for an omnibus of cryptographic types – any given application will almost definitely never have to use all the types in a module. Start with something small, such as what is needed to configure an HTTPS server – a cert chain, an end-entity cert, and a private key.  All of these can be handled by OpenSSL command-line.  Future modules could add SSH provisioning, VPN key management, Kerberos login actions, and suchlike.

Starting with the HTTPS server, all of those objects are, as you point out, structures defined in ASN1 and encoded in DER. For configuration, they are generally maintained as base-64 encoded files, with a known header and trailer line. This is popularized by OpenSSL as the PEM format, which harkens back to RFC 1421. RFC 7468 is an excellent starting point for actual use of that.

Hope this helps.  I would be glad to contribute to a draft developed along these lines.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Sep 2019 11:12:42 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> It seems that there is little appetite to pursue a solution that
> entails defining many algorithm identifiers/enumerations in YANG.
> 
> In Montreal, I presented a "fallback" strategy (see slide 9 here:
> https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-suite-of-drafts-00
> <https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-suite-of-drafts-00>)
> that sought to leverage ASN.1 structures (that are heavily used by
> TLS) as much as possible and, in particular, rather than crypto-types
> defining many algorithms, the YANG module instead uses existing OIDs
> (ASN.1 object identifiers) to identify the algorithms and ASN.1
> structures to encode them.
> 
>      - this is a raw key; there is no OID identifying the structure, or
>      - attributes indicating how it should be used.
> 
> 2) `openssl rsa -in rsa_private_key.pem -pubout -out
> rsa_public_key.pem` creates a SubjectPublicKeyInfo (from rfc5280)
>      - the "algorithm" field is "rsaEncryption" (thus indicating how the key
>      - is expected to be used)
>      - the "parameters" field is NULL (which for some reason is actually the
>      - value b'\x05\x00')
>       - this is a raw key; there is no OID identifying the structure, or
>       - attributes indicating how it should be used.
> 
> 4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem`
> creates a SubjectPublicKeyInfo (from rfc5280)
>      - the "algorithm" field is "id_ecPublicKey" (but, unlike rsaEncryption,
>      - this doesn't seem to indicate how the key should be used)
>      - the "parameters" field is a ECParameters (from rfc5480) and (for me)
>      - contains 'namedCurve' being an OID containing value "secp256r1"
>      - the "subjectPublicKey" field is an ECPoint (from rfc5480), which
>      - contains the value of a point on the curve.
> 
> 
> I've been discussing all this offline with security experts
> (especially wrt all these ASN.1 structures) Russ Housley and Sean
> Turner (CC-ed) for about a week now.  I now feel the need to get some
> WG feedback before proceeding much further...
> 
> Here are some options:
> 
> OPTION A
> ========
> - Continue pursuing the solution in the draft as is - a holistic mapping
> - of many algorithm identifiers (more than needed for our use).
> - Note that everyone that showed interest before haven't been heard from
> - in awhile.
> 
> OPTION B
> ========

I'm not a security expert so I don't have any input on which ASN.1
structure to support.

But it seems to me that in both B1 and B2, the "algorithm" leaf isn't
really necessary in the config, right?  I guess it is still needed
when a key is generated though.  But then note that "rsaEncryption" is
not an OID ("1.2.840.113549.1.1.1" is the OID).  If you want to use a
symbolic name you need something else.

Is the idea that the module becomes ietf-tls-keystore with top-level
node tls-keystore?

>     c) figure out a plan for SSH later

Hmm, what does this mean?  That we won't do ietf-netconf-server now?

> PROs: mostly supported by OpenSSL command line (see commands 1-4
> above) [missing: commands illustrating key-encryption]
> CONs: private keys have no way to declare their intended use (encrypt
> vs sign) or modes (CBS vs GCM).  some usage information could be
> stored in the public key.  no key usage information stored for
> symmetric keys.
> 
> module: ietf-keystore
>      +--rw keystore
>         +--rw asymmetric-keys
>         |     +--rw public-key <---- this becomes SubjectPublicKeyInfo ASN.1
>         |     structure
>         |        |  +--rw private-key?  <---- this becomes a raw ASN.1 key
>         |        |  (e.g., RSAPrivateKey, ECPrivateKey)
>         |              |  |  +--rw symmetric-key-ref?  leafref // ref to
>         |              |  |  another key in keystore
>         |              |     +--rw asymmetric-key-ref?  leafref // ref to
>         |              |     another key in keystore
>         |              +--rw value?  <--- this becomes an CMS EncryptedData
>         |              structure containing an OneAsymmetricKey (from rfc5958)
>         |
>         +--rw symmetric-keys
>                  |  +--rw key?  <---- this becomes an OctetString (ASN.1
>                  |  structure)
>                  +--:(encrypted-key)
>                     +--rw encrypted-key
>                        +--rw (key-type)
>                        |  |  +--rw symmetric-key-ref?  // leafref to another
>                        |  |  key in keystore
>                        |     +--rw asymmetric-key-ref?  // leafref to another
>                        |     key in keystore
>                        +--rw value?  <---- this becomes an CMS EncryptedData
>                        structure containing an OneSymmetricKey (from rfc6031)
> 
> 
> 
>         |     +--rw algorithm <---- this could be deleted, or set to the same
>         |     OID as in B1
>         |     +--rw public-key <---- SubjectPublicKeyInfo ASN.1 structure (same
>         |     as in B1)
>         |        |  +--rw private-key?  <---- this becomes a ASN.1
>         |        |  OneAsymmetricKey (from rfc5958)
>         |              |  |  +--rw symmetric-key-ref?  // leafref to another
>         |              |  |  key in keystore
>         |              |     +--rw asymmetric-key-ref?  // leafref to another
>         |              |     key in keystore
>         |              +--rw value?  <---- CMS EncryptedData ASN.1 structure
>         |              (same as in B1)
>         |
>         +--rw symmetric-keys
>                  |  +--rw key?  <---- this becomes a ASN.1 OneSymmetricKey
>                  |  (from rfc6031)
>                  +--:(encrypted-key)
>                     +--rw encrypted-key
>                        +--rw (key-type)
>                        |  |  +--rw symmetric-key-ref?  leafref to another key
>                        |  |  in keystore
>                        |     +--rw asymmetric-key-ref?  leafref to another key
>                        |     in keystore
>     - B1 is easier to support unencrypted keys, but fails to support some
>       things important to some security folks (not me).
>     - B1 complexity to support encrypted keys is TBD (I'm told OpenSSL
>       command line can do it, but have yet to verify)
>     - B2 is preferred by crypto folks, but lack an OpenSSL command line will
>       thwart the development of simple scripts.
>     - NC/RC are programmatic APIs, so complexity shouldn't be driving
>       factor, though it may affect solution adoption.

Yes, NC/RC are programmatic APIs, but simplicity is always goodness...

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 12 Sep 2019 14:58:02 +0000

Hi Rich,

>  Hope this helps.  I would be glad to contribute to a draft developed along these lines.

We would be happy to have your eyes on this draft.  Thank you. 

Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 12 Sep 2019 16:39:33 +0000

Hi Martin,

> really necessary in the config, right?  

The "algorithm" leaf is needed, because a "private-key" itself enough.  The RSAPrivateKey and ECPrivateKey ASN.1 structures contain just the raw key fields (e.g., RSA --> [d, p, q, n,e]).  The two structures do not share a common base type that would presumably identify if the payload is an RSAPrivate key or ECPrivateKey, so the the correct parser can be used.  We could argue that private keys should always come with a public key, in which case we could claim that, for B1, the typing of the private key is done via the typing of the public key.  I don't prefer this approach and, as you say, the same algorithm identifier would have to be passed into the generate-asymmetric-key() and generate-symmetric-key() actions, so having the field in the configuration seems right.

> I guess it is still needed

Isn't it?  Check https://tools.ietf.org/html/rfc3279#section-2.3.1 <https://tools.ietf.org/html/rfc3279#section-2.3.1>.

> Is the idea that the module becomes ietf-tls-keystore with top-level

There is no need to change the "keystore" module's name.  ASN.1 is not TLS-specific, it just so happens to be heavily used by TLS.

Already, and for awhile now, the ietf-crypto-types module has defined the private-key and public-key using type "binary" with a description statement saying that how it is parsed is defined by the "algorithm" field.   The description statements even say that the RSAPublicKey/RSAPrivateKey formats are defined in RFC8017 and the EC public/private key formats are defined in rfc5915.  These unnamed formats are actually the same ASN.1 structures mentioned in my OP.   So this was/is sort of been the plan all along.  

> Hmm, what does this mean?  That we won't do ietf-netconf-server now?

More fully, that line says: 

The intention was to signal that it should be easy to determine how to support SSH, to support the netconf-client-server draft.  Nothing is blocked.  We just need to discuss a plan for what to do.  The easiest thing would be to 1) update the mapping table in the ssh-client-server drafts from mapping SSH-specific algorithm identifiers (e.g., in rfc4253) to OIDs, and 2) this could get moved into a section called "Implementation Considerations" that also notes that is an implementation convert between the ASN.1 structures used by, e.g., keystore, and the local SSH implementation (e.g., OpenSSH).

> Yes, NC/RC are programmatic APIs, but simplicity is always goodness...

ACK, but let's be clear that the "simplicity" is in the ready access to tooling, not from an algorithmic perspective.   

According to [1], the private-key format is identical to OpenSSL's private key format (i.e., it uses RSAPrivateKey/ECPrivateKey, not OneAsymmetricKey or something else).  Thus, the only conversion needed is to/from OpenSSH's public key format.  This does not appear to be hard, e.g., [2] has code showing how to do this using Python.

[1] http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG%2C-OpenSsh-and-OpenSSL <http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG,-OpenSsh-and-OpenSSL>
[2] https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/ <https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/>

Kent // as author

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Sep 2019 17:02:27 +0000

You should not require every private key to have  the public key; they are often separated – e.g., most SSH implementations separate them. As you point out, they don’t share the same ASN1 data structures: a “25519” key is a bytestring, a DH key is two “bignums” (in OpenSSL terms), an RSA key is different from a DSA key, and so on.

I think saying “used by TLS” is not a good reason, we should really talk about the applications we are trying to configure and manage.  Or am I hopelessly wrong about netconf?  That could be likely, I’m only here for the crypto objects dicussions.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 12 Sep 2019 17:46:31 +0000

Hi Rich,

> I think saying “used by TLS” is not a good reason, we should really talk about the applications we are trying to configure and manage. 

For reference, the full sentence was: ASN.1 is not TLS-specific, it just so happens to be heavily used by TLS.

The focus of this work is primarily to enable the configuration of NETCONF and RESTCONF servers.   NETCONF can use either SSH or TLS as a transport, and RESTCONF is always HTTPS.    The current structure of the suite of client-server drafts includes generic SSH and TLS layers (and likely a DTLS layer someday) that have already been adopted by other work-in-progress at the IETF (e.g., models for PCEP, Syslog, etc.), so the scope of the SSH and TLS layers is a little wider than just NETCONF and RESTCONF.  That said, I can't think of anything that has been done to date to cater to any external effort.

> Or am I hopelessly wrong about netconf?  That could be likely, I’m only here for the crypto objects dicussions.

Right.  My claim is that ASN.1 for storing keys is a pretty universal.   I don't think we give up much by formally claiming all the key values are ASN.1 structures but, importantly, by doing so, using OIDs becomes natural, thus obsoleting the need to define our own set of algorithm identifiers in YANG, which significantly motivates this thread.  Makes sense?

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Sep 2019 19:58:59 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> The "algorithm" leaf is needed, because a "private-key" itself enough.
> The RSAPrivateKey and ECPrivateKey ASN.1 structures contain just the
> raw key fields (e.g., RSA --> [d, p, q, n,e]).  The two structures do
> not share a common base type that would presumably identify if the
> payload is an RSAPrivate key or ECPrivateKey, so the the correct
> parser can be used.  We could argue that private keys should always
> come with a public key, in which case we could claim that, for B1, the
> typing of the private key is done via the typing of the public key.  I
> don't prefer this approach and, as you say, the same algorithm
> identifier would have to be passed into the generate-asymmetric-key()
> and generate-symmetric-key() actions, so having the field in the
> configuration seems right.
> 
> 
> Isn't it?  Check https://tools.ietf.org/html/rfc3279#section-2.3.1
> <https://tools.ietf.org/html/rfc3279#section-2.3.1>.

The symbolic name is not (guaranteed to be) globally unique.

> There is no need to change the "keystore" module's name.

So where would keys for SSH go?  Your reasoning was (which I agree
with) don't create a super-generic module for all things crypto /
keys, but let's focus on what we need (you wrote "to configure an
HTTPS server).  If we limit ourselves to TLS it should be reflected in
the naming.   But perhaps I misunderstood your intention.

> ASN.1 is not
> TLS-specific, it just so happens to be heavily used by TLS.
> 
> Already, and for awhile now, the ietf-crypto-types module has defined
> the private-key and public-key using type "binary" with a description
> statement saying that how it is parsed is defined by the "algorithm"
> field.  The description statements even say that the
> RSAPublicKey/RSAPrivateKey formats are defined in RFC8017 and the EC
> public/private key formats are defined in rfc5915.  These unnamed
> formats are actually the same ASN.1 structures mentioned in my OP.  So
> this was/is sort of been the plan all along.

Right, but at that time the idea was to be able to have very generic
"algorithm", and have each alg define its own format, right?  As soon
as we limit "algorithm" and the format for the key, we are no longer
generic.  Hence we should have a less generic name, that more
precisely decribe what it is.

> 	c) figure out a plan for SSH later (the risk level is pretty low,
> 	e.g., I've seen code to key SSH keys from TLS keys)
> 
> The intention was to signal that it should be easy to determine how to
> support SSH, to support the netconf-client-server draft.  Nothing is
> blocked.  We just need to discuss a plan for what to do.  The easiest
> thing would be to 1) update the mapping table in the ssh-client-server
> drafts from mapping SSH-specific algorithm identifiers (e.g., in
> rfc4253) to OIDs

But do these OIDs exist already?

>, and 2) this could get moved into a section called
> "Implementation Considerations" that also notes that is an
> implementation convert between the ASN.1 structures used by, e.g.,
> keystore, and the local SSH implementation (e.g., OpenSSH).
>
> ACK, but let's be clear that the "simplicity" is in the ready access
> to tooling, not from an algorithmic perspective.

But the solution becomes more robust if you can use the format you're
used to w/o additional conversion.

> According to [1], the private-key format is identical to OpenSSL's
> private key format (i.e., it uses RSAPrivateKey/ECPrivateKey, not
> OneAsymmetricKey or something else).  Thus, the only conversion needed
> is to/from OpenSSH's public key format.  This does not appear to be
> hard, e.g., [2] has code showing how to do this using Python.
> 
> [1]
> http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG%2C-OpenSsh-and-OpenSSL
> <http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG,-OpenSsh-and-OpenSSL>
> [2]
> https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/
> <https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/>

/martin

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Sep 2019 18:04:30 +0000

Thanks, it’s reasonable :)

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 13 Sep 2019 08:48:05 +0000

Hi Kent,

I feel that this is outside my area of expertise, and hence I have a slight concern that my comments may needless derail a discussion rather than provide useful input.

But I have three comments:

  1.  I think that using a numerical OID to identify crypto algorithms doesn't seem like a great choice.  Seeing a config file say something like "rsaEncryption" instead of some OID string seems to be much more human friendly.  And as Martin says, using the OID name has no guarantees of being unique.

  1.  I wonder if changing from identifiers to enums was a mistake.  If we were to use YANG identifiers then we wouldn't need to define them all now, and they wouldn't all need to be defined in the same YANG module.  In fact, if we were to go back to using identifiers then perhaps NETCONF should restrict itself to only defining the identifiers that we actually need now, and leave the rest to the security folks to figure out, probably as separate modules defining the extra identifiers that they need, or as a bis version of the crypto-types draft if required.

  1.  I'm not sure that I understand why we would always want to always use ASN.1 to describe the keys for all algorithms.  Could we just leave the algorithm identities to define what format they use?   If we were to go back to using identities when we could have the choice of using multiple inheritance and then have a separate set of identities to allow the key formats to be defined.  Note, I have no objection to ASN.1 being used for some/most the keys if that is the right encoding.

Hopefully the comments are useful, apologies if they are not!

Thanks,
Rob

From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: 11 September 2019 21:05
To: [email-masked]
Cc: Russ Housley <[email-masked]>; Rifaat Shekh-Yusef <[email-masked]>; Sean Turner <[email-masked]>
Subject: [netconf] crypto-types fallback strategy

Folks,

In Montreal, I presented a "fallback" strategy (see slide 9 here: https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-suite-of-drafts-00) that sought to leverage ASN.1 structures (that are heavily used by TLS) as much as possible and, in particular, rather than crypto-types defining many algorithms, the YANG module instead uses existing OIDs (ASN.1 object identifiers) to identify the algorithms and ASN.1 structures to encode them.

Here are some options:

OPTION A
========

OPTION B
========

module: ietf-keystore
     +--rw keystore
        +--rw asymmetric-keys

module: ietf-keystore
     +--rw keystore
        +--rw asymmetric-keys

In summary:

Thoughts?

Kent // co-author

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 13 Sep 2019 13:41:05 +0000

> I think that using a numerical OID to identify crypto algorithms doesn’t seem like a great choice

Every OID definition I’ve seen has a name, often both a short name and a long name.  Look at https://oid-info.com  There is also a URN syntax for OID’s. The widely-used OpenSSL has a built-in mapping; see https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt .

> I wonder if changing from identifiers to enums was a mistake.  If we were to use YANG identifiers then we wouldn’t need to define them all now, and they wouldn’t all need to be defined in the same YANG module.  In fact, if we were to go back to using identifiers then perhaps NETCONF should restrict itself to only defining the identifiers that we actually need now, and leave the rest to the security folks to figure out, probably as separate modules defining the extra identifiers that they need, or as a bis version of the crypto-types draft if required.

I am strongly in favor of not trying to create a unified module for *all* cryptography, as I have posted before.  I don’t know enough about YANG to know if this is the only way to achieve that, but this seems like the right thing to do. There are new types of crypto coming (look at what CFRG is doing), and they are likely to create new object types.

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 13 Sep 2019 14:05:06 +0000

> Every OID definition I’ve seen has a name, often both a short name and a long name.  Look at https://oid-info.com  There is also a URN syntax for OID’s. The widely-used OpenSSL has a built-in mappi…

This can get nasty. There are interpretations of what OIDs and
associated 'names' are but in good old ASN.1 things often look quite
different. Even the dotted numeric notation 1.3.6.1 is an IETF
invention, not an ASN.1 notation. The OID URN notation is actually
using a sequence of numbers (see RFC 3061). In ASN.1, you would write
an OID value as { iso(1) org(3) dod(6) iana(1) } and you can associate
'descriptors' to the numbers but they are scoped to the branching
level and I think they only need to be unique within the usage
context. The above does not define that 'dod' always resolves to
1.3.6, or more correctly, to { iso(1) org(3) dod(6) }. In fact, {
iso(1) org(3) foo(6) } is just as good. In some context the uniqueness
issue has been addresses by using ASN.1 module names as prefixes with
different notational markup and so on. The crypto people seem to
bypass this issue by creating long descriptors that hopefully have a
low probability to clash and they seem to treat these descriptor as
registered names, which from an ASN.1 perspective they are not.

Perhaps it is best to not look too much behind the curtain and just
talk about using existing names, avoiding to dive into details what
these names really are and where they come from. Perhaps we need to
move to a more opaque type that can hold names of crypto algorithms
and we point to well-known names (i.e., defined in some IANA
registries) that apply to certain protocol contexts.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Sep 2019 16:41:26 +0000

Hi Martin,

> The symbolic name is not (guaranteed to be) globally unique.

Probably...

> the naming.   But perhaps I misunderstood your intention.

Some options:

1) use a 'union' between the two key types (binary vs string)
2) add a new 'case' to the "private-key" choice called "ssh-key"
3) go back to -04 draft with top-level "host-keys" container

Of these, (2) is the obvious choice. 

> precisely decribe what it is.

s/ ietf-crypto-types / ietf-asn1-types /?

> But do these OIDs exist already?

Probably.  Regardless, we have to map them to something.  Look at ssh-client-server draft.

> used to w/o additional conversion.

Right, see option (2) above.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Sep 2019 16:49:12 +0000

Hi Rob,

> I think that using a numerical OID to identify crypto algorithms doesn’t seem like a great choice.  Seeing a config file say something like “rsaEncryption” instead of some OID string seems to be much more human friendly.  And as Martin says, using the OID name has no guarantees of being unique.

On only this very last point, I'm unsure about that.

> I wonder if changing from identifiers to enums was a mistake.  If we were to use YANG identifiers then we wouldn’t need to define them all now, and they wouldn’t all need to be defined in the same…

Seems like a reasonable approach, but I don't know how that differs, in the end, from the uber definition some folks have voiced a concern for.  Maybe we need to understand better what that concern is better.

> I’m not sure that I understand why we would always want to always use ASN.1 to describe the keys for all algorithms.  Could we just leave the algorithm identities to define what format they use?   If we were to go back to using identities when we could have the choice of using multiple inheritance and then have a separate set of identities to allow the key formats to be defined.  Note, I have no objection to ASN.1 being used for some/most the keys if that is the right encoding.

Perhaps we can do both, say that the field is parsed according to its "algorithm" value, but for now, all algorithm identifiers happen to point to ASN.1 structures.

> Hopefully the comments are useful, apologies if they are not!

All good.  Keep them coming.

Kent

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 16 Sep 2019 16:50:03 +0000

>> But then note that "rsaEncryption" is not an OID ("1.2.840.113549.1.1.1" is the OID).  If you want to use a symbolic name you need something else.

> Isn't it?  Check https://tools.ietf.org/html/rfc3279#section-2.3.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3279-23section-2D2.3.1&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=uYE8fXe6R23tavktnaIS9n7HaOtjLgXaih-2ULwnT3s&s=F-SWW3M7EQbKppPsaMqMKmtplgkzg6IO-RcRSpljAtU&e=>

If you are referring to this line:

           rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

The intent is that it only defines a symbolic name to be used as a short-hand prefix of an OID string within that specific ASN1 module definition.  For example, pkcs-1 is a prefix is a prefix for 1.2.840.113549.1.1 and is not expected or required to be unique globally.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Sep 2019 16:58:13 +0000

Hi Rich, Rob,

> Every OID definition I’ve seen has a name, often both a short name and a long name.  Look at https://oid-info.com <https://oid-info.com/>  There is also a URN syntax for OID’s. The widely-used OpenSSL has a built-in mapping; see https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt <https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt> .

I believe that each OID has a common name that can be used.

nit: s/https/http/   (the site didn't resolve until I removed the 's')

> I am strongly in favor of not trying to create a unified module for *all* cryptography, as I have posted before.  I don’t know enough about YANG to know if this is the only way to achieve that, but…

Rich, can you explain why not try to define a unified module for all cryptography?   Is it because it is a monster effort?   Would many smaller efforts that, together, achieve the same thing be different in a meaningful way?

Kent

---

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Sep 2019 17:04:34 +0000

Hi Juergen,

> registries) that apply to certain protocol contexts.

I use thinking that we'd use numbers only, or more precisely, the ASN.1 OID structure.   An OID's common "name" value is only "needed" for presentation; though it makes using `genarate-asymmetric-key" and `generate-symmetric-key` more complicated, as both actions need to take an "algorithm" parameter.

Kent // co -author

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 16 Sep 2019 17:10:09 +0000

*   I believe that each OID has a common name that can be used.

You can use those names within a module that you are defining, but be prepared to handle collisions when you import multiple modules.  I am not aware of any, but there is absolutely no requirement that one module will not have something like:
                foo ::= OBJECT IDENTIFIER { 1 2 3 . . . }
and another will have
                foo ::= OBJECT IDENTIFIER { 1 2 5 . . . }

  *   Rich, can you explain why not try to define a unified module for all cryptography?   Is it because it is a monster effort?   Would many smaller efforts that, together, achieve the same thing be different in a meaningful way?

Two reasons:

  1.  The data structures are different, and the security communities are different.  There are many people familiar with HTTPS configuration and TLS, and there are many people familiar with SSH key management, but the overlap between those two communities is a fraction of either one.

  1.  I prefer bite-sized chunks rather than a boil the ocean effort.

  1.  They are separate things; TLS uses X509 and PKCS structures, generally; SSH often uses “raw” public keys.  See https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/ for an explanation.

Make sense?

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Mon, 16 Sep 2019 18:31:37 +0000

> I use thinking that we'd use numbers only, or more precisely, the ASN.1 OID structure.   An OID's common "name" value is only "needed" for presentation; though it makes using `genarate-asymmetric-k…

If there is one thing almost everybody did hate about SNMP, then it is
ASN.1 OIDs. And with OID I mean a sequence of numbers (not any
descriptors or such things). There is a reason why YANG has support
for other naming systems. It feels odd to go back to OIDs.

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 17 Sep 2019 10:10:31 +0000

Hi Kent,

From: Kent Watsen <[email-masked]>
Sent: 16 September 2019 17:49
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]; Russ Housley <[email-masked]>; Rifaat Shekh-Yusef <[email-masked]>; Sean Turner <[email-masked]>
Subject: Re: [netconf] crypto-types fallback strategy

Hi Rob,

1.      I think that using a numerical OID to identify crypto algorithms doesn’t seem like a great choice.  Seeing a config file say something like “rsaEncryption” instead of some OID string seems to be much more human friendly.  And as Martin says, using the OID name has no guarantees of being unique.

On only this very last point, I'm unsure about that.
[RW]
The full numerical OID string is unique, but very hard to be interpreted by a human.  The human readable OID name (e.g. for just the last element) is not unique.

I agree with Juergen, in that I think that using OIDs as names for encryption protocols is probably a mistake and tying us into the past.

2.      I wonder if changing from identifiers to enums was a mistake.  If we were to use YANG identifiers then we wouldn’t need to define them all now, and they wouldn’t all need to be defined in the same YANG module.  In fact, if we were to go back to using identifiers then perhaps NETCONF should restrict itself to only defining the identifiers that we actually need now, and leave the rest to the security folks to figure out, probably as separate modules defining the extra identifiers that they need, or as a bis version of the crypto-types draft if required.

Seems like a reasonable approach, but I don't know how that differs, in the end, from the uber definition some folks have voiced a concern for.  Maybe we need to understand better what that concern is better.
[RW]
Oops, my comment about should have been identities rather than identifiers!

I think that it is helpful that identities are extensible and can easily be constructed in a modular way.  E.g. defining identities in different YANG modules, and/or putting them under if-feature allows implementations to choose which ones they actually support.

In ietf-crypto-types I would define the base identities for:

hash-algorithm, asymmetric-key-algorithm, mac-algorithm, encryption-algorithm, encryption-and-mac-algorithm, signature-algorithm, key-exchange-algorithm

Note, as an aside, I am I also wondering whether the “encryption-and-mac-algorithm” identity should derive from both “mac-algorithm” and “encryption-algorithm”?  Or perhaps it doesn’t need to be defined at all, and the actual identities can just derive from two base identities?

I then suggest that we put different identities into different YANG modules, perhaps something roughly like:

  *   Ietf-crypto-sha-types.yang for the SHA hash identities (RFC 6234)
  *   Ietf-crypto-rsa-types for RSA asymmetric-key-algorithm (RC 8017)
  *   Ietf-crypto-elliptic-curve-types for the Elliptic Curve based algorithms (RFC 6090, 5480, 8422)
  *   Ietf-crypto-mac-types – I’m not really sure how to organize the MAC algorithm types, or even if they need to be defined now.
  *   Ietf-crypto-aes-types – AES encryption types (RFC 4309)
  *   Ietf-crypto-ssh-types – das-sha1, rsaasa-pkcs1-sha1 (RFC 4253)
  *   Ietf-crypto-tls-types – (RFC 8446)
  *   Ietf-cyprto-dhe-types – Diffier Hellman key exchange (RFC 7919).  Actually, the key-exchanges algorithm types might need to be split up a bit further.

The key step is that I would say that NETCONF should only standardizes the ones that we need now.  For the others, we could potentially create the YANG modules and either hand this off to the security groups, or work whether them to standardize these through the appropriate WGs.

3.      I’m not sure that I understand why we would always want to always use ASN.1 to describe the keys for all algorithms.  Could we just leave the algorithm identities to define what format they use?   If we were to go back to using identities when we could have the choice of using multiple inheritance and then have a separate set of identities to allow the key formats to be defined.  Note, I have no objection to ASN.1 being used for some/most the keys if that is the right encoding.

Perhaps we can do both, say that the field is parsed according to its "algorithm" value, but for now, all algorithm identifiers happen to point to ASN.1 structures.
[RW]
Yes, in essence I think that is what I’m suggesting.

If this is really common, then an identity for “ASN.1 encoded” could also be defined and inherited by crypto type identities above.  I think that this depends on how useful it is to programmatically know that they are encoded in ASN.1

Thanks,
Rob

Kent

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Sep 2019 13:54:46 +0000

*   In ietf-crypto-types I would define the base identities for:

I am not very comfortable with that division, as the same key material can be used in multiple places, and we’re transporting key material.  A symmetric key can be used to both encrypt data, and to do an HMAC “signature.”  As a minor note, it omits Key Derivation Functions, KDF, which are a key part of TLS 1.3 and used for “exporting” keys from TLS up to the application layer among other things.

  *   The key step is that I would say that NETCONF should only standardizes the ones that we need now.

A very strong yes for this.

  *     For the others, we could potentially create the YANG modules and either hand this off to the security groups, or work whether them to standardize these through the appropriate WGs.

I think it would be worthwhile to contact the Security AD’s and ask for time to present this somewhere, like the open SAAG meeting.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 17 Sep 2019 14:09:33 +0000

Hi Rich,

From: Salz, Rich <[email-masked]>
Sent: 17 September 2019 14:55
To: Rob Wilton (rwilton) <[email-masked]>; Kent Watsen <[email-masked]>
Cc: Russ Housley <[email-masked]>; [email-masked]; Sean Turner <[email-masked]>; Rifaat Shekh-Yusef <[email-masked]>
Subject: Re: [netconf] crypto-types fallback strategy

Ø  In ietf-crypto-types I would define the base identities for:

[RW]
These base identities are just the ones that were already defined in cypto-types-08.  I.e. really I am just saying that defining the base identities in the crypto types draft is the right thing to do, whereas the actual identities can be defined in separate types modules.

I am not very comfortable with that division, as the same key material can be used in multiple places, and we’re transporting key material.  A symmetric key can be used to both encrypt data, and to do an HMAC “signature.”  As a minor note, it omits Key Derivation Functions, KDF, which are a key part of TLS 1.3 and used for “exporting” keys from TLS up to the application layer among other things.
[RW]
If you had an algorithm that can be used for multiple things then it can just derive from multiple base identities.

E.g. if you take “aes-128-ccm” (from draft-ietf-netconf-crypto-types-08) that is currently has “encryption-and-mac-algorithm” as its base, it could be defined as follows, allowing it to be used either as a mac-algorithm or an encryption algorithm:

    identity aes-128-ccm {
      base encryption-algorithm;
      base mac-algorithm;
      description
        "Encrypt message with AES algorithm in CCM mode with a key
         length of 128 bits; it can also be used for generating MAC";
      reference
        "RFC 4309:
           Using Advanced Encryption Standard (AES) CCM Mode with
           IPsec Encapsulating Security Payload (ESP)";
    }

Ø  The key step is that I would say that NETCONF should only standardizes the ones that we need now.

Ø    For the others, we could potentially create the YANG modules and either hand this off to the security groups, or work whether them to standardize these through the appropriate WGs.

I think it would be worthwhile to contact the Security AD’s and ask for time to present this somewhere, like the open SAAG meeting.
[RW]
I agree that seems like a good idea.  But I think that narrowing the scope to get these documents finished is the highest priority.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Sep 2019 14:23:48 +0000

Hi Rob (also Rich and Juergen)

> I agree with Juergen, in that I think that using OIDs as names for encryption protocols is probably a mistake and tying us into the past.

I was somewhat expecting that response ;)  

Fine, now we're aligned to the need to define something for the "algorithm" field.

> Ietf-crypto-sha-types.yang for the SHA hash identities (RFC 6234)
> Ietf-crypto-rsa-types for RSA asymmetric-key-algorithm (RC 8017)
> Ietf-crypto-elliptic-curve-types for the Elliptic Curve based algorithms (RFC 6090, 5480, 8422)
> Ietf-crypto-mac-types – I’m not really sure how to organize the MAC algorithm types, or even if they need to be defined now.
> Ietf-crypto-aes-types – AES encryption types (RFC 4309)
> Ietf-crypto-ssh-types – das-sha1, rsaasa-pkcs1-sha1 (RFC 4253)
> Ietf-crypto-tls-types – (RFC 8446)
> Ietf-cyprto-dhe-types – Diffier Hellman key exchange (RFC 7919).  Actually, the key-exchanges algorithm types might need to be split up a bit further.
>  

This is a good path forward: flip back to identities and only define the identities hierarchies needed now.  Having multiple modules make sense (they'd all still be defined in the crypto-types draft).  Only possible discussion point is if these should be "iana-" modules rather than "ietf-" modules?   [The hope being that, if maintained by IANA, it might be possible to get auto-updates].

> Yes, in essence I think that is what I’m suggesting.

Sounds good.

>  If this is really common, then an identity for “ASN.1 encoded” could also be defined and inherited by crypto type identities above.  I think that this depends on how useful it is to programmatical…

Just knowing that it is ASN.1 encoded isn't enough, unless we say all ASN.1 encoded keys must be a OneSymmetricKey or OneAsymmetricKey (i.e., option 'B2' from before).   Otherwise, the description statement needs to say something like "This identity indicates that the 'private-key' node is a DER-encoded RSAPrivateKey and 'public-key' is a DER-encoded RSAPublicKey."   Personally, I think this is okay.

An alternative to this may be to use a "choice" statement for "private-key" whereby one of the options is "asn1".

Kent // contributor

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 17 Sep 2019 15:36:55 +0000

Hi Kent,

Please see inline …

Sent: 17 September 2019 15:24

[RW]

[RW]
OK

[RW]

·        Ietf-crypto-sha-types.yang for the SHA hash identities (RFC 6234)

·        Ietf-crypto-rsa-types for RSA asymmetric-key-algorithm (RC 8017)

·        Ietf-crypto-elliptic-curve-types for the Elliptic Curve based algorithms (RFC 6090, 5480, 8422)

·        Ietf-crypto-mac-types – I’m not really sure how to organize the MAC algorithm types, or even if they need to be defined now.

·        Ietf-crypto-aes-types – AES encryption types (RFC 4309)

·        Ietf-crypto-ssh-types – das-sha1, rsaasa-pkcs1-sha1 (RFC 4253)

·        Ietf-crypto-tls-types – (RFC 8446)

·        Ietf-cyprto-dhe-types – Diffier Hellman key exchange (RFC 7919).  Actually, the key-exchanges algorithm types might need to be split up a bit further.

This is a good path forward: flip back to identities and only define the identities hierarchies needed now.  Having multiple modules make sense (they'd all still be defined in the crypto-types draft).  Only possible discussion point is if these should be "iana-" modules rather than "ietf-" modules?   [The hope being that, if maintained by IANA, it might be possible to get auto-updates].
[RW]
IANA might be OK, I’m not sure.

My original thought was that if a new security RFC is written then it could hopefully also define a YANG module that defines the new identities related to that security protocol.  But that may well depend on the scope of the RFC.

E.g. looking at say draft-ietf-curdle-ssh-ed25519-ed448-11.txt, that has just been approved by the IESG, it would seem that this could probably just update iana-crypto-ssh-types with some new identities.  But other documents might need to introduce new categories (i.e. new crypto types modules) altogether, which I think is OK.

Sounds good.

Just knowing that it is ASN.1 encoded isn't enough, unless we say all ASN.1 encoded keys must be a OneSymmetricKey or OneAsymmetricKey (i.e., option 'B2' from before).

  Otherwise, the description statement needs to say something like "This identity indicates that the 'private-key' node is a DER-encoded RSAPrivateKey and 'public-key' is a DER-encoded RSAPublicKey."   Personally, I think this is okay.
[RW]
OK, so this is where I am beyond the boundary of my knowledge, and don’t really know how keys are programmatically used, but my hunch is that "This identity indicates that the 'private-key' node is a DER-encoded RSAPrivateKey and 'public-key' is a DER-encoded RSAPublicKey” sounds like the right option.  I think that we want the keys to be in whatever form applications can most readily use them without having to perform an arbitrary conversion.

Thanks,
Rob

Kent // contributor

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Sep 2019 16:47:12 +0000

Thanks for the reply.

I think the most important thing is to get it *right* and in a way that the security folks (including those way much more knowledgeable than I) will accept it. We seem to agree that narrowing the scope is a good way to get there.

I also still think, more strongly now, that building definitions around the algorithms, rather than the type of key material, is wrong.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 17 Sep 2019 16:59:39 +0000

Hi Rich,

Sent: 17 September 2019 17:47

Thanks for the reply.

I also still think, more strongly now, that building definitions around the algorithms, rather than the type of key material, is wrong.
[RW]
Please may I ask you to clarify what you mean by this last comment.

Do you mean that you don’t like the base identities (e.g. hash-algorithm, asymmetric-key-algorithm, mac-algorithm, encryption-algorithm, encryption-and-mac-algorithm, signature-algorithm, key-exchange-algorithm), which really just define how the identities can be used.

Or is your objection to my suggestion of putting the identity definitions into different YANG modules (e.g.

), e.g. which is really just an organization structure for the identities?

Thanks,
Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Sep 2019 17:07:04 +0000

I do not think using algorithms as the base classes is a good idea.  I think it is much better to have the type of key material as the base class:
                asymmetric-key (RSA, ECC, etc)
                symmetric-key (AES 3DES etc)
                byte string (maybe…)
nonce (non-reused stream of bits used in AES-GCM, EdDSA signature, EDDSA signatures, etc)
                tag (used in KDF functions, almost always a text string)

The *use* of the identities should be implied by the operation.

I like the idea of partitioning by “here is what you need to configure a typical HTTPS server” in one document and “here is what you need to configure a typical SSH server”

Does that answer your question?

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 18 Sep 2019 09:36:03 +0000

Hi Rich,

Sent: 17 September 2019 18:07

The *use* of the identities should be implied by the operation.
[RW]
OK.  So, in YANG I think the definition of a base identity is effectively defined by how it is intended to be used.  I.e. somewhere in the model there is an identity reference that indicates that it can take any identity value that is derived from that base identity.

So, from the keystore model I can see:

“keystore/asymmetric-keys/asymmetric-key/algorithm” uses any identity derived from “asymmetric-key-algorithm”
“keystore/symmetric-keys/symmetric-key/algorithm” uses any identity derived from “encryption-algorithm”

I assume that the other base identities are used in the other drafts.

I also think that the identities are identifying encryption-key-algorithms, not the keys themselves, so having algorithm in the name doesn’t seem particularly strange.

I like the idea of partitioning by “here is what you need to configure a typical HTTPS server” in one document and “here is what you need to configure a typical SSH server”
[RW]
We still need to have care here.  Presumably there will be cases where the same key algorithm is used in multiple places.  I was partly trying to tie the partitioning into modules about where the algorithms are being defined (i.e. which RFCs) rather then where they are necessarily used.

Yes, thank you.

Thanks,
Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Sep 2019 12:41:24 +0000

*   OK.  So, in YANG I think the definition of a base identity is effectively defined by how it is intended to be used.  I.e. somewhere in the model there is an identity reference that indicates that it can take any identity value that is derived from that base identity.

I will have to go learn a heck of a lot more about YANG before the next IETF.

  *   We still need to have care here.  Presumably there will be cases where the same key algorithm is used in multiple places.  I was partly trying to tie the partitioning into modules about where the algorithms are being defined (i.e. which RFCs) rather then where they are necessarily used.

Luckily TLS and SSH are defined in separate RFC’s. :)

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 18 Sep 2019 12:45:19 +0000

Sent: 18 September 2019 13:41

Ø  OK.  So, in YANG I think the definition of a base identity is effectively defined by how it is intended to be used.  I.e. somewhere in the model there is an identity reference that indicates that it can take any identity value that is derived from that base identity.

I will have to go learn a heck of a lot more about YANG before the next IETF.
[RW]
Probably sections 7.18 Identities and 9.10 Identity-ref of RFC 7950 are probably the key ones for this discussion.

Ø  We still need to have care here.  Presumably there will be cases where the same key algorithm is used in multiple places.  I was partly trying to tie the partitioning into modules about where the algorithms are being defined (i.e. which RFCs) rather then where they are necessarily used.

[RW]
Yes, 😉

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Sep 2019 14:19:01 +0000

The authors are looking for clear direction for the next update to the draft(s).

From the gist of the discussion, the punch list appears to be:

- revert back to using identities, as they were in the -08 revision.
- only define base identities for what's needed immediately for TLS and SSH and keystore key-encryption.
- define these base identities in distinct YANG modules
- have each identity's description statement indicate what the binary key data is encoded.

A bit separate from the above, but still in mind:

  - specify that all TLS public-keys are a DER-encoded SubjectPublicKeyInfo structure
  - specify that all SSH public-keys are a "ssh-public-key-type" type (see below)
  - specify that all encrypted symmetric keys are a DER-encoded OneSymmetricKey structure
  - specify that all encrypted asymmetric keys are a DER-encoded OneAsymmetricKey structure

The "ssh-public-key" type would be defined as:

     typedef ssh-public-key-type {
         type binary;
         mandatory true;
         description
           "The binary public key data for this 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";
          }

Any concerns?

Kent // author

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Sep 2019 14:42:36 +0000

Moving Russ and Sean to BCC; they can subscribe to the list if they want :)

>  - specify that all TLS public-keys are a DER-encoded SubjectPublicKeyInfo structure

No, they should be an X509 certificate object.

Private keys and symmetric keys can be encrypted; is that a separate keytype derived from their base key types?

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 18 Sep 2019 15:37:14 +0000

Hi Kent,

From: Kent Watsen <[email-masked]>
Sent: 18 September 2019 15:19
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Salz, Rich <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]; Sean Turner <[email-masked]>; Rifaat Shekh-Yusef <[email-masked]>
Subject: Re: [netconf] crypto-types fallback strategy

I think that this matches my view, except for "define these base identities in distinct YANG modules".  I don't feel particularly strongly about this, but I was thinking that the base identities would still be defined in crypto-types.yang, which might help keep the import references simple.

Any concerns?
[RW]
I think that this sounds OK.

Minor: Does the "string" in the description above mean "ASCII string" or "binary string", RFC 4251 seemingly uses both definitions?

Is putting the encrypted keys into DER-encoded OneSymmetricKey obviously the right thing to do?  Are there other choices?

Thanks,
Rob

Kent // author

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 18 Sep 2019 16:36:59 +0000

> I think that this matches my view, except for "define these base identities in distinct YANG modules".  I don't feel particularly strongly about this, but I was thinking that the base identities wo…

I tend to agree that sometimes less modules is more. For me, the
problem is likely more that I am not entirely sure what the proper
base types would be, which may depend on what exactly they are used
for. I guess I wait until I see the description text...
 
>   - specify that all encrypted asymmetric keys are a DER-encoded OneAsymmetricKey structure

I would check what is commonly used in existing configuration
interfaces. We are not inventing the wheel here. And whatever we
define better is usable with existing implementations and tools.

>            "RFC 4253: The Secure Shell (SSH) Transport

The SSH implementations that I use have the binary key data rendered
in ASCII. In fact, the whole key record is rendered in ASCII. I
strongly suggest to use formats that are well established.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Sep 2019 16:46:20 +0000

> Moving Russ and Sean to BCC; they can subscribe to the list if they want :)

Okay but, be aware that this thread is the culmination of me interacting with Sean and Russ for a couple weeks...

> No, they should be an X509 certificate object.

There is a separate field for certificates, which is an X.509 certificate.

The desire to use SubjectPublicKeyInfo is per tests (2) and (4) described here: https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE <https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE>.

> Private keys and symmetric keys can be encrypted; is that a separate keytype derived from their base key types?

I don't understand the question.  I think your tip-toeing on a concern that a key should only be encrypted with a certain other key, if only the ensure that the strength of the encrypting key is not less than the key being encrypted.  Is this what you mean?

draft-ietf-netconf-keystore currently uses a YANG "leafref" for the model to point to the other key in the keystore used to do the encryption.  The leafref has not constraints on its at the moment.

Kent // contributor

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Sep 2019 16:58:25 +0000

*   The desire to use SubjectPublicKeyInfo is per tests (2) and (4) described here: https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_netconf_ysukDdbCA0a70heF1a-5FldZNr4yE&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=2WjGA7HZCdgO3PuNIGcShf2is7JW06LCQdbjHnYFNs8&s=2a467Qepi3ZnOMc6bomXjp3ysTseF0EUXytuahNHZNw&e=>.

Those experiments do not matter.  TLS sends X509 certificates.  I am not aware of any protocol (and I don’t know all of them, of course) that sends raw public keys.  What protocols are you thinking of?

If you want to configure an HTTPS server using netconf/yang, you will need to give that server X509 certificates.

> don't understand the question.  I think your tip-toeing on a concern that a key should only be encrypted with a certain other key, if only the ensure that the strength of the encrypting key is not less than the key being encrypted.  Is this what you mean?

No, I was asking if “encrypted private key” is a separate thing from “plaintext private key.”

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Sep 2019 17:03:09 +0000

[moving Russ and Sean to BCC, per Rich's action]

> Minor: Does the “string” in the description above mean “ASCII string” or “binary string”, RFC 4251 seemingly uses both definitions?

I don't know, but this is the language found for the "key-data" leaf in RFC 7317 (i.e., we've been living with this definition for awhile)

> Is putting the encrypted keys into DER-encoded OneSymmetricKey obviously the right thing to do?  Are there other choices?

Yes, if there was one thing that came out of my discussion with Russ and Sean is that OneSymmetricKey and OneAsymmetricKey SHOULD be used for encrypting key data.   Anything else would be a BIG effort.   

The real question is if we should also use the One*Key structures for unencrypted keys, which could help some ways, but I think that it's better to use the values provided by OpenSSL command line.  This approach pushes the complexity of using the One*Key structures to just the "advanced" case of when encryption is needed and, besides, it would primarily be for the NC/RC server to generate/parse; clients would rarely encrypt a key themselves, the only case I can think of when they might would be for the RMA workflow we discussed a few weeks back.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Sep 2019 17:12:25 +0000

> for. I guess I wait until I see the description text...

Okay, we'll keep just the one YANG module.

> define better is usable with existing implementations and tools.

These are the native types used by OpenSSL and OpenSSH, what more verification do we need?   

Possibly we could discuss supporting PEM, in addition to DER, but I'd image that, if PEM is supported at all, the presentation layer (Web UI, CLI) would convert it to/from PEM as needed (i.e., the underlying model only needs to support DER).

> strongly suggest to use formats that are well established.

This is the "key-data" leaf from RFC 7317.  Are you saying that it should've been different?

Regardless, should this be a presentation layer issue?

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Sep 2019 17:16:36 +0000

> The desire to use SubjectPublicKeyInfo is per tests (2) and (4) described here: https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_netconf_ysukDdbCA0a70heF1a-5FldZNr4yE&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=2WjGA7HZCdgO3PuNIGcShf2is7JW06LCQdbjHnYFNs8&s=2a467Qepi3ZnOMc6bomXjp3ysTseF0EUXytuahNHZNw&e=>.
>  

The previous line in my response read: "There is a separate field for certificates, which is an X.509 certificate."

So, that need/desire is covered.  Having the "public-key" field is not needed for TLS.

>  No, I was asking if “encrypted private key” is a separate thing from “plaintext private key.”

From a Keystore perspective, there are keys, and each key may either be encrypted or not, but not both at the same time.

Kent // contributor

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 18 Sep 2019 17:41:08 +0000

> Possibly we could discuss supporting PEM, in addition to DER, but I'd image that, if PEM is supported at all, the presentation layer (Web UI, CLI) would convert it to/from PEM as needed (i.e., the…

On my Linux system, certs tend to be stoed in pem format, so I am
biased. It seems some other applications like web browsers and server
also tend to use pem format. But I am happy to be corrected since my
experience with cert usage is limited.

Yes, the application or presentation could convert between formats and
solve all problems. One of the failures of SNMP was that SNMP required
an application or presentation layer to be usable while CLIs did not
require other tools. The idea that there is always software between
the NC/RC server and whoever has to solve an automation problem has
somehow failed in the past. I believe data models should be written to
enable automation without requiring lots of additional tooling. And
yes, there is a need to find a balance.
 
> Regardless, should this be a presentation layer issue?

See above, if we start to require a presentation layer, we may repeat
a failure. It might be useful to check who has implemented that part
of RFC 7317 and how happy operators were with the format. I personally
would not immediately know how to convert my openssh key in a binary
format such that that I can use the YANG model. We should try to
maximize usability and stay away from the idea that a presentation
layer will be available to make things usable for people that have to
script customized automation solutions.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Sep 2019 19:02:53 +0000

> yes, there is a need to find a balance.

Use a union statement?  The 'string' type  for PEM and 'binary' for DER?

> script customized automation solutions.

Use a union for this too?  string vs binary?

One issue is that your file-format is most likely an OpenSSH-specific format, which is likely duplicated by other SSH implementations.   Is it too much of an assumption to use that format as the defacto 'string' format?  Perhaps we should define a custom type (e.g., openssh-string) to use instead of "string"?

Kent // contributor

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 18 Sep 2019 19:22:23 +0000

> One issue is that your file-format is most likely an OpenSSH-specific format, which is likely duplicated by other SSH implementations.   Is it too much of an assumption to use that format as the de…

What are the SSH implementations that do not understand that format?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Sep 2019 22:06:38 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> > Minor: Does the “string” in the description above mean “ASCII string”
> > or “binary string”, RFC 4251 seemingly uses both definitions?
> 
> I don't know, but this is the language found for the "key-data" leaf
> in RFC 7317 (i.e., we've been living with this definition for awhile)

So the definition is:

             leaf key-data {
               type binary;
               mandatory true;
               description

The textual representation of a binary in YANG is base64 encoded.  As
it happens, this is exactly the same as OpenSSH uses for its keys.  So
the open ssh key can be copy/pasted into the NC/RC XML/JSON.

/martin

> 
> 
> > Is putting the encrypted keys into DER-encoded OneSymmetricKey
> > obviously the right thing to do?  Are there other choices?
> 
> 
> Yes, if there was one thing that came out of my discussion with Russ
> and Sean is that OneSymmetricKey and OneAsymmetricKey SHOULD be used
> for encrypting key data.  Anything else would be a BIG effort.
> 
> The real question is if we should also use the One*Key structures for
> unencrypted keys, which could help some ways, but I think that it's
> better to use the values provided by OpenSSL command line.  This
> approach pushes the complexity of using the One*Key structures to just
> the "advanced" case of when encryption is needed and, besides, it
> would primarily be for the NC/RC server to generate/parse; clients
> would rarely encrypt a key themselves, the only case I can think of
> when they might would be for the RMA workflow we discussed a few weeks
> back.
> 
> 
> Kent
> 
>

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 18 Sep 2019 20:29:30 +0000

> the open ssh key can be copy/pasted into the NC/RC XML/JSON.

My public ssh keys usually start like this:

  ssh-rsa AAAA...

Looking at RFC 4251, it seems to me that 'string' is encoded with a
length prefix, followed by n bytes of key data. This means the start
in hex would be something like this:

  00 00 00 07 73 73 68 2d 72 73 61

If I base64 encode this, I won't get what I quoted above.

/js

---

From: Per Hedeland <[email-masked]>
Date: Wed, 18 Sep 2019 22:53:09 +0200

On 2019-09-18 22:29, Schönwälder, Jürgen wrote:
>>>> Minor: Does the string in the description above mean ASCII string
>>>> or binary string, RFC 4251 seemingly uses both definitions?
>>>

Are you sure? I don't have a handy base64 encoder for "space-separated
octets represented as hex numbers", but going in the other direction
with the initial part of my public ssh key (ssh-rsa), using the Linux
'base64' command and converting the result to "space-separated octets
represented as hex numbers" gives:

$ echo AAAAB3NzaC1yc2EA | base64 -d | od -t x1
0000000 00 00 00 07 73 73 68 2d 72 73 61 00

Seems to agree with what you have.

--Per

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 18 Sep 2019 21:19:52 +0000

> Seems to agree with what you have.

Aha. So the 'ssh-rsa ' part in my key file needs to be stripped as it
is actually redundant (but still its there in my file). In the RFC
7317 YANG model, this string seems to go into the 'algorithm'
leaf. All good and usable.

(I wonder what happens if the two algorithm names do not match, time
 to run some experiments on my ssh implementation...)

/js

---

From: Per Hedeland <[email-masked]>
Date: Wed, 18 Sep 2019 23:54:41 +0200

On 2019-09-18 23:19, Schönwälder, Jürgen wrote:
> is actually redundant (but still its there in my file).

Right, it's in mine too of course - I stripped it without thinking,
but realized after posting that this might be the reason that your
encoding didn't match. (There is also normally a trailing
<user>@<host> after the actual key.)

> In the RFC

Yes - and hopefully a server implementing it will reject 'key-data'
input with the leading 'ssh-rsa ' (or any other "key type", which all
seem to include one or more '-') - the '-' is not a valid base64
character (nor is space, but base64 decoders are often "liberal" with
whitespace).

>   to run some experiments on my ssh implementation...)

Ditto for a server implementing RFC 7317...

--Per

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 19 Sep 2019 10:44:06 +0000

From: Kent Watsen <[email-masked]>
Sent: 18 September 2019 18:12
To: Juergen Schoenwaelder <[email-masked]>
Cc: Rob Wilton (rwilton) <[email-masked]>; [email-masked]; Rifaat Shekh-Yusef <[email-masked]>
Subject: Re: [netconf] crypto-types fallback strategy

Okay, we'll keep just the one YANG module.
[RW]
Do you mean one module for all the identities of just the base identities?

Thanks,
Rob

Kent // contributor

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 19 Sep 2019 10:45:46 +0000

From: Kent Watsen <[email-masked]>
Sent: 18 September 2019 18:03
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Salz, Rich <[email-masked]>; [email-masked]; Rifaat Shekh-Yusef <[email-masked]>
Subject: Re: [netconf] crypto-types fallback strategy

OK.

[RW]
I would suggest only using the One*Key structures for the encrypted key data.

Thanks,
Rob

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Sep 2019 12:53:58 +0200 (CEST)

> leaf. All good and usable.

Here's a link to the discussion we had some five years ago:

https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCPs

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Sep 2019 13:35:24 +0000

> Do you mean one module for all the identities of just the base identities?

Do you have a preference?   Recent comments suggest that less is more.   If there were one module, we could limit it to just the identity hierarchies needed for our immediate needs, leaving it as a future effort to add (and deprecate/remove) identities at any point in the hierarchy.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Sep 2019 13:36:27 +0000

> I would suggest only using the One*Key structures for the encrypted key data.

Agreed.  Okay.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Sep 2019 14:04:05 +0000

> On Sep 19, 2019, at 6:53 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCPs <https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCPs>

So apropos.    Yeah for email archives!

I noticed a discrepancy between the file format described in RFC 4716 and the one `ssh-keygen` produces by default.  In order to get the standard public key file format, I had to use the command `ssh-keygen -e -m RFC4716 -f <public-or-private-key-file>`.

We can define a type for this:

	typedef rfc4716-string {
	    type string;
	    description
	      "A string containing the contents of the file described by RFC 4716";
	    reference
	      "RFC 4716: The Secure Shell (SSH) Public Key File Format";
	}

And perhaps another for PEMs:

	typedef pem-string {
	    type string;
	    description
	      "A string containing the PEM encoding of an ASN.1 structure.";
	    reference
	      "TBD";
	}

And then put a union into the "public-key" leaf:

    leaf public-key {
      nacm:default-deny-write;
      type union {
          type rfc4716-string;
          type pem-string;
          type binary;
      }
      mandatory true;
      description
        "The value of the public key.  The interpretation of this value is
         defined by 'algorithm'.  For example, algorithms using SSH
         specific identities always use 'rfc4716-string', where algorithms
         using X.509 specific identities encode a SubjectPublicKeyInfo
         (RFC 5280) that may be a 'binary' (for DER encodings) or 
         'pem-string' (for PEM encodings).";
      reference
        "RFC 5280: Internet X.509 Public Key Infrastructure Certificate
                            and Certificate Revocation List (CRL) Profile";
    }

And similar for the private key?

AFAICT, that all are effectively strings doesn't matter.  Implementations can try to parse the options until something works.

Thoughts?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Sep 2019 09:52:58 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> > <https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCPs>
> 
> 
> I noticed a discrepancy between the file format described in RFC 4716
> and the one `ssh-keygen` produces by default.  In order to get the
> standard public key file format, I had to use the command `ssh-keygen
> -e -m RFC4716 -f <public-or-private-key-file>`.
> 
> AFAICT, that all are effectively strings doesn't matter.
> Implementations can try to parse the options until something works.
> 
> 
> Thoughts?

What's wrong with the definition we use in RFC 7317?

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 23 Sep 2019 13:21:55 +0000

> What's wrong with the definition we use in RFC 7317?

Because Juergen said he wanted to copy/patse the file contents?

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Sep 2019 15:34:53 +0200 (CEST)

> Because Juergen said he wanted to copy/patse the file contents?

He can; by copying the key-part (b64 encoded).

/martin

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Mon, 23 Sep 2019 13:50:32 +0000

> He can; by copying the key-part (b64 encoded).

Yes. It took me a bit of time to figure this out from the description
statement. An explanation of example might have helped me...

/js

---

From: tom petch <[email-masked]>
Date: Tue, 24 Sep 2019 08:50:06 +0000

Going back a bit, since this is a more generic comment, I get a
different, simpler perspective in
draft-jholland-taps-api-yang
which has me wondering just how complicated this needs to be for it to
be useful in other WGs.

The I-D defines
  identity security-algorithm {description "Base identity for security
algorithms."
  identity cipher-suite { base security-algorithm;description "Base
identity for security cipher suites.";
  identity signature-algorithm {base security-algorithm;
description "Base identity for security signature algorithms.";
  identity ed25519 {base signature-algorithm;
  identity TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 {
    base cipher-suite;

and

  grouping security-credentials {
    leaf identity { type string;
    leaf trust-ca { type string;
    leaf algorithm { type identityref {base security-algorithm;
    leaf pre-shared-key { type string;
    leaf private-key { type string;
    leaf private-key-callback-handle {type string;
    leaf public-key {type string;

(No SSH but that does not surprise me:-)

Again a more general comment, the IETF often starts simple and adds lots
later, which sometimes goes wrong because no allowance was made for
slotting in extras, but an approach which, I think, more often leads to
successful adoption.

Thus will TAPS consider using
draft-ietf-netconf-crypto-types
or will they RYO?

Tom Petch

----- Original Message -----
From: <Schönwälder>; "Jürgen" <[email-masked]>
To: "Rob Wilton (rwilton)" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>; <[email-masked]>; "Sean
Turner" <[email-masked]>; "Rifaat Shekh-Yusef" <[email-masked]>
Sent: Wednesday, September 18, 2019 5:36 PM

> > I think that this matches my view, except for "define these base
identities in distinct YANG modules".  I don't feel particularly
strongly about this, but I was thinking that the base identities would
still be defined in crypto-types.yang, which might help keep the import
references simple.
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Sep 2019 12:15:34 +0000

> Going back a bit, since this is a more generic comment, I get a different, simpler perspective in
draft-jholland-taps-api-yang which has me wondering just how complicated this needs to be for it to be useful in other WGs.

I like Jake's approach.  But I don't know what your "this" refers to -- the crypto-types or the TAPS draft?

>    Thus will TAPS consider using draft-ietf-netconf-crypto-types or will they RYO?
  
Perhaps the TAPS WG should be asked :)  Jake's a colleague, I've pinged him.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 24 Sep 2019 20:02:01 +0000

Jake,

As the author of the draft referenced below, do you care to comment?

The crypto-types document in the netconf WG is undergoing some pretty drastic surgery.

On 9/24/19, 4:50 AM, "tom petch" <[email-masked]> wrote:

    The I-D defines
    
    and

    

    Tom Petch

---

From: "Holland, Jake" <[email-masked]>
Date: Tue, 24 Sep 2019 20:38:31 +0000

(+taps)
Hi,

Thanks for taking a look at that model, Tom.  I'll give just a
little background:

The current taps-api structure was driven basically by an attempt to
support the examples given in the taps-interface draft, for instance
in section 5.3.1:
https://tools.ietf.org/html/draft-ietf-taps-interface-04#section-5.3.1

I didn't do much (or any? don't recall...) of a search for crypto
models before throwing together the early ietf-taps-api.yang drafts,
including the security config stuff.  I mostly worked off the API
examples, with intent to look for a more serious answer later as
we try to integrate the secure connection support into a reference
implementation or 2.

What's there now hasn't been through any kind of security review, and
I'd characterize it as a placeholder, at the moment.  (The taps use of
yang is still relatively immature.)

I'd be very grateful for a grouping or object of some kind that I
could pull in by import from another module, and would support
using it in taps-api-yang if we can use it to do what we need (which
is to configure connection endpoints to allow secured connections,
for either client or server endpoints).  I think that would make for
a very helpful improvement.

Part of the point of using yang in taps was to be able to better exploit
yang work from other wgs, and this would be an excellent opportunity to
put that into practice, I think.  So I would be very delighted to import
a model that does this right.

Best,
Jake

On 2019-09-24, 13:02, "Salz, Rich" <[email-masked]> wrote:

Jake,

    
    The I-D defines
    
    and

    

    Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Sep 2019 08:36:20 +0200 (CEST)

Hi,

Just a quick comment on the usage of YANG in this document.  Since it
doesn't define configuration data to be used over a management
protocol like NETCONF or RESTCONF, you may want to have a look at
https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext, which
introduces a YANG extenstion statement to define "structures" (with no
predefined semantics), and replace your:

  container preconnection { ... }

with:

  sx:structure preconnection { ... }

/martin

---

From: tom petch <[email-masked]>
Date: Fri, 27 Sep 2019 11:00:32 +0000

----- Original Message -----
From: "Holland, Jake" <[email-masked]>
To: "Salz, Rich" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 24, 2019 9:38 PM

Jake,

Yes!  Part of the remit of the NETCONF and NETMOD WG  is to produce YANG
modules for general use by other WG and
draft-ietf-netconf-crypto-types
is part of that.  The NETCONF *client-server* modules would be another
example

Crypto has different object classes - hash, MAC, KEX, encrypt,
signature - with plenty of options for most of these.  YANG lacks a
subset feature for saying this is the MTI subset and here are others for
you to consider; unless you divide the space up with base YANG modules
and augmentations thereto, an option which has been discussed on the
NETCONF list and not found favour.

And then you have SSH and TLS which take radically different approaches,
with TLS having ciphersuites and TLS itself changing what it uses with a
change of version.

So is a list of everything possible, in a tree or mesh structure of YANG
identity going to be useful to other WG?

Your I-D caught my eye and seemed to be a different approach based on
this is what most implementations of TLS 1.2 will need, and limiting it
to that; a different approach to
draft-ietf-netconf-crypto-types
which made me wonder if the latter would be of any use to you; and if
not, if anything would.

Tom Petch

>     > > - only define base identities for what's needed immediately
for TLS
>     and SSH and keystore key-encryption.
>     > >   - specify that all SSH public-keys are a
"ssh-public-key-type"
>     type (see below)
>     > >   - specify that all encrypted symmetric keys are a
DER-encoded
>     OneSymmetricKey structure
>     > >   - specify that all encrypted asymmetric keys are a
DER-encoded
>     OneAsymmetricKey structure
>     >
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 Sep 2019 14:35:29 +0000

[cc-ing my co-authors, as they're beginning to convert crypto-types back to identities again]

Rob et. al.,

> Do you mean one module for all the identities of just the base identities?

Dunno.   

Identities provide the desirable benefit of hierarchy and extensibility, but they come with the weight of the module needing to be implemented (not just imported) in order for the identity to be defined.  This is how YANG works; it would've been better if, e.g., identities could be defined by "implemented" via YANG-library...

The thing with crypto algorithms, the algorithms a server supports is a matter of importance, e.g., because the algorithm isn't approved for use on the network.  The ability to configure algorithms supported is not currently present in the ssh-client-server and tls-client-server drafts, as I was hoping it could be added later as a -bis extension or an update, but perhaps it should be, in order to drive this problem, to ensure a proper crypto-types solution.

Working within the current YANG construct, one possible solution would be to define every algorithm identity in its own module, thus enabling servers maximum flexibility to describe which are supported.  The ostensible negative is that doing so would produce many modules.  While not a computer problem, it could become onerous.

Another idea is to not use identities either (in addition to enumerations), but instead define a data model that preserves the extensibility of identities without needing to implement modules.  For instance, instead of assuming the "algorithm" field is an 'identityref', perhaps a "leafref" is used.

ietf-crypto-types.yang snippet:

	// protocol accesible nodes  (note: config false)
	list algorithms {
	  config false;
	  key name;
	  leaf name {
	    type string;
	    description "The name of a collection of algorithms.  Suitable values are defined in the TBD IANA registry...";
	  }
	  list algorithm {
	    key name;
	    leaf name {
	      type string;
	      description "The name of an algorithm.   Suitable values are defined in the TBD IANA registry...";
	    }
	  }
	}    

	grouping public-key {
          leaf algorithm-type {
	    type leafref {
	      path "/ct:algorithms/ct:name";
	      require-instance false;
	    }
	    must '../algorithm';
          }
	  leaf algorithm {
	      type leafref {
	        path "/ct:algorithms[ct:name = current()/../algorithm-type]/ct:algorithm/ct:name";
	        require-instance false;
	      }
	    must '../algorithm-type';
	  }
	}

PROs:
  - allows a server to advertise (in <operational>) which algorithms it supports without any need to implement a module, other than crypto-types.
  - supports extensibility via IANA registries.  Sequence:  RFC updates registry --> server supports --> client configures to use.
  - "require-instance false" enables YANG-based config validations to succeed w/o presence config false data.

CONs:
  - only one level of hierarchy (would more every be needed?)
  - "require-instance false" enables YANG-based config validations to succeed even when misconfigured (though commit should fail).

Thoughts?

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 Sep 2019 14:44:58 +0000

Here is the COSE registry that Henk suggested us looking at in Montreal:

	https://www.iana.org/assignments/cose/cose.xhtml <https://www.iana.org/assignments/cose/cose.xhtml>

It seems more a reference to how the issue has been approached before, then something that crypto-types would consume normatively, but perhaps others feel differently?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 27 Sep 2019 17:09:02 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> Identities provide the desirable benefit of hierarchy and
> extensibility, but they come with the weight of the module needing to
> be implemented (not just imported) in order for the identity to be
> defined.  This is how YANG works; it would've been better if, e.g.,
> identities could be defined by "implemented" via YANG-library...

Yes, but it only matters if the server implements some data node of
type identityref with the base that these identities are derived from.

While I agree that it would be good to find a solution to the
"advertise identities supported"-problem, I don't think it is
importang enough for us to find some clever little workaround...

So I think a single module wih the identities will work.  Or perhaps
one for tls and one for ssh.

> The thing with crypto algorithms, the algorithms a server supports is
> a matter of importance, e.g., because the algorithm isn't approved for
> use on the network.  The ability to configure algorithms supported is
> not currently present in the ssh-client-server and tls-client-server
> drafts, as I was hoping it could be added later as a -bis extension or
> an update, but perhaps it should be, in order to drive this problem,
> to ensure a proper crypto-types solution.
> 
> Working within the current YANG construct, one possible solution would
> be to define every algorithm identity in its own module, thus enabling
> servers maximum flexibility to describe which are supported.  The
> ostensible negative is that doing so would produce many modules.
> While not a computer problem, it could become onerous.
> 
> Another idea is to not use identities either (in addition to
> enumerations), but instead define a data model that preserves the
> extensibility of identities without needing to implement modules.  For
> instance, instead of assuming the "algorithm" field is an
> 'identityref', perhaps a "leafref" is used.
> 
> 
> 	    description "The name of a collection of algorithms.  Suitable
> 	    values are defined in the TBD IANA registry...";
> 	  }
> 	  list algorithm {
> 	    key name;
> 	    leaf name {
> 	      type string;
> 	        path "/ct:algorithms[ct:name =
> 	        current()/../algorithm-type]/ct:algorithm/ct:name";
> 	        require-instance false;
> 	      }
>   - allows a server to advertise (in <operational>) which algorithms it
>     supports without any need to implement a module, other than
>     crypto-types.
>   - supports extensibility via IANA registries.  Sequence: RFC updates
>     registry --> server supports --> client configures to use.
>   - "require-instance false" enables YANG-based config validations to
>     succeed even when misconfigured (though commit should fail).

The last CON here is essentially the same as you get with identities.
I think we should stick to identities, and describe that it is ok for
a server to reject config for an identity representing an algorithm
that the server doesn't implement (even though it "supports"
(understands) the identity itself).

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 27 Sep 2019 15:53:51 +0000

I basically agree with what Martin is saying.

Either one YANG module containing all of the crypto identities, or a few YANG modules as previously suggested.

If advertising the specific identities is important, then a per identity if-feature could be used, although I'm not entirely sure that one feature per identity is really a great option either, but I think that this would be better than one per module.

Or, we could do an augmentation to YANG library with a leaf-list of the crypto identities that are supported by the server.  This is sort of equivalent to a feature per identity solution without polluting the feature list with lots of features.  Something along these lines could even be extended if it is likely that a given identity might only be supported by some of the protocols.  E.g. a separate list for NETCONF supported crypto identities vs RESTCONF supported crypto identities, etc.

But I also think that this is just another instance of the generic capabilities issue, and really it would be good to a have a solution where the capabilities are available offline as well as from the device.

Thanks,
Rob

> -----Original Message-----
> From: Martin Bjorklund <[email-masked]>
> Sent: 27 September 2019 16:09
> To: [email-masked]
> Cc: Rob Wilton (rwilton) <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]
> Yes, but it only matters if the server implements some data node of type
> identityref with the base that these identities are derived from.
> 
> While I agree that it would be good to find a solution to the "advertise
> identities supported"-problem, I don't think it is importang enough for us
> to find some clever little workaround...
> 
> So I think a single module wih the identities will work.  Or perhaps one
> for tls and one for ssh.
> 
> >     succeed w/o presence config false data.
> >
> > CONs:
> I think we should stick to identities, and describe that it is ok for a
> server to reject config for an identity representing an algorithm that the
> server doesn't implement (even though it "supports"

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 27 Sep 2019 16:35:24 +0000

>    Either one YANG module containing all of the crypto identities

I dislike this approach for a couple of reasons:
	- It might be hard to  get good security reviews of an omnibus document as opposed to short docs that need different audiences
	- Not all crypto objects will advance, or be attacked, in lockstep; being able to revise the one short YANG document will make updates easier.

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 27 Sep 2019 17:46:24 +0000

> I basically agree with what Martin is saying.

So do I.

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

> If advertising the specific identities is important, then a per identity if-feature could be used, although I'm not entirely sure that one feature per identity is really a great option either, but…

Why not instead have a config false list of algorithms supported? Once
we have solved this problem generically, this list may get deprecated.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 1 Oct 2019 00:38:08 +0000

> On Sep 27, 2019, at 1:46 PM, Schönwälder, Jürgen <[email-masked]> wrote:
> 

Hmmm...

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

Updates only to the specific module would be needed.   The updates would only need to support new algorithms (not to remove support for legacy algorithms), as a different mechanism can be used for a server to advertise which algorithms it actually supports (on a more granular level).

One issue not addressed is defining the identities for the algorithms used to encrypt other keys in the keystore.   At least, neither SSH or TLS are involved.  However, both the keystore and TLS use "ASN.1" and so, somehow, the keystore may be encrypting with "TLS" (really ASN.1) keys already... (requires more analysis)

> we have solved this problem generically, this list may get deprecated.

I like this idea, but it means that ietf-crypto-types, where this config false list would be defined, presumably, would then have protocol accessible nodes and, to the point, may be odd for a "types" module to define.   Thoughts?  - a "config false" list okay?

Rich, does any of this line of thinking address your concern?  - or maybe you liked more my previous idea of using IANA registries?

Kent // contributor

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 1 Oct 2019 06:40:55 +0000

> Updates only to the specific module would be needed.   The updates would only need to support new algorithms (not to remove support for legacy algorithms), as a different mechanism can be used for…

I do not know whether this helps solving a problem or creates other
problems as side effects. I think we have

a) a set of named algorithms that is changing over time
b) a set of algorithms that are "blessed" for use a certain protocol
   version (and the set may change over time)
c) a set of algorithms supported by a protocol implementation (may change
   with over time as well, i.e., with firmware updates)
d) a set of algorithms configured to be used by a protocol implementation
   (this is really what we want to get at)

Perhaps it is best to use identities for a) and to expose the other
sets via data leafs. I am not even sure exposing b) is required since
b) is input to the protocol implementer and a client can (only)
configure what is implemented anyway. I think c) could be exposed as
config false data and d) is then config true data.

> I like this idea, but it means that ietf-crypto-types, where this config false list would be defined, presumably, would then have protocol accessible nodes and, to the point, may be odd for a "type…

Such a config false list should go where the protocol specifics are
defined. And it likely has to be protocol version specific for
implementations that do support multiple versions of a security
protocol.

I am generally not a fan of overloading names (or concepts in
general). A YANG identity simply gives a name to something and a
module simply puts a collection of named definitions into a common
namespace. We should stay away from associating additional semantics
with how an identity is named or how a module is named. If additional
information is needed, model that additional information as data.
 
/js