[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
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
- [netconf] client identification in ietf-netconf-s… Martin Bjorklund
- Re: [netconf] client identification in ietf-netco… Kent Watsen
- Re: [netconf] client identification in ietf-netco… Martin Bjorklund
- Re: [netconf] client identification in ietf-netco… Kent Watsen
- Re: [netconf] client identification in ietf-netco… Martin Bjorklund
- Re: [netconf] client identification in ietf-netco… Kent Watsen
- Re: [netconf] client identification in ietf-netco… Martin Bjorklund
- Re: [netconf] client identification in ietf-netco… Kent Watsen