Re: TLS certificates for NFS-over-TLS floating client

On Wed, 04 Mar 2020 13:35:15 +0900 (JST) Hiroki Sato hrs_at_FreeBSD.org said

> Rick Macklem <rmacklem_at_uoguelph.ca> wrote
>  in
> <YTBPR01MB3374EFF14948CB8FEA1B5CCDDDE50_at_YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>:
> 
> rm> Hi,
> rm>
> rm> I am slowly trying to understand TLS certificates and am trying to
> figure
> rm> out how to do the following:
> rm> -> For an /etc/exports file with...
> rm> /home -tls -network 192.168.1.0 -mask 255.255.255.0
> rm> /home -tlscert
> rm>
> rm> This syntax isn't implemented yet, but the thinking is that clients on
> the
> rm> 192.168.1 subnet would use TLS, but would not require a certificate.
> rm> For access from anywhere else, the client(s) would be required to have a
> rm> certificate.
> rm>
> rm> A typical client mounting from outside of the subnet might be my laptop,
> rm> which is using wifi and has no fixed IP/DNS name.
> rm> --> How do you create a certificate that the laptop can use, which the
> NFS
> rm>       server can trust enough to allow the mount?
> rm> My thinking is that a "secret" value can be put in the certificate that
> the NFS
> rm> server can check for.
> 
> I do not think it is a good idea to use a certificate with an
> embedded secret for authentication and/or authorization.
> 
> In the case that the client offers a certificate upon establishing a
> TLS connection for authentication purpose, the authenticity will be
> checked on the server usually by using the CA certificate which was
> used to issue the client certificate.  The CA cert must be put to
> somewhere the NFS server can read.
> 
> The CA cert is secret.  So if the NFS server can check the client
> certificate by the CA certificate, it means the NFS server can
> trust the client.  I think no additional information is required.
> 
> Authorization such as which mount point can be mounted by using the
> client cert can be implemented by using the CN field or other X.509
> attributes, of course.  It can be just a clear text.
> 
> I think this is one of the most reliable and straightforward ways
> because in most cases both NFS servers and the clients are under the
> sysadmin's control.
> 
> rm> Now, I'm not sure, but I don't think this certificate can be created via
> rm> a trust authority such that it would "verify". However, the server can
> rm> look for the "secret" in the certificate and allow the mount based on
> that.
> 
> In the way described above, to use TLS client authentication, the NFS
> server admin has to have a certificate which allows to sign another
> certificate.  This means that the admin must be a CA or trusted
> authority.
> 
> In practice, one can generate a self-signed certificate by using
> openssl(1) and use it as its CA certificate.  He can issue
> certificates signed by it for the NFS clients, and put his CA
> certificate to somewhere the NFS server can read.
> 
> rm> Also, even if the NFS client/server have fixed IP addresses with well
> known
> rm> DNS names, it isn't obvious to me how signed certificates can be
> acquired
> rm> for them?
> rm> (Lets Encrypt expects the Acme protocol to work and that seems to be
> rm> web site/http specific?)
> 
> TLS certificates do not always have (or do not need to have) a domain
> name as an attribute.  Data in attributes are restricted depending on
> the purpose, so certificates issued by Let's Encrypt can have only
> domain names (CN or Subject Alternative Name), for example.  An
> example which is not supported by Let's Encrypt is a certificate for
> S/MIME email encryption which has an email address.
FWIW here's an example from the headers coming from this list.
Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80])
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
    (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK))
    by mx2.freebsd.org (Postfix) with ESMTPS id 1B07B7E9A8;
    Wed,  4 Mar 2020 04:37:12 +0000 (UTC)
    (envelope-from owner-freebsd-current_at_freebsd.org)
Not sure if it would help with your intent here. But there it is. :)

--Chris
> 
> -- Hiroki