Re: [netconf] a comment on draft-ietf-netconf-tls-client-server-15
Kent Watsen <kent@watsen.net> Wed, 23 October 2019 16:29 UTC
Return-Path: <0100016df97342cf-58f4f854-4372-4da7-aab6-86959cc275d7-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 BDA091201B7 for <netconf@ietfa.amsl.com>; Wed, 23 Oct 2019 09:29:11 -0700 (PDT)
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 NmTAPbOkDS7h for <netconf@ietfa.amsl.com>; Wed, 23 Oct 2019 09:29:09 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A19C1200A3 for <netconf@ietf.org>; Wed, 23 Oct 2019 09:29:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1571848143; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=YAK08mog1YDpkQfiMC8UPLQmc6dp49K/aUdKkI8IlQo=; b=Gc6Hp7BYyzoc/xryRCWMtUnN7i0G6m9SKhFLeq6Z9G3vh6hAp1VB4bjkX8Yid147 3QnQw+RcViCZIpShm/3AW6neGObZGvpm/qyKhZCyzyVQ2XFzlxWpK5EiN88BwlqBgwi zLeW38toeJqWY+49V6IzIQE8Um5HEZ1n9DRY68TY=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100016df97342cf-58f4f854-4372-4da7-aab6-86959cc275d7-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F866A6DF-FBFF-43B8-8706-C56366780321"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 23 Oct 2019 16:29:03 +0000
In-Reply-To: <20191023.093715.2094043256766716320.mbj@tail-f.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.com>
References: <20191023.093715.2094043256766716320.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.10.23-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/LkQJYPhGPvEkqgDEg3LgGoxucRc>
Subject: Re: [netconf] a comment on draft-ietf-netconf-tls-client-server-15
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, 23 Oct 2019 16:29:12 -0000
Hi Martin, Thanks for digging into this. > The model has (pruned to illustrate my point): > > container server-authentication { > nacm:default-deny-write; > must 'ca-certs or server-certs'; > container ca-certs { > if-feature "ts:x509-certificates"; > presence ...; > ... > } > container server-certs { > if-feature "ts:x509-certificates"; > presence ...; > ... > } > } This is in ietf-tls-client.yang, for those interested. > 1. If a server doesn't implement the feature ts:x509-certificates, > the model effectively becomes: > > container server-authentication { > nacm:default-deny-write; > must 'ca-certs or server-certs'; > } > > This must expression will never be true, which means that it is > not possible to configure anything! The "if-feature" statements above are no longer valid since now "local" configuration is supported (i.e., `ts:local-or-truststore-certs-grouping`), so the truststore no longer is required to be implemented. Simply removing the two "if-feature" statements in ietf-tls-client.yang resolves the issue. Note that ts:local-or-truststore-certs-grouping have within it if-feature statements that prune the "truststore" half out. Checking the other models, there were also instances of this in ietf-tls-server.yang and in both the ssh client and server modules. > 2. When this grouping is used in ietf-https-notifs, it looks like > this: > > +--rw receivers > +--rw receiver* [name] > +--rw name string > ... > | +--rw server-authentication > | | +--rw ca-certs! {ts:x509-certificates}? > ... > | | +--rw server-certs! {ts:x509-certificates}? > ... > > Now, the container 'server-authentication' has > nacm:default-deny-write, and its contents is mandatory (due to the > must expression). This means that it is not possible to configure > a single receiver without explicit NACM rules for this container. Is > that really the intention? Yes, these are security parameters. Read access is okay, but only authorized clients should be able to configure them. > 3. You don't have a choice between ca-certs and server-certs, which I > assume is intentional (they can both exist). I think you need to > explain what happens when both these are configured. OLD: container server-authentication { ... description "Trusted server identities."; NEW: container server-authentication { ... description "Trusted server identities. Any combination of trusted server identities is additive and unordered."; Is this okay? > 4. The description of ca-certs and server-certs has: > > "A server certificate is authenticated if ..." > > But you don't specify what it means for a certificate to be > authenticated. If the intention is that the meaning depends on > where it is used, the description of the grouping should specify > this requirement. For "ca-certs", the full sentence is: A server certificate is authenticated if it has a valid chain of trust to a configured CA certificate."; For server-certs, the full sentence is: A server certificate is authenticated if it is an exact match to a configured server certificate."; How is the 2nd-half of these sentences not doing just what you're asking for? Kent // contributor
- [netconf] a comment on draft-ietf-netconf-tls-cli… Martin Bjorklund
- Re: [netconf] a comment on draft-ietf-netconf-tls… Martin Bjorklund
- Re: [netconf] a comment on draft-ietf-netconf-tls… Kent Watsen
- Re: [netconf] a comment on draft-ietf-netconf-tls… Martin Bjorklund
- Re: [netconf] a comment on draft-ietf-netconf-tls… Kent Watsen