Re: [netconf] crypto-types fallback strategy

["Rob Wilton (rwilton)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Kent Watsen
Sent: 11 September 2019 21:05
To: [e-mail]
Cc: Russ Housley <[e-mail]>; Rifaat Shekh-Yusef <[e-mail]>; Sean Turner <[e-mail]>
Subject: [netconf] crypto-types fallback strategy

[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) 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