Re: [netconf] client identification in ietf-netconf-server

[Kent Watsen <[e-mail]>]

Hi Martin,


> 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.


Would this be better?   

OLD
       when "../../../../tls";

NEW
	if-feature "tls-listen or tls-call-home";



> But should't this cert-to-name list be available when x509-certs are
> used also with SSH?

Hmmm.  I'd assumed that, with RFC 6187, the username was still passed as its own field, but I see this in Section 4:

   For the purposes of user authentication, the mapping between
   certificates and user names is left as an implementation and
   configuration issue for implementers and system administrators.

So you may be right about that.  I only ever looked at RFC 6187 from the perspective of the server presenting an IDevID certificate.  But, assuming it's true, then perhaps this:

NEWEST:
	if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs";



> 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.

We certainly want to factor out configuration where possible.  I'd need to look into this more.  Perhaps you can send a diff?


> 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.

Okay, let's fix that.


> 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?)

Hmmm, this 'choice' seems unneeded for NETCONF.  The "choice" is coming from the ietf-tls-server, and a similar "choice" is in ietf-http-server. It was put there, in part, for RESTCONF, as user-auth can occur at either (or both!) protocol layers...



> 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.

Well that's just the thing, the goal is to enable user-auth to NOT be defined here.  As the description statement in ietf-tls-server says:

          "Configuring credentials externally enables applications
           to place client authentication with client definitions,
           rather then in a part of a data model principally
           concerned with configuring the TLS transport.";


> 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.

Yes.


> 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.

In context, that statement I made before is a relatively minor objection.  That said, I don't understand your proposal, as you suggesting the recreate the essence of 'cert-to-name'?   Another idea I had was that the fingerprint could be in a "union" with also a truststore-reference, which is only mildly better...


Kent // contributor