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

Kent Watsen <kent+ietf@watsen.net> Mon, 11 November 2019 03:07 UTC

Return-Path: <0100016e586dbe79-24514978-922b-479b-a523-3d2bbcdc56c4-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 C844B1200EC for <netconf@ietfa.amsl.com>; Sun, 10 Nov 2019 19:07:01 -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 1WEo9VSXRKNY for <netconf@ietfa.amsl.com>; Sun, 10 Nov 2019 19:06:59 -0800 (PST)
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 EB03F1200C3 for <netconf@ietf.org>; Sun, 10 Nov 2019 19:06:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573441617; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ZVog5Mx+9XB9DDHOtE+prEK/lL2tJt+WGkeYr1/Pbyw=; b=WDmLJRvyLbmGincawrJCCn60d61RalrVaBNd6gVNJFo1fYZvgsuYeJzlVP1XbBKq /LbKIXLr4h/Smqg3rf1byPp2b5OCP1nwnHS9+CMNbMIUnUUPppB3nrCyqNRgsOLQvRv yFYpQbHrvvrvc/I3AVGRAb/w5ys8/rz/ad+0fHcA=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016e586dbe79-24514978-922b-479b-a523-3d2bbcdc56c4-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F06B6630-7688-4BEB-9562-0B82D64FBFB8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 11 Nov 2019 03:06:57 +0000
In-Reply-To: <AM0PR07MB5187296C56CCE38DADE9EA1483790@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> <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com> <AM0PR07MB5187296C56CCE38DADE9EA1483790@AM0PR07MB5187.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.11.11-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/xz31MAgCrtqgqgjPqJHwrhljdWE>
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: Mon, 11 Nov 2019 03:07:02 -0000

Hi Balazs,


> 1.       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?
>  
> Balazs> Ok, then let’s wait for WG decision. Well, I just say that the earlier ways of communicating the key formats were adequate from my point of view, which was that in documentation it was said that for RSA use RSAPrivateKey and for EC use ECPrivateKey, and similarly for other types. I’m also ok with the key-format approach if preferred by the WG.
>  
> In earlier versions:
>  
>            description
>              "The value of the binary key.  The key's value is
>               interpreted by the 'algorithm'.  For example, a DSA key
>               is an integer, an RSA key is represented as RSAPrivateKey
>               as defined in RFC 8017 <https://tools.ietf.org/html/rfc8017>, and an ECC key is represented as
>               ECPrivateKey as defined in RFC 5915 <https://tools.ietf.org/html/rfc5915>." 

Yes, the previous way (example above) was adequate, but I believe the new way (i.e. using a key-format leaf) is better as:

1) it enables the a key-type (e.g., a symmetric key) do be expressed in different ways as needed (OctetString vs. OneSymmetricKey vs. EncryptedData)
2) it MAY (haven't tried to model it yet) be able to support encoding variations (DER vs PEM, and CMS vs. multi-part PEM)
3) it decouples the part that we are stuck on (i.e., the 'algorithm' node) and it being factored-out may provide more flexibility in that definition.

The WG hasn't discussed key-format yet.  Above is the first foray into it...do these arguments sound compelling?




> 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?
>  
> Balazs> In RFC2986 <https://tools.ietf.org/html/rfc2986#section-3> the attributes are said to be optional. We just need the subject DN as mandatory, don’t we?
>  
>  
>         1. A CertificationRequestInfo value containing a subject
>            distinguished name, a subject public key, and optionally a
>            set of attributes is constructed by an entity requesting
>            certification.

Thank you.  I've removed these to comments, thus leaving the "attrubtute" nodes as NOT mandatory.




> 3.       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.
>  
> Balazs: You had an example earlier in an email from 10/8/2019, which is about the TLS client/server models. Below, you are referring to some possibly new groupings that you wanted to propose. I don’t understand though why you mentioned these new groupings since ‘ks:local-or-keystore-asymmetric-key-grouping’ (RPK) and something new that just refers to a keystore symmetric key, such as ‘ks:local-or-keystore-symmetric-key-grouping’ (PSK) should be good. This latter I think would be a new grouping, but with existing terminology.
>  
> All, looking at ietf-tls-client.yang and ietf-tls-server.yang, adding the ability to configure the "private" half of a PSK or raw public key would be something like:
>  
>                 OLD
>                     container <client-identity or server-identity> {
>                       uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
> 
>                 NEW
>                     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-raw-public-key-grouping;
>                          uses ks:local-or-keystore-pre-shared-key-grouping;
>  

Ah, now I understand, I and agree that this seems like the right way to do it, but see below...


> To your last sentence regarding features, could you provide an example of what you mean?
>  
>  
> container <client-identity or server-identity> {
>     choice auth-type {
>         mandatory true;
>         case certificate {
>             if-feature x509-certificate-auth;
>            uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
>        }
>         case raw-public-key {
>             if-feature raw-public-key-auth;
>            uses ks:local-or-keystore-asymmetric-key-grouping;
>        }
>         case psk {
>             if-feature psk-auth;
>            uses ks:local-or-keystore-symmetric-key-grouping;
>        }

Better!  This uses the existing groupings (e.g., ks:local-or-keystore-asymmetric-key-grouping) whereas the above proposal defined new ones.  (see GitHub for latest files, though the commit is larger than it should be)

Henk, what do you think?


> I assume these features would then need to be defined in the TLS client/server draft.

Yes.


> 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?
>  
> Balazs> Local definitions are ok too that’s why I used a hypothetical grouping name  ks:local-or-keystore-symmetric-key-grouping.

Sorry, I glossed over the "local-" prefix in your earlier statement.

I agree that PSKs should be in Keystore when used for client-identity/server-identity nodes... (more below)


>   Why was/is seeing them in truststore a surprise, perhaps because they're not encryptable there?
>  
> Balazs> When PSKs are used then both communicating ends use the shared key for signing and verifying messages. Then one configuration seems enough that is either local or from keystore, why would it be necessary to set it up yet another time for verification from local or truststore? This would mean there is no need for a PSK option when configuring how to  verify the peer.
>  
> container <client-authentication or server-authentication> {
>     choice auth-type {
>         mandatory true;
>         case certificate {
>             if-feature x509-certificate-auth;
>             container ca-certs {
>                 uses ts:local-or-truststore-certs-grouping
>             }
>             container server-certs {
>                 uses ts:local-or-truststore-certs-grouping
>             }
>        }
>         case raw-public-key {
>             if-feature raw-public-key-auth;
>                 uses ks: local-or-truststore-raw-pub-keys-grouping
>        }
> 
> No need for PSK config since it is already configured in client/server-identity.

Ack.   (see GitHub for latest files, though the commit is larger than it should be)

And, as a bonus, Keystore already defines support for encryption (unlike Truststore).


>  Or what is the reasoning why it is necessary to configure a PSK from truststore?

Somehow I thought that were being used in conceptually different ways, but I see now that's not really the case...


Thank you, Balazs, this message was most helpful!   

Kent // contributor