[netmod] x509c2n:cert-to-name problem [WAS: [netconf-wg/https-notif] What is the user-id of the entity sending the notification? (#3)]

Martin Bjorklund <mbj@tail-f.com> Wed, 23 October 2019 08:18 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6DD120058 for <netmod@ietfa.amsl.com>; Wed, 23 Oct 2019 01:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4G-HNyqgF02B for <netmod@ietfa.amsl.com>; Wed, 23 Oct 2019 01:18:46 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE4D12002F for <netmod@ietf.org>; Wed, 23 Oct 2019 01:18:46 -0700 (PDT)
Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id C8D071AE018B for <netmod@ietf.org>; Wed, 23 Oct 2019 10:18:44 +0200 (CEST)
Date: Wed, 23 Oct 2019 10:18:44 +0200 (CEST)
Message-Id: <20191023.101844.48270589337022568.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <netconf-wg/https-notif/issues/3/545072069@github.com>
References: <netconf-wg/https-notif/issues/3@github.com> <netconf-wg/https-notif/issues/3/545072069@github.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/JVI5eW8UnO7bQPkveFgbQUQg9f0>
Subject: [netmod] x509c2n:cert-to-name problem [WAS: [netconf-wg/https-notif] What is the user-id of the entity sending the notification? (#3)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2019 08:18:48 -0000

Hi,

Since this is a problem with ietf-x509-cert-to-name I reply to this
question here, rather than buried in a reply to another issue for
another document ;-)

Kent Watsen <notifications@github.com> wrote:
> Separately, I just noticed an issue with the
> `ietf-[net/rest]conf-server` modules using x509c2n:cert-to-name.
> 
> ```
>          leaf fingerprint {
>            type x509c2n:tls-fingerprint;
>            mandatory true;
>            description
>              "Specifies a value with which the fingerprint of the
>               full certificate presented by the peer is compared.  If
>               the fingerprint of the full certificate presented by the
>               peer does not match the fingerprint configured, then the
>               entry is skipped, and the search for a match continues.";
> ```
> 
> This definition seems to exclude authenticating client certificates
> via a trust anchor certificate as, if one can configure a fingerprint,
> then one could also configure the whole certificate (e.g.,
> `tls-server-parameters/client-authentication/client-certs`), thus
> obviating the need for
> `tls-server-parameters/client-authentication/ca-certs`.

[...]

> A better definition (I think) would've been:
> 
> ```
> OLD: full certificate presented by the peer 
> NEW: full certificate of the certificate used to authenticate the
> certificate presented by the peer, which MAY be the peer's end-entity
> certificate.
> ```

Hmm, I think you found an inconsisteny in this module.  Note that the
description of the list itself has:

         The cert-to-name entry's fingerprint
         determines whether the list entry is a match:

         1) If the cert-to-name list entry's fingerprint value
            matches that of the presented certificate, then consider
            the list entry a successful match.

         2) If the cert-to-name list entry's fingerprint value
            matches that of a locally held copy of a trusted CA
            certificate, and that CA certificate was part of the CA
            certificate chain to the presented certificate, then
            consider the list entry a successful match.

Also note:

        Security administrators are encouraged to make use of
        certificates with subjectAltName fields that can be mapped to
        names so that a single root CA certificate can allow all
        child certificates' subjectAltName fields to map directly to
        a name via a 1:1 transformation.

So I think this is a bug in the description of "leaf fingerprint".


> I note that `fingerprint` may be 0 characters in length, which is what
> netconf/restconf servers wanting to support authenticating clients via
> a trust anchor will need to do in their configurations.  I'll update
> the examples in those drafts to include an empty `fingerprint` node.

But 0-length fingerprint won't match anything, which means you won't
get a user name and the client can't be authenticated, and the session
dropped.


/martin