[netconf] client authentication in the ietf-[ssh/tls/http]-server models

Kent Watsen <kent+ietf@watsen.net> Mon, 29 April 2019 16:00 UTC

Return-Path: <0100016a69d2e950-218c4aa5-2d10-405f-b1ee-6396dda0d3c6-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 E25531203C0 for <netconf@ietfa.amsl.com>; Mon, 29 Apr 2019 09:00:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 8PBNnHaV-vqj for <netconf@ietfa.amsl.com>; Mon, 29 Apr 2019 09:00:00 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8FE1203EC for <netconf@ietf.org>; Mon, 29 Apr 2019 08:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556553591; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=a8XofmJE9HVY5ZYBsCFgNH++pGHHrvkEkrfGQhIMjxI=; b=Mg8AXu54NHAg4sWKj5qHMDCdCb0bi2O1/W7/YK6U2xK29/qroand9Q0Aag6BgDbj xy/6MB89jfh9e1HJBMjZNjjvBgXFXGt8PXAe7kL4Iqg9w3+9joNlA8YaS7SNxs9vm04 Wv0JEZKNmBthGmrQ0b7VSmORCXr5qMXja0vYSELw=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-ID: <0100016a69d2e950-218c4aa5-2d10-405f-b1ee-6396dda0d3c6-000000@email.amazonses.com>
Date: Mon, 29 Apr 2019 15:59:51 +0000
To: "netconf@ietf.org" <netconf@ietf.org>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.29-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Z1rUxJI0zLrA27FOBtRhLo08kW4>
Subject: [netconf] client authentication in the ietf-[ssh/tls/http]-server models
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: Mon, 29 Apr 2019 16:00:04 -0000

The ietf-ssh/tls/http-server models have, or should have, to some extent or another, configuration for client authentication, but there appears to be a fine line between configuring the kind of authentication needed versus configuring to perform the authentication itself.

To clarify:

1) The SSH protocol requires client authentication and itself prompts for a username.  Additionally the SSH server needs to be configured as to what kinds of client auth it supports (passwords, rsa-key, client certs per RFC 6187, etc.).

2) The TLS protocol does not require client authentication, but has a configurable option for if the TLS server requests the TLS client to send a client certificate.  When client certificates are provided, there is a further distinction between authenticating the certificate versus extracting an identity from the certificate.

3) The HTTP protocol does not require authentication but, when it does, the authentication mechanism resolves to a username.

4) NETCONF-over-SSH inherits SSH's guarantee for username extraction.  NETCONF-over-TLS needs to configure the TLS-layer to prompt for the client certificate and have configuration for how to extract a username from the certificate (i.e., cert-maps).

5) RESTCONF is only HTTP-over-TLS, but leaves it open as to if client authentication occurs at the TLS or HTTP (or both) layers.  If client auth occurs at the TLS layer, there needs to be configuration for how to extract a username from the certificate (i.e., cert-maps).


In general (and exhibited by RFC 7317's "users" model), there is a desire to colocate the client auth credentials within the "client" nodes, outside of the "transport" tree.

For instance, suppose a hypothetical app has two RESTCONF interfaces; a northbound interface for "users" and a southbound interface for "devices".  At a very high-level, the app's model looks like this:

    +-- transport
    |   +-- restconf-server-config
    |       +-- listen
    |           +-- endpoint
    |               +-- ... (for northbound interface)
    |           +-- endpoint
    |               +-- ... (for southbound interface)
    +-- users
    |   +-- user
    |       +-- name
    |       +-- http-auth
    |           +-- basic-auth-password
    +-- devices
        +-- device
            +-- name
            +-- tls-auth
            |   +-- trust-anchor-certificate
            |   +-- cert-map
            +-- http-auth
                +-- basic-auth-password


Not that, in the above tree diagram, having a trust-anchor-certificate and cert-map configured per-device is very flexible, but likely overkill for most circumstances.

In trying to square all of the above, I believe that the "client-authentication" nodes in the various <protocol>-server models need to be reworked.  My idea is to add a combination of "presence" and "choice" node indicating if client authentication 1) is prompted for at all, 2) is required or optional, 3) is locally or externally defined, and 4) if local, the configuration necessary to perform the local configuration.

Whilst a fairly isolated problem (client auth in just the "server" models), it is still a pretty complicated edit and difficult to describe.  My idea is to make the edit and then publish an update to the drafts so it can be seen.  If folks don't like it, we can roll it back.  That said, given that I've been staring at this for a few days now, my guess/hope is that folks will see it as "better" and we can fine-tune tweak it from there.

An updated suite of drafts will be posted this week!  (These updates will also address the various other issues raised on list recently).

Kent // contributor