On Thu, Jun 5, 2025 at 11:11 PM Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: > > On Wed, 4 Jun 2025 at 22:21, Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > > > On Wed, Jun 4, 2025 at 10:36 AM Cedric Blancher > > <cedric.blancher@xxxxxxxxx> wrote: > > > > > > On Mon, 2 Jun 2025 at 02:45, Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > > > > > > > On Sun, Jun 1, 2025 at 3:53 PM Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > > > > > > > > > On Wed, May 21, 2025 at 12:20 AM Lionel Cons <lionelcons1972@xxxxxxxxx> wrote: > > > > > > > > > > > > On Wed, 21 May 2025 at 01:53, Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > If the Google AI is correct, MS does not provide a full > > > > > > > TLS implementation in the kernel and their kTLS only > > > > > > > handles record level encryption/decryption, similar to > > > > > > > FreeBSD. > > > > > > > > > > > > Could you first look into adding TLS support to steved-libtirpc in a > > > > > > generic fashion via openssl, please? > > > > > Ok, I finally got around to doing this. The tarball is attached and it can > > > > > also be found at... > > > > > https://people.freebsd.org/~rmacklem/tirpc-tls.tar > > > > > > How are uid and - more important gid - information passed to the NFS/RPC server? > > Normally, no differently than it is now. Either krb5 or auth_sys. > > RPC-over-TLS encrypts > > the RPC header, but does not change it. > > > > There is a "special case" where a <user@domain> string is set in the otherName > > component of subjectAltName. For that specific case, the NFS server generates > > credentials based on that user (uid+gid list for POSIX servers) and uses those, > > ignoring whatever is in the RPC header (presumably auth_sys with any old uid > > and gid list). > > --> This is entirely an option for an NFS server and really has > > nothing to do with > > NFS-over-TLS except that it is embedded in the client's X.509 > > cert. by whoever > > created it. It is meant for laptops and similar that are only > > used by one user. > > I see a problem here, because <user@domain> is not sufficient. Users > can have multiple primary groups, e.g. in case of /bin/newgrp, Windows > winsg and so on. > > TLS must have a way to specify a primary group for POSIX newgrp(1) support. TLS does not handle user authentication, only machine authentication. The above special case is what Chuck calls "identity squashing" and will only identify a single user at the time of TLS handshake (normally when mounting is done. It does not allow changes to the user after that time and I do not see how it could? (NFS-over-TLS is not meant to replace krb5[ip] or auth_sys, which are still in the RPC message header.) Btw, I'm not sure that things like newgrp are handled by krb5[ip] either. Normally, for "sec=krb5[ip]" a Kerberos credential representing a Kerberos principal is sent to the NFS server. The NFS server translates that Kerberos user principal to a <uid, gid list> at that time and that <uid, gid list> is used for all subsequent RPCs for that principal. --> The only way newgrp would work for Kerberos is if there was a separate user principal in the KDC for each variant of groups list (not practical) or the "group list on the server" is changed every time "newgrp" is done and the client creates a new RPCSEC_GSS shorthand for the user principal via the TGT etc (gss_init_sec_context() etc). I know the FreeBSD NFS client does not do this but I am not sure w.r.t. other ones. Note that, when NFS-over-TLS is used with auth_sys, the server is "trusting" the client's <uid, gid-list> based on the authentication of the client machine's identity. Only for the "special case" where the <user@domain> is in the otherName field of SAN in the client's X.509 cert does it do anything else. Note that I believe this machine authentication is stronger than using client IP host address, which is what traditional exports files do. If it was not clear, X.509 certs do not travel from client->server with every RPC. A cert. is only passed to the server during TLS handshake and even that is optional. --> Put another way, if this does not work for you, you choose not to do it. (Trond has talked about using X.509 certs to authenticate users, but has never described what he thinks could work in any detail.) rick > > Ced > -- > Cedric Blancher <cedric.blancher@xxxxxxxxx> > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur
