[netconf] client identification in ietf-netconf-server

Martin Bjorklund <mbj@tail-f.com> Wed, 30 October 2019 14:56 UTC

Return-Path: <mbj@tail-f.com>
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 83E92120108 for <netconf@ietfa.amsl.com>; Wed, 30 Oct 2019 07:56:28 -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 We9t_WX3DhOE for <netconf@ietfa.amsl.com>; Wed, 30 Oct 2019 07:56:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4D51200C4 for <netconf@ietf.org>; Wed, 30 Oct 2019 07:56:26 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 827171AE0388 for <netconf@ietf.org>; Wed, 30 Oct 2019 15:56:24 +0100 (CET)
Date: Wed, 30 Oct 2019 15:55:54 +0100 (CET)
Message-Id: <20191030.155554.1912259150134728652.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.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/netconf/P9cbDm36ohGSdzTqQ469sazDSJM>
Subject: [netconf] client identification in ietf-netconf-server
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, 30 Oct 2019 14:56:28 -0000

Hi,

The ietf-netconf-server module has this:

  grouping netconf-server-grouping {
    ...
    container client-identification {
      ...
      container cert-maps {
        when "../../../../tls";
        uses x509c2n:cert-to-name;
        ...
      }
    }
  }

Note the "when" expression.  This means that the grouping has a strong
depency on where is it used.  We should try to avoid such a design.

But should't this cert-to-name list be available when x509-certs are
used also with SSH?  The current data model for ssh specifies certs on
a per-user basis. But this requires lots of configuration in the case
that the cert encodes the user name (even though the name is in the
cert you have to configure each user on each device).  I suggest we
align the model for SSH with the TLS model for cert identification.


For TLS, the data model has the following structure:

  +--rw netconf-server
     +--rw listen! {ssh-listen or tls-listen}?
        +--rw idle-timeout?   uint16
        +--rw endpoint* [name]
           +--rw name         string
           +--rw (transport)
              ...
              +--:(tls) {tls-listen}?

    [ reset indentation to make the diagram easier to read ]

   +--rw tls
      +--rw tcp-server-parameters
      ...
      +--rw tls-server-parameters
      |  +--rw server-identity
            ...
      |  +--rw client-authentication!
      |  |  +--rw (required-or-optional)
      |  |  |  +--:(required)
      |  |  |  |  +--rw required?    empty
      |  |  |  +--:(optional)
      |  |  |     +--rw optional?    empty
      |  |  +--rw (local-or-external)
      |  |     +--:(local)  {local-client-auth-supported}?
      |  |     |  +--rw ca-certs!   {ts:x509-certificates}?
      |  |     |  |  +--rw (local-or-truststore)
      |  |     |  |     +--:(local)  {local-definitions-supported}?
      |  |     |  |     |  +--rw local-definition
      |  |     |  |     |     +--rw cert*   trust-anchor-cert-cms
      |  |     |  |     |     +---n certificate-expiration
      |  |     |  |     |        +-- expiration-date
      |  |     |  |     |                yang:date-and-time
      |  |     |  |     +--:(truststore)
      |  |     |  |              {truststore-supported,x509-certificates}?
      |  |     |  |        +--rw truststore-reference?
      |  |     |  |                ts:certificates-ref
      |  |     |  +--rw client-certs!  {ts:x509-certificates}?
      |  |     |     +--rw (local-or-truststore)
      |  |     |        +--:(local)  {local-definitions-supported}?
      |  |     |        |  +--rw local-definition
      |  |     |        |     +--rw cert*     trust-anchor-cert-cms
      |  |     |        |     +---n certificate-expiration
      |  |     |        |        +-- expiration-date
      |  |     |        |                yang:date-and-time
      |  |     |        +--:(truststore)
      |  |     |                 {truststore-supported,x509-certificates}?
      |  |     |           +--rw truststore-reference?
      |  |     |                   ts:certificates-ref
      |  |     +--:(external)
      |  |              {external-client-auth-supported}?
      |  |        +--rw client-auth-defined-elsewhere?
      |  |                empty
          ...
      +--rw netconf-server-parameters
         +--rw client-identification
            +--rw cert-maps
               +--rw cert-to-name* [id]
                  +--rw id             uint32
                  +--rw fingerprint
                  |       x509c2n:tls-fingerprint
                  +--rw map-type       identityref
                  +--rw name           string


It is not clear how this is used by the server to end up either with
an authenticated user name or failed authentication.

First of all, how is the "required-or-optional" choice used in a
NETCONF server?  What happens if an operation configures this to
"optional"?  (side note: why is this a choice of empty leafs instead
of a leaf?)

Second, I assume that the idea is that the server uses the config
params in "local-or-external" and the certificate presented by the
client and after this step is either accepted or rejected.  It is not
clear what is supposed to happen if someone configures
"client-auth-defined-elsewhere".  I think it is better to not define
this case, but (perhaps) keep the choice and explain that other
modules can augment additional config params here for other
authentication mechanisms.

Next, my guess is that the intention is that if the cert was accepted
in the step above, it is checked in cert-to-name to see if a user name
can be derived.

In another thread you mentioned that if a local cert is configured, it
seems redundant to also configure the cert as a fingerprint in
cert-to-name.  I'm not sure about this.  But perhaps you can use the
same "map-type" and "name" leafs in the "client-cert" container?  It
is not as easy for the "truststore-reference"; perhaps you'd have to
augment the truststore with these leafs in this case.


/martin