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

From: Kent Watsen <[email-masked]>
Date: Mon, 29 Apr 2019 15:59:51 +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