Re: [netconf] FIXMEs in ietf-crypto-types and client/server models

Kent Watsen <kent+ietf@watsen.net> Wed, 06 November 2019 03:45 UTC

Return-Path: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-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 78842120033 for <netconf@ietfa.amsl.com>; Tue, 5 Nov 2019 19:45:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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] 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 pxH4T3AdNKDs for <netconf@ietfa.amsl.com>; Tue, 5 Nov 2019 19:45:20 -0800 (PST)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3369B12002E for <netconf@ietf.org>; Tue, 5 Nov 2019 19:45:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573011918; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=JygmWiIH9P2Q/OohZPFOS1TWTiSq3f0LIWhKA6kw9l4=; b=GV4EJVoOonLJ6otptXEKPVKA8MQ2vyNp9yaYBwLRYZgZdwmvIfFHMmNyqk2wvddN QSIOWhbqXDXkSZ3UWLj6YWnrLUF2He5HqjUYCYGg7u8titR0St+8Mnsy++nU8OPS6p4 IVSj/S8MpFEzX0bFncqyittBFecjaCq/uV9IaS7Y=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8EACB715-DF9B-4D04-9B90-7C2ED3D3F166"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 6 Nov 2019 03:45:18 +0000
In-Reply-To: <AM0PR07MB5187A1438941A29D28CE3486837E0@AM0PR07MB5187.eurprd07.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= <balazs.kovacs@ericsson.com>
References: <AM0PR07MB5187A1438941A29D28CE3486837E0@AM0PR07MB5187.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.11.06-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WfJOTNeKXDW7_RRfziJ8py8IyZ4>
Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models
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, 06 Nov 2019 03:45:23 -0000

Hi Balázs,


> I see some FIXMEs in ietf-crypto-types and related models. I would be interested about the current state of them and possibility to clean them up.

Yes!  thanks for taking this up.


> Key-format (symmetric-key, public-key, asymmetric-key-pair)
> I assume the idea here is to make it possible to have choices for the ASN.1 types holding the keys. If this flexibility for formats is necessary I don’t have any objection to them but having a single agreed type for these different use cases would also suffice.

I believe here you're referring to the 3 instances of lines like:

      leaf key {
        nacm:default-deny-all;
        type binary;
        //must "../key-format";  FIXME: remove comment if approach ok
        ...
      }

FWIW, the whole "key-format" leaf is still being sussed out (your opinion would be helpful on that thread as well) but, so far it seems promising.  The reason these lines are commented out is because 1) the WG hasn't committed to this path yet and 2) I didn't want to update all the examples in all the drafts (other than truststore and keystore) to add a "key-format" leaf until the WG had more consensus on the "key-format" leafs.

I don't understand your last comment/sentence.  Can you provide an example?

 
> 2.       attributes in asymmetric-key-pair-with-cert(s)-grouping
> I think attributes should be kept optional. If there is anything else besides subject seen mandatory maybe it should be extracted out from attributes and be spelled out a separate leaf, but I don’t think there is.

I believe here you're referring to the 2 instances of lines like:

        leaf attributes {
          type binary; // FIXME: does this need to be mandatory?
          ...
        }

These are in the "generate-certificate-signing-request" actions found inside the asymmetric-key-pair-with-cert(s)-grouping.

Hmmm, are you claiming that "attributes" are not required in order to generate a CSR?  I think the CSR itself MUST have attributes (right?) so, if not specified, what default values are used?



> PSK and raw public keys
> The use case of PSK and raw public keys are not the most urgent in my opinion which now slows a bit the progress of these drafts, but let’s make an attempt to finalize them.

Agreed, but they are legal for TLS and a WG member stated that they were needed in order to support another IETF WG's efforts.  A quick resolution would be best!

 
> raw-public-keys: I see these were added due to RFC 7250 and 8446. I guess in truststore this is a separate container to distinguish from SSH host keys. For configuring the private part I think keystore already gives support for this case with the asymmetric key (w/o cert) and in the client/server drafts Kent’s proposal could be used (I replaced raw public key with existing type, shouldn’t that be useable straight away?)
>  
>                     container <client-identity or server-identity> {
>                       choice auth-type {
>                          uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
>                          uses ks:local-or-keystore-asymmetric-key-grouping;
> 
> I would also prefer if these choices are in features, so that an implementation can choose.

To your first sentence, yes, "psk" (and "raw-public-key") are top-level nodes in truststore, as can be seen here (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2.1 <https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2.1>).   Note, the trust-anchors draft accidentally doesn't include the ietf-truststore.yang module.

The body of your comment above seems to be about supporting the secret-half of the PSK and RPK within the Keystore.  I've raise this question a couple times previously to Henk (who's asking for the PSK/RPK add), but he's not responded yet as to if doing so is important (though I can only imagine that it does).   With that said, I think your YANG snippet is meant to be in ietf-tls-server and ietf-tls-client modules (right?).  I'm having a hard time following the "I replaced raw public key with existing type, shouldn’t that be useable straight away?" comment.

To your last sentence regarding features, could you provide an example of what you mean?

PS: none of this goes to the FIXME in the ietf-crypto-types.  I had previously asked Henk to provide some text here as well but, apparently, like all of us at this time, he's been busy!


>  psk: given that the asymmetric keys without certs were covered by host keys and raw public keys, I think psk should only be symmetric keys. Symmetric keys are then sensitive/secret data and as such I believe they should only be referenced from keystore. Seeing them in truststore was unexpected for me. When it comes to their use, clients and servers should be extended with following configuration (and I assume we talk of TLS clients and servers only):
>  
>                     container <client-identity or server-identity> {
>                       choice auth-type {
>                          uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
>                          uses ks:local-or-keystore-asymmetric-key-grouping;
>                        uses ks:local-or-keystore-symmetric-key-grouping;
>  
> Latter grouping would be a new one, but it would use existing constructs and terms from keystore. I don’t think we need new ones. Selected cipher suites will need to have PSK in them for using symmetric key (similar match needed for the others). Note that symmetric keys can be used for other cases than TLS PSK, for example SNMPv3 USM. Again, features would be necessary (those could be saying x.509 or raw-public-key or psk).


Correct, I said the same (that PSKs are essentially symmetric keys) before as well.  Regarding only being referenced to keystore, why not also support them being local-definitions too?  Certainly not a problem if encrypted and, even when not encrypted, then they can be "protected" by NACM-like mechanisms, right?   Why was/is seeing them in truststore a surprise, perhaps because they're not encryptable there?  I agree that symmetric keys can be used beyond PSK (and encryption of the asymmetric keys, the original use case).  Regarding features, again, please provide a YANG-snippet so it is clear to me (and all) what you mean.


Thanks!
Kent