Handle FreeBSD-style user-specific certificates for NFS

[chucklever]

FreeBSD's RPC-with-TLS implementation supports a security policy mechanism that enables an x.509-authenticated client to tell an NFS server to squash all requests within its TLS session to a single specific user ID. The user ID is specified within the subjectAltName field of the client's certificate. We'd like to add that support to ktls-utils and the Linux kernel's RPC client and server.

[g-v-egidy]

I think adding this would be a very good idea. Being able to differentiate access rights for example between several users homedirs is something that is currently missing in linux with TLS-NFS.

The way FreeBSD does it afaik, is you put "username@domain" into the subjectAltName with type otherName:1.3.6.1.4.1.2238.1.1.1;UTF8 of the cert and then "username" is looked up in the passwd (or other user database) and translated to the filesystem UID.

But what happens with groups and their GIDs? Would they be

• kept as the client sends them
• all squashed into the main GID of the user as it is in the passwd on the server
• the list of groups the user is member of on the server looked up and those GIDs whitelisted when sent from the client, all others squashed into the main GID?
• something else?

I'm asking because I have a bunch of directories that are used for sharing files between user groups. I have dedicated GIDs for these and use the setgid mode in the respective directories to have all files automatically regrouped to these GIDs. I would prefer if a solution for this would still allow something like that and keep strict access controls tied to certificates between the groups.

[chucklever]

I think adding this would be a very good idea. Being able to differentiate access rights for example between several users homedirs is something that is currently missing in linux with TLS-NFS.

First, you understand of course that each NFS client uses only one certificate, because certificates here identify a peer host, not a user. So one client can't, say, use multiple certificates, one for each user.

Therefore: for any one client, the server squashes all users on that client to the user identified in the client's certificate.

But what happens with groups and their GIDs?

We'll have to ask Rick how FreeBSD manages group information.

[g-v-egidy]

First, you understand of course that each NFS client uses only one certificate, because certificates here identify a peer host, not a user. So one client can't, say, use multiple certificates, one for each user.

Therefore: for any one client, the server squashes all users on that client to the user identified in the client's certificate.

Yes, I understand this and this is no issue for me.

I should probably have mentioned this in my usecase description. Each user is connected from one or more workstations, and one workstation is only ever used by one user at the same time. The client certificates are loaded into the workstation & decrypted with the pam framework when the user logs in.

But what happens with groups and their GIDs?

We'll have to ask Rick how FreeBSD manages group information.

I didn't see anything documented about GIDs in FreeBSD when skimming their docs.

[rmacklem]

The gid list is created exactly the same way as would be done if the user were to log into the server.

• gid from paaswd database entry for username
• additional gids as specified by the group database
  (More than 17 gids is supported.)

Now, what I did that I am not certain is correct is...

• I only do the identity squash for AUTH_SYS RPCs.
• RPCSEC_GSS RPCs are not squashed.
  Why?
  Well, I'm not sure what is correct for clients that use SP4_MACH_CRED.
  There is also the case where a client uses sec=krb5, but a user does not have a
  valid TGT. Some (most?) clients will fall back on AUTH_SYS for this case and I
  thought that squashing the AUTH_SYS, but not the Kerberos cred (if there is a valid one
  for the user) made sense.
  However, this makes things more confusing than just squashing all RPCs.

