Re: [netconf] crypto-types fallback strategy

Kent Watsen <kent+ietf@watsen.net> Tue, 01 October 2019 16:44 UTC

Return-Path: <0100016d8834e6b1-d2301e8e-89e5-4fb1-ae58-057e82c4cf7f-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 CCEB112087A for <netconf@ietfa.amsl.com>; Tue, 1 Oct 2019 09:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 lZHJ9FAhOFIE for <netconf@ietfa.amsl.com>; Tue, 1 Oct 2019 09:44:04 -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 D4E1E120A99 for <netconf@ietf.org>; Tue, 1 Oct 2019 09:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1569948231; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=4gkRxIATdlfKZqTKZXPuqC18LmnSGA7o7TTcqGpZPuI=; b=LUglehm4tVESn6DhA/I2fdVZiKPflzzZpCXQCCSLLtRZhXtRxizo8xYYav1vQVyg qdHgyAMtsV9JGxHWW0xrVi0xiKZFxDj9ywg+Ez7nG8Mo30JVXr3DmCdiqTzaNyo6Bk5 5qcAi4D6Et9HHO2EW29je1lx/u+lsushsOpvpnZ0=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016d8834e6b1-d2301e8e-89e5-4fb1-ae58-057e82c4cf7f-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C241ACA0-321D-45E0-B815-2B13DB6EA9C1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 01 Oct 2019 16:43:51 +0000
In-Reply-To: <02f501d57846$e29a3b20$4001a8c0@gateway.2wire.net>
Cc: Juergen Schoenwaelder <J.Schoenwaelder@jacobs-university.de>, "netconf@ietf.org" <netconf@ietf.org>
To: tom petch <ietfc@btconnect.com>
References: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <MN2PR11MB4366E914816F6C3D9515A31DB5890@MN2PR11MB4366.namprd11.prod.outlook.com> <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> <20190927.170902.142773301948727896.mbj@tail-f.com> <MN2PR11MB4366C30CE4650421CE915840B5810@MN2PR11MB4366.namprd11.prod.outlook.com> <20190927174623.jhvpudof6yfs2m4k@anna.jacobs.jacobs-university.de> <0100016d84c0c469-e57fd7aa-dcba-4079-9b37-22720f7a4500-000000@email.amazonses.com> <02f501d57846$e29a3b20$4001a8c0@gateway.2wire.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.10.01-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/h5YXdKD1en7u0UTk3Pjjjd1J04o>
Subject: Re: [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: Tue, 01 Oct 2019 16:44:08 -0000

Thanks for pointing that out, Tom.  I was going to say something along these lines in a response to Juergen.    The net is that partitioning identities along protocol boundaries is misdirected.  We need to focus on the algorithms, not the cipher suites.  

Going back to the primary goal, we care about is how to use the "algorithm" field to identify the format of the public and private key fields.  To this end, the field could be called a "key-format" instead.   There is a secondary goal to pass an "algorithm" parameter into the 'generate-symmetric-key' and 'generate-asymmetric-key' actions, but maybe the problems can be separated?

In OpenSSL, the commands are:

1) `openssl genrsa -out rsa_private_key.pem 2048` creates an RSAPrivateKey (from RFC3447)
2) `openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem` creates a SubjectPublicKeyInfo (from RFC5280)
3) `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem` creates an ECPrivateKey (from RFC5915)
4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem` creates a SubjectPublicKeyInfo (from RFC5280)

OpenSSH, the commands are:

1) `ssh-keygen -t rsa -b 4096 -C "your_email@example.com"` creates an RSAPrivateKey (from RFC3447) and a proprietary public key file format.
2) `ssh-keygen -t ed25519 -b 4096 -C "your_email@example.com"` creates an ECPrivateKey (from RFC5915) and a proprietary public key file format.
3) `ssh-keygen -e [-m RFC4716] -f <private-key-file>` exports the public key format described by RFC 4716.

Disclaimer: (2) is just a guess, based on (1), which I haven't tested myself yet.


In order to just identify the format, perhaps we use something like the following, which could be in ietf-crypto-types:  (Note I added OneSymmetricKey and OneAsymmetricKey formats as well.  That is, with this approach, it's not an "either-or" tradeoff, both can be defined.)


	    /*** all key format types ****/

	    identity key-format-base {}
	    identity public-key-format { base "key-format-base" }
	    identity private-key-format { base "key-format-base" }
	    identity symmetric-key-format { base "key-format-base" }


	    /**** for private keys ****/

	    identity rsa-private-key-format { // used by SSH and TLS
	        base "private-key-format";
	        description "An RSAPrivateKey (from RFC 3447).";
	    }

	    identity ec-private-key-format { // used by SSH and TLS
	        base "private-key-format";
	        description "An ECPrivateKey (from RFC 5915)";
	    }

	    identity one-asymmetric-key-format {
	        base "private-key-format";
	        description "A OneAsymmetricKey (from RFC 5958).";
	    } 

	    identity encrypted-private-key-format {
	        base "private-key-format";
	        description "A CMS EncryptedData structure (RFC 5652) containing a OneAsymmetricKey (RFC 5958).";
	     }


	    /**** for public keys ****/

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

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


	    /**** for symmetric keys ****/

	    identity symmetric-key-format {
	        base "symmetric-key-format";
                description "An OctetString from ASN.1.";  
	            // Knowing that it is an "OctetString" isn't really helpful.  
	            // Knowing the length of the octet string would help a little, as it relates to the algorithm's block size
	            // We may want to only (for now) use "one-symmetric-key-format" for symmetric keys.
	            //     ^---- the usability issues Juergen mentioned before only applies to asymmetric keys?
	    }

	    identity one-symmetric-key-format {
	        base "symmetric-key-format";
	        description "A OneSymmetricKey (from RFC6031).";
	    } 

	    identity encrypted-symmetric-key-format {
	        base "symmetric-key-format";
	        description "A CMS EncryptedData structure (RFC 5652) containing an OneSymmetricKey (RFC 6031).";
	    } 


then, the public-key grouping might look like:

	  grouping public-key-grouping {
	    description
	      "A public key and its associated algorithm.";
	    leaf key-format {
	      nacm:default-deny-write;
	      type public-key-format;
	      mandatory true;
	      description "Identifies the format key's binary data value.";
	    }
	    leaf public-key {
	      nacm:default-deny-write;
	      type binary;
	      mandatory true;
	      description
	        "The binary value of the public key.  The interpretation
	         of the value is defined by the 'key-format' field.";
	    }
	  }

and the key-pair grouping might look like:

	  grouping asymmetric-key-pair-grouping {
	    description
	      "A private key and its associated public key.";
	    uses public-key-grouping;
	    choice private-key-type {
	      mandatory true;
	      description
	        "Choice between key types.";
	      leaf private-key {
	        nacm:default-deny-all;
	        type binary;
	        description
	          "The binary value of the private key.  The interpretation
	           of the value is defined by the 'key-format' field.";
	      }
	      leaf hidden-private-key {
	        nacm:default-deny-write;
	        type empty;
	        description
	          "A permanently hidden key.  How such keys are created
	           is outside the scope of this module.";
	      }
	    }
	  }

and the symmetric grouping might look like:

	  grouping symmetric-key-grouping {
	    description
	      "A symmetric key and algorithm.";
	    leaf key-format {
	      nacm:default-deny-write;
	      type public-key-format;
	      mandatory true;
	      description "Identifies the symmetric key's format.";
	    }
	    choice key-type {
	      mandatory true;
	      description
	        "Choice between key types.";
	      leaf key {
	        nacm:default-deny-all;
	        type binary;
	        description
	          "The binary value of the key.  The interpretation
	           of the value is defined by the 'key-format' field.";
	      }
	      leaf hidden-key {
	        nacm:default-deny-write;
	        type empty;
	        description
	          "A permanently hidden key.  How such keys are created
	           is outside the scope of this module.";
	      }
	    }
	  }



To put an end to this email, recall above it was said that the secondary goal is to pass an "algorithm" parameter into the 'generate-symmetric-key' and 'generate-asymmetric-key' actions (what kind of key to generate, right?).   Most of the above regards the key formats (not algorithms, though the OneSymmetricKey and OneAsymmetricKey structs do self-identify their algorithms).   I don't have an answer for this yet, but maybe we can mimic some aspect of the above for it?

Comments?



Kent // contributor



> On Oct 1, 2019, at 6:58 AM, tom petch <ietfc@btconnect.com> wrote:
> 
> <inline tp>
> 
> ----- Original Message -----
> From: "Kent Watsen" <kent+ietf@watsen.net>
> To: "Juergen Schoenwaelder" <J.Schoenwaelder@jacobs-university.de>
> Cc: <netconf@ietf.org>; <wang.haiguang.shieldlab@huawei.com>;
> <rifaat.ietf@gmail.com>
> Sent: Tuesday, October 01, 2019 1:38 AM
> 
>> On Sep 27, 2019, at 1:46 PM, Schönwälder, Jürgen
> <J.Schoenwaelder@jacobs-university.de> wrote:
>> 
>> On Fri, Sep 27, 2019 at 03:53:51PM +0000, Rob Wilton (rwilton) wrote:
>>> I basically agree with what Martin is saying.
>> 
>> So do I.
> 
> Hmmm...
> 
>>> 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.
> 
> 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.
> 
> <tp>
> 
> Kent
> 
> I am not sure how this can work. TLS has ciphersuites, rather than
> algorithms, albeit which are combinations of algorithms.  Taking TLS1.2,
> RFC5246, the ciphersuite is a combination of KEX, cipher, MAC leading to
> e.g. TLS_RSA_WITH_AES_128_CBC_SHA
> (which is MTI).
> 
> Separately, it has a signature algorithm and hash algorithm registry
> which may be relevant, depending on the ciphersuite; these fit rather
> better with the approach of this model.
> 
> Looking at the IANA registry of Transport Layer Security Cipher Suites
> gives (to me) a good sense of how this has evolved from a base list for
> TLS1.2 in RFC5246 with RFC5932 then adding Camellia, RFC5288 AES GCM
> while RFC6289 updates the use of ECC, RFC5487 adds PSK with AES GCM,
> RFC7251 adds AES-CCM, RFC7905 adds CHACHA20 and so on.  It is a long
> list, extended many times.  TLS 1.3 is, so far, a shorter list.
> 
> So is your list of all the ciphersuites or multiple lists of the
> algorithms that
> underpin them?
> 
> It comes back to what is going to use this module. Whenever I see TLS, I
> see ciphersuites first and foremost, not algorithms.
> 
> SSH is different, with KEX method names, authentication method names
> encryption algorithm names and so on, with far fewer of them, a better
> fit for this model.  But then SSH includes the Diffie-Hellman group in
> the KEX name where TLS puts that in an extension - not the
> ciphersuite -for TLS1.3 so the concept of a KEX is a bit different.
> 
> Tom Petch