On Tue, May 27, 2025 at 9:58 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>
> On 5/27/25 12:29 PM, Rick Macklem wrote:
> > On Tue, May 27, 2025 at 8:05 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
> >>
> >> On 5/25/25 8:09 PM, NeilBrown wrote:
> >>> On Mon, 26 May 2025, Chuck Lever wrote:
> >>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
> >>>>> Hiya Rick -
> >>>>>
> >>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
> >>>>>
> >>>>>> Do you also have some configurable settings for if/how the DNS
> >>>>>> field in the client's X.509 cert is checked?
> >>>>>> The range is, imho:
> >>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> >>>>>> device). The least secure, but still pretty good, since the ert. verified.
> >>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> >>>>>> the client's IP host address.
> >>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> >>>>>
> >>>>> I've been told repeatedly that certificate verification must not depend
> >>>>> on DNS because DNS can be easily spoofed. To date, the Linux
> >>>>> implementation of RPC-with-TLS depends on having the peer's IP address
> >>>>> in the certificate's SAN.
> >>>>>
> >>>>> I recognize that tlshd will need to bend a little for clients that use
> >>>>> a dynamically allocated IP address, but I haven't looked into it yet.
> >>>>> Perhaps client certificates do not need to contain their peer IP
> >>>>> address, but server certificates do, in order to enable mounting by IP
> >>>>> instead of by hostname.
> >>>>>
> >>>>>
> >>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> >>>>>
> >>>>> I would prefer that we follow the guidance of RFCs where possible,
> >>>>> rather than a particular implementation that might have historical
> >>>>> reasons to permit a lack of security.
> >>>>
> >>>> Let me follow up on this.
> >>>>
> >>>> We have an open issue against tlshd that has suggested that, rather
> >>>> than looking at DNS query results, the NFS server should authorize
> >>>> access by looking at the client certificate's CN. The server's
> >>>> administrator should be able to specify a list of one or more CN
> >>>> wildcards that can be used to authorize access, much in the same way
> >>>> that NFSD currently uses netgroups and hostnames per export.
> >>>>
> >>>> So, after validating the client's CA trust chain, an NFS server can
> >>>> match the client certificate's CN against its list of authorized CNs,
> >>>> and if the client's CN fails to match, fail the handshake (or whatever
> >>>> we need to do).
> >>>>
> >>>> I favor this approach over using DNS labels, which are often
> >>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
> >>>>
> >>>> What do you think?
> >>>
> >>> I completely agree with this. IP address and DNS identity of the client
> >>> is irrelevant when mTLS is used. What matters is whether the client has
> >>> authority to act as one of the the names given when the filesystem was
> >>> exported (e.g. in /etc/exports). His is exacly what you said.
> >>>
> >>> Ideally it would be more than just the CN. We want to know both the
> >>> domain in which the peer has authority (e.g. example.com) and the type
> >>> of authority (e.g. serve-web-pages or proxy-file-access or
> >>> act-as-neilb).
> >>> I don't know internal details of certificates so I don't know if there
> >>> is some other field that can say "This peer is authorised to proxy file
> >>> access requests for all users in the given domain" or if we need a hack
> >>> like exporting to nfs-client.example.com.
> >>>
> >>> But if the admin has full control of what names to export to, it is
> >>> possible that the distinction doesn't matter. I wouldn't want the
> >>> certificate used to authenticate my web server to have authority to
> >>> access all files on my NFS server just because the same domain name
> >>> applies to both.
> >>
> >> My thought is that, for each handshake, there would be two stages:
> >>
> >> 1. Does the NFS server trust the certificate? This is purely a chain-of-
> >> trust issue, so validating the certificate presented by the client is
> >> the order of the day.
> >>
> >> 2. Does the NFS server authorize this client to access the export? This
> >> is a check very similar to the hostname/netgroup/IP address check
> >> that is done today, but it could be done just once at handshake time.
> >> Match the certificate's fields against a per-export filter.
> >>
> >> I would take tlshd out of the picture for stage 2, and let NFSD make its
> >> own authorization decisions. Because an NFS client might be authorized
> >> to access some exports but not others.
> >>
> >> So:
> >>
> >> How does the server indicate to clients that yes, your cert is trusted,
> >> but no, you are not authorized to access this file system? I guess that
> >> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
> >>
> >> What certificate fields should we implement matches for? CN is obvious.
> >> But what about SAN? Any others? I say start with only CN, but I'd like
> >> to think about ways to make it possible to match against other fields in
> >> the future.
> > Just fyi, here's an example where filtering on the DNS or IP field in the
> > SAN (SubjectAltName) could improve security..
> > (Dusting off my CS sysadmin hat.)
> >
> > Suppose I had a file system where student grades and exam questions
> > were stored.
> > The mount was restricted to faculty offices, where their machines had fixed
> > well known IP addresses and FQDNs assigned.
> > However, as it was for my case, the building their offices were in also had
> > student labs and the building was assigned a subnet by the campus
> > networking folk.
> > --> As such, a student could easily come in off hours (when the faculty were not
> > around and, as such, had their office computers shut down) and
> > plug into the
> > subnet (they just had to find an RJ45 jack somewhere that they
> > could access).
> > --> They could then set their laptop up with the same IP address
> > as a faculty
> > member's office computer and defeat ordinary /etc/exports
> > filtering based
> > on client IP address.
> >
> > However, these students would not have the X.509 cert. with a DNS or IP field
> > set to the correct address in it. (They might have a valid cert. so
> > their laptop can
> > mount the file systems students have coursework assignments on, but it would
> > not have the DNS or IP of a faculty member's office computer.)
> > --> This additional filtering would stop them from accessing the
> > marks/exam question
> > file system (or at least make it a lot harder for them to do so).
> >
> > As already discussed, there is a tradeoff between using DNS or IP. (I'll admit
> > FreeBSD doesn't currently support the IP case, but it probably should.)
>
> To be clear, there is a marked difference between relying on reverse DNS
> queries versus relying on a DNS hostname or IP address contained in a
> client certificate's SAN field. DNS queries are untrustworthy, but
> fields in a certificate (once its trust chain has been validated) are OK
> to use, IMO.
Yes, after sending this (an early morning brain fart;-) I realized I actually
just demonstrated a case where the IP or DNS field matching the client's
host IP address was not useful.
--> For the above example, it only shows that certs. can be differentiated
between student and faculty.
However, having the IP/DNS match work limits the use of a compromised
cert. to the subnet it was meant to be used on.
Or, put another way, if the faculty offices are on a separate subnet from
the student labs, the students would have difficulties using a compromised
cert. before it ends up in a CRL. (Admittedly, for separate subnets, just
filtering on client host IP address as /etc/exports now does can work, as well.)
Another advantage of using client certs is the "identity squashing" case,
where the cert. identifies the user, avoiding any need for Kerberos.
(Then, if the compromised cert. cannot be used outside of the subnet
it was issued for, you are in a better place than if the compromised cert.
can be used from anywhere.)
I do think CRLs should be supported, but it takes a while for someone
to realize a cert. has been compromised and then do what it takes to
get it into a CRL (notifying the sysadmin or ??).
rick
>
> But I would like NFSD's administrative interface to be unambiguous about
> which DNS/IP information is being matched against.
>
>
> > rick
> >
> >>
> >> What would the administrative interface look like? Could be the machine
> >> name in /etc/exports, for instance:
> >>
> >> *,OU="NFS Bake-a-thon",* rw,sec=sys,xprtsec=mtls,fsid=42
> >>
> >> But I worry that will not be flexible enough. A more general filter
> >> mechanism might need something like the ini file format used to create
> >> CSRs.
> >>
> >>
> >> What about pre-shared keys? No certificate fields there.
> >>
> >>
> >> --
> >> Chuck Lever
>
>
> --
> Chuck Lever