Squashing all RPCs should be ok for NFSv4.1/4.2 using SP4_NONE, but what about
NFSv4.0?
I think making a X.509 client cert. represent a machine credential makes sense,
but I'm not sure what has been implemented as yet?
(I'll admit I had forgotten that this was still an outstanding issue.)

[rmacklem]

I should note that I think NFSv4.0 as well as NFSv4.1/4.2 using
SP4_NONE when doing squashing, if the client uses "sec=sys".
The uid all RPCs are squashed to becomes the "machine principal".

However, when a NFSv4.1/4.2 client mixes RPCSEC_GSS and AUTH_SYS,
then it should work for SP4_NONE, but it is not obvious to me if the
RPCSEC_GSS RPCs should be squashed?
Then there is NFSv4.1/4.2 using SP4_MACH_CRED?

[chucklever]

Thanks Rick. I don't have any answers. Sounds like there needs to be some discussion on nfsv4@ietf.org. Maybe even some standards action might be helpful to resolve some of these issues so that clients and servers can interoperate securely.

[g-v-egidy]

The gid list is created exactly the same way as would be done if the user were to log into the server.

* gid from paaswd database entry for username

* additional gids as specified by the group database
  (More than 17 gids is supported.)

Thank you, this is exactly what I wandted to hear.

Squashing all RPCs should be ok for NFSv4.1/4.2 using SP4_NONE, but what about
NFSv4.0?

I'm not really familiar with the way NFS is implemented and the different RPC calls used, so take this with caution:

I'm aware that RPC-over-TLS and the underlying NFS RPCs are different layers. But nonetheless I think you can assume that there are no clients capable of RPC-over-TLS that don't also support NFS 4.2. So from a user perspective I wouldn't see an issue if there is some option in the exports file or config for tlshd on the server that restricts mounts with userid-squashing to NFS 4.2.

[chucklever]

I see a straightforward way to extract the SAN::OtherName content from an incoming certificate and pass it to NFSD. GnuTLS provides an API to extract only that field, and we can introduce a netlink attribute to the DONE command to hand the value part, or even the whole OtherName field, down to the kernel.

See RFC 5280 Section 4.2.1.6.

What I need to know is the OID that will appear as the "type-id", and what the format of the "value" blob looks like. Rick, do you have plans to standardize these items, or any documentation we can follow for the NFSD implementation?

[rmacklem]

On Fri, Jul 11, 2025 at 9:26 AM Chuck Lever ***@***.***> wrote: CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ***@***.*** *chucklever* left a comment (oracle/ktls-utils#43) <#43 (comment)> I see a straightforward way to extract the SAN::OtherName content from an incoming certificate and pass it to NFSD. GnuTLS provides an API to extract only that field, and we can introduce a netlink attribute to the DONE command to hand the value part, or even the whole OtherName field, down to the kernel. See RFC 5280 Section 4.2.1.6 <https://www.rfc-editor.org/rfc/rfc5280.html#section-4.2.1.6>. What I need to know is the OID that will appear as the "type-id", and what the format of the "value" blob looks like. Rick, do you have plans to standardize these items, or any documentation we can follow for the NFSD implementation?

Here's what I have in https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt -tlscertuser requires that the client use TLS and provide a verifiable X.509 certificate. The otherName component of the certificate's subjAltName must have a an OID of 1.3.6.1.4.1.2238.1.1.1 and a UTF8 string of the form ***@***.***". (I suppose the domain should be in puny code if not plain Ascii?) I'm not sure how this would be more standardized. I don't think there is an OID# for NFSv4? The above OID is a FreeBSD one. rick —

…

Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APNAL2VFAJMV6VTKGIFWGCT3H7QTZAVCNFSM6AAAAACBKH3MKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANRSHEZTCMJRG4> . You are receiving this because you commented.Message ID: ***@***.***>

[chucklever]

Here's what I have in
https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt
-tlscertuser requires that the client use TLS and provide a
verifiable X.509 certificate. The otherName component of the
certificate's subjAltName must have a an OID of
1.3.6.1.4.1.2238.1.1.1 and a UTF8 string of the form @.***".
(I suppose the domain should be in puny code if not plain Ascii?)

I'm not sure how this would be more standardized. I don't think there is
an OID# for NFSv4? The above OID is a FreeBSD one.

I don't think this OID would be allocated from an NFSv4-specific arc. Since the OID is part of an x.509 certificate, it probably needs to come from the PKIX arc assigned by IANA, not from the enterprise private arc. At least, someone in authority in this area should be consulted. RFC 7299 says:

The PKIX object identifier arc is:

 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
            dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

The format of the value string also needs to be part of a published standard so implementers don't go sticking any old thing in there. It should follow guidance from Noveck's i18n draft plus whatever requirements there are for iDNA labels that appear in certificates. (ISTR Noveck does address the proper form for internationalized NFSv4 idmap strings).

Thus IMO the feature needs to be run by the NFSv4 and PKIX working groups and IANA, and published as a (very short) RFC to make sure we've followed best practices.

Generally the Linux NFS implementation doesn't add features with interoperability requirements that are not already backed by at least a personal draft.

[rmacklem]

I suspect everything you say is correct. Feel free to do so. (I'm already wishing I had never written the POSIX draft ACL one, so I have no urge to do another.) I can easily make the FreeBSD server recognize a different OID and I agree ***@***.***" should follow whatever RFC8881 says. (I think the domain should have been puny code and not the utf8mixed blah blah, but I don't really care. Everyone just uses a single domain anyhow.) rick

…

On Sun, Jul 13, 2025 at 10:10 AM Chuck Lever ***@***.***> wrote: CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ***@***.*** *chucklever* left a comment (oracle/ktls-utils#43) <#43 (comment)> Here's what I have in https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt -tlscertuser requires that the client use TLS and provide a verifiable X.509 certificate. The otherName component of the certificate's subjAltName must have a an OID of 1.3.6.1.4.1.2238.1.1.1 and a UTF8 string of the form *@*.***". (I suppose the domain should be in puny code if not plain Ascii?) I'm not sure how this would be more standardized. I don't think there is an OID# for NFSv4? The above OID is a FreeBSD one. I don't think this OID would be allocated from an NFSv4-specific arc. Since the OID is part of an x.509 certificate, it probably needs to come from the PKIX arc assigned by IANA, not from the enterprise private arc. At least, someone in authority in this area should be consulted. RFC 7299 says: The PKIX object identifier arc is: id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } The format of the value string also needs to be part of a published standard so implementers don't go sticking any old thing in there. It should follow guidance from Noveck's i18n draft plus whatever requirements there are for iDNA labels that appear in certificates. (ISTR Noveck does address the proper form for internationalized NFSv4 idmap strings). Thus IMO the feature needs to be run by the NFSv4 and PKIX working groups and IANA, and published as a (very short) RFC to make sure we've followed best practices. Generally the Linux NFS implementation doesn't add features with interoperability requirements that are not already backed by at least a personal draft. — Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APNAL2XYEUEFUSMHIYMH4V33IKHITAVCNFSM6AAAAACBKH3MKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANRXGE3TGMJUGI> . You are receiving this because you commented.Message ID: ***@***.***>