Re: [netconf] FIXMEs in ietf-crypto-types and client/server models
Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Wed, 06 November 2019 07:56 UTC
Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 8071A120BFF for <netconf@ietfa.amsl.com>; Tue, 5 Nov 2019 23:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 z0PCRD6yFH0r for <netconf@ietfa.amsl.com>; Tue, 5 Nov 2019 23:56:12 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037F7120C01 for <netconf@ietf.org>; Tue, 5 Nov 2019 23:56:11 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xA67u7fB015319 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 6 Nov 2019 08:56:08 +0100
Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 6 Nov 2019 08:56:02 +0100
To: Kent Watsen <kent+ietf@watsen.net>, Balázs Kovács <balazs.kovacs@ericsson.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
References: <AM0PR07MB5187A1438941A29D28CE3486837E0@AM0PR07MB5187.eurprd07.prod.outlook.com> <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <2b0daa52-10e4-566b-6e66-760dbd47c24b@sit.fraunhofer.de>
Date: Wed, 06 Nov 2019 08:56:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <0100016e3ed10fbb-8a5a44a9-6df6-4ac1-9b56-8dbf61ec64cc-000000@email.amazonses.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.112.245]
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/tO7pqgdRLIsEocbvuTKAs6s39Vg>
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 07:56:16 -0000
Hi Balázs, hi list, Item 3.) is on me, I think. Sorry! For me personally, there are a few technical questions that have to be resolved on the list first. Under the assumption that the trust stores will be used for TLS (maybe potential other things), I am not sure if the YANG module is an appropriate place to make some (maybe implicit?) "mandatory-to-implement" decisions. If there can be (and I think effectively there should be, but I do not know the appropriate place for them) prescriptive statements here, I would recommend the following proposals for the use with TLS: 1.) With respect to the format of the "raw" pub-key, I propose that the structure defined in section 3 of RFC 7250 MUST be used. 2.) With respect to cipher suite and interoperability, I propose to make RFC 7151 and RFC 4492 (basically the NIST curve and its format extensions) mti for raw pub-key and to point to RFC 7250 for guidance & to make RFC6635 mti for psk. 3.) With respect to key identities, I propose that raw pub-key identities as specified in RFC 6920 and a minimum hash length enabled by mode sha-256-120 MUST be used & to support and recommend the use of Identity Hints (section 5.2. in RFC 4279) for PSKs and refer to the corresponding security considerations (section 7 in RFC 4279). My first question - on a technical level: do these proposals in the context of using TLS sound reasonable to the group? My second question - on a semantic level: do these normative requirements belong here? My third question - on a noob level :) If they belong here, where would these mandatory requirements be spelled out? Viele Grüße, Henk On 06.11.19 04:45, Kent Watsen wrote: > > 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. > > >> 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? > >> 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? > > > >> 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). > 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 > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >
- [netconf] FIXMEs in ietf-crypto-types and client/… Balázs Kovács
- Re: [netconf] FIXMEs in ietf-crypto-types and cli… Kent Watsen
- Re: [netconf] FIXMEs in ietf-crypto-types and cli… Henk Birkholz
- Re: [netconf] FIXMEs in ietf-crypto-types and cli… Balázs Kovács
- Re: [netconf] FIXMEs in ietf-crypto-types and cli… Kent Watsen
- Re: [netconf] FIXMEs in ietf-crypto-types and cli… Kent Watsen
- Re: [netconf] FIXMEs in ietf-crypto-types and cli… Balázs Kovács
- Re: [netconf] FIXMEs in ietf-crypto-types and cli… Balázs Kovács
- Re: [netconf] FIXMEs in ietf-crypto-types and cli… Kent Watsen