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