[netconf] crypto-types fallback strategy

Kent Watsen <kent+ietf@watsen.net> Wed, 11 September 2019 20:05 UTC

Return-Path: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5312021D for <netconf@ietfa.amsl.com>; Wed, 11 Sep 2019 13:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XonuM0Rpp2X for <netconf@ietfa.amsl.com>; Wed, 11 Sep 2019 13:05:19 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10941201CE for <netconf@ietf.org>; Wed, 11 Sep 2019 13:05:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568232317; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=1MhFn3hJ0/bvIrsaE7f9e+aSSR6mTCIzpCNyXBhICDI=; b=g0fn30WSrD3AJb+8tMAbW6yWV/BQ8XPc16G/DzaA0/UqKBIZtxKScU+H/Lwc3JpK oUhNQNSGBhJMhpJAxUspgT3svCo9HVtEH22vGVwS6F/IwCeQnMQwSVBaAEpwtYEZbfA 7OZCucM/sC4dKVfp5pqOEfc7awTXzZKZRZErmBEw=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E0FAB74-D0FE-4202-9CE1-84E92770F248"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com>
Date: Wed, 11 Sep 2019 20:05:17 +0000
Cc: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Russ Housley <housley@vigilsec.com>, Sean Turner <sean@sn3rd.com>
To: "netconf@ietf.org" <netconf@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.11-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE>
Subject: [netconf] crypto-types fallback strategy
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Sep 2019 20:05:22 -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