Re: [netconf] crypto-types fallback strategy

[Martin Bjorklund <[e-mail]>]

Hi,


Kent Watsen <[e-mail]> wrote:
> [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.

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?

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

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


/martin




> 
> 
> Thoughts?
> 
> Kent // co-author
> 
> 
> 
>