Support for restricting client certificates trusted by server

[bwhacks]

Currently it appears that when the server is configured with "xprtsec=mtls", any client certificate issued by any CA in the system trust store will be accepted. I would guess that this is not what administrators would want from client authentication.

I would expect to be able to configure a server to trust only client certificates issued by a specific CA (perhaps an internal CA) and/or client certificates for hostnames with a specific domain. But it possibly makes sense to allow specifying required values for all of the standard subject fields.

[chucklever]

I would expect to be able to configure a server to trust only client certificates issued by a specific CA (perhaps an internal CA)

We have in the past discussed how to provide a particular narrow trust chain for kernel TLS consumers. This is particularly interesting if the server's certificate is self-signed.

• I think it would be possible, as a first pass, to specify a pathname to a bundle file in tlshd.conf.
• Alternatively, we can set up a keyring with the CA bundle on it, and pass that keyring's serial to tlshd for each handshake. That enables, say, each export to use it's own specific bundle.

I can discuss this feature request with our team.

and/or client certificates for hostnames with a specific domain.

So we would combine /etc/netgroup-style checking with certificate checking? Can you elaborate?

But it possibly makes sense to allow specifying required values for all of the standard subject fields.

This starts to make the export administrative interface quite unwieldy. I would need to see use cases to understand exactly what is required.

[bwhacks]

I would expect to be able to configure a server to trust only client certificates issued by a specific CA (perhaps an internal CA)

We have in the past discussed how to provide a particular narrow trust chain for kernel TLS consumers. This is particularly interesting if the server's certificate is self-signed.

• I think it would be possible, as a first pass, to specify a pathname to a bundle file in tlshd.conf.

That sounds good.

• Alternatively, we can set up a keyring with the CA bundle on it, and pass that keyring's serial to tlshd for each handshake. That enables, say, each export to use it's own specific bundle.

I don't know enough about keyrings to comment on this.

I can discuss this feature request with our team.

and/or client certificates for hostnames with a specific domain.

So we would combine /etc/netgroup-style checking with certificate checking? Can you elaborate?

As an example, I use something like this for SMTP among the computers in my own domain:

• I get a certificate for each of them. This could be done with a private CA but I use Let's Encrypt. For those that aren't public servers, I use the dns-01 challenge method.
• I configure exim on each computer to use this as a client certificate when sending over TLS.
• On the mail server, I allow relaying mail from clients that present a certificate (from any trusted CA, I think) with a name under my domain.
• Everywhere else, I configure exim to use that mail server as a smarthost with TLS required.

I could imagine some organisations wanting to authenticate NFS clients in a similar way. But I'm not a real sysadmin and I might have just invented something weird. :-)

But it possibly makes sense to allow specifying required values for all of the standard subject fields.

This starts to make the export administrative interface quite unwieldy. I would need to see use cases to understand exactly what is required.

Right, the problem is I don't think there's an established standard for how to validate client certificates. (Aside from: run your own CA and only trust certificates from that one.) So I don't know what options are actually needed!

[chucklever]

and/or client certificates for hostnames with a specific domain.

So we would combine /etc/netgroup-style checking with certificate checking? Can you elaborate?

As an example, I use something like this for SMTP among the computers in my own domain:

• I get a certificate for each of them. This could be done with a private CA but I use Let's Encrypt. For those that aren't public servers, I use the dns-01 challenge method.
• I configure exim on each computer to use this as a client certificate when sending over TLS.
• On the mail server, I allow relaying mail from clients that present a certificate (from any trusted CA, I think) with a name under my domain.
• Everywhere else, I configure exim to use that mail server as a smarthost with TLS required.

I could imagine some organisations wanting to authenticate NFS clients in a similar way. But I'm not a real sysadmin and I might have just invented something weird. :-)

The Linux NFS server has /etc/exports settings that allow filtering client access via IP address. That is a separate security policy mechanism that could be used in combination with certificate verification to achieve similar results, I would think.

[bwhacks]

The Linux NFS server has /etc/exports settings that allow filtering client access via IP address. That is a separate security policy mechanism that could be used in combination with certificate verification to achieve similar results, I would think.

I don't think that's particularly useful. If access to the network is strictly controlled then it could work but TLS is not really needed. If access to the network is not so well controlled, an attacker could attach their own device with an arbitrary client certificate for NFS, which would be accepted.

[chucklever]

If access to the network is strictly controlled then it could work but TLS is not really needed.

That's arguable. For instance, an RPC-with-TLS certificate can contain instructions to treat all RPCs from a particular client as coming from a specific AUTH_SYS user. TLS encryption can still protect against snooping by other clients, even if the server trusts those clients.

If access to the network is not so well controlled, an attacker could attach their own device with an arbitrary client certificate for NFS, which would be accepted.

I thought that was what the chain of trust was for? The server's client certificate verification process would prevent access by a client with an unrecognized signer, even if that client has an allowed IP address.

[eingemaischt]

We have in the past discussed how to provide a particular narrow trust chain for kernel TLS consumers. This is particularly interesting if the server's certificate is self-signed.

• I think it would be possible, as a first pass, to specify a pathname to a bundle file in tlshd.conf.
• Alternatively, we can set up a keyring with the CA bundle on it, and pass that keyring's serial to tlshd for each handshake. That enables, say, each export to use it's own specific bundle.

Option 1 as general restriction would be great as a first step. In heterogeneous networks it is more or less possible to "steal" an IP and get a Let's Encrypt certificate, so restricting the CA-certificates to one keyring (or one location, or to an array of serials etc) would be great!

[wiesl]

@chucklever Great that already a config option to specify trust store has been implemented. Any update on adding specific clients or wildcards on names?

Thnx.

[chucklever]

Any update on adding specific clients or wildcards on names?

I'm not sure what you are requesting. Names of what?

[wiesl]

Names of certificates (CNs): e.g. a list of valid CN (common name) pathes including wildcards, e.g. myhost1.mydomain1.com, myhost2.mydomain1.com, *.mydomain2.com

These clients are allowed to connect to the NFS server.

[chucklever]

Names of certificates (CNs): e.g. a list of valid CN (common name) pathes including wildcards, e.g. myhost1.mydomain1.com, myhost2.mydomain1.com, *.mydomain2.com

These clients are allowed to connect to the NFS server.

Ah. Common Names are going to be more secure than client DNS labels, aren't they. We have also recently discussed how to deal with transient NFS clients (laptops on wifi), and looking at the CN might be helpful in that scenario.

As I mentioned in response to Ben, this sounds more like an administrative feature of NFSD, rather than a feature of tlshd. But tlshd will have to be involved, certainly.

Ben suggested above that other certificate fields might also be used to filter access (and I'd like to hear specific usage scenarios). At that point, specifying more complex filters in /etc/exports might get awkward. But a list of CN wildcards is probably similar enough to the current legacy IP-based access control in /etc/exports that it could make sense there.

The wire protocol interactions that NFSD would use to reject an unauthorized client also needs to detailed. I'm pretty certain that is not specified by RFC 9289. In other words, would it be an RPC level rejection, or would the TLS handshake fail, or would the server simply drop the connection?