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. > > 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. One thing you might want to consider as well is the case of compounds not associated with files (such as the initial EXCHANGEID, CREATESESSION). - A naughty client can do a pretty good job of a DOS with those. Right now there is SP4_NONE and SP4_MACH_CRED for Kerberos. I have tried to suggest to the NFSv4 working group that SP4_MACH_CRED should be allowed for the mtls case as well, although I'm not sure it has gained traction. (Something might be buried in David Noveck's security draft. I haven't gotten around to looking at it lately.) rick > > > What about pre-shared keys? No certificate fields there. > > > -- > Chuck Lever
