Re: [nfsv4] Comments on minutes of wg meeting at IETF114

[David Noveck <[e-mail]>]

Thanks for the clarification.

Have you been following the discussion of internationalized domain names?
Chuck has helpfully provided information, relayed from the Solaris team,
about how this is dealt by the Solaris client and server.  I am hoping to
get some testing results from the Linux client and server and the Ontap
server.

It would help, to round out the picture, to know how the freebsd client and
server deal with internationalized domain names that contain, for example,
umlauts.

On Tue, Sep 13, 2022, 10:10 PM Rick Macklem <[e-mail]> wrote:

> Chuck Lever III wrote:
> >David Noveck wrote:
> [stuff snipped to just comments related to FreeBSD/me]
>
> >>Let me give people some background.  Chuck objected to the treatment
> >>of SECINFO in some earlier security-0x draft.  He thought it was to
> >>complicated so we agreed that he would publish his approach, as he did
> >>in rpc- tls-pseudoflavors and I  would refer to that in the next security
> draft.
> >>
> >>Now it appears that Chuck has changed his mind and I'd appreciate
> >>knowing why<http://why.ch/>.
> >
> >Rick told me he is not going to implement it.
> This statement sounds somewhat misleading, although true.
> I do not see the FreeBSD client implementing pseudo-flavors
> because it does not use Secinfo/SecinfoNoName and I doubt
> it ever will.
> --> It just considers NFS4ERR_WRONGSEC to be a fatal error
>       that it maps to EACCES.
>
> The FreeBSD NFSv4 server could easily implement pseudo-flavors.
> I was just waiting to see if there was a consensus that it was
> the correct way to go.  I'll admit I do not see that consensus
> at this time.
>
> > Trond stated that the proposed mechanism is a hack, which I take to mean
> > he will not accept it in the Linux client.
> It would be nice to find out what he thinks is appropriate?
>
> [more stuff snipped]
> >Rick says he plans to implement a simple rejection of RPCs when a
> server’s >security policy does not permit AUTH_SYS without TLS, using
> existing RPC >or upper layer status code. The client can decide to retry
> with TLS (why was >it not defaulting to TLS in the first place?) or let
> such requests fail.
> The current FreeBSD NFSv4 server implementation includes two per
> file system export restrictions:
> - The client must use RPC-over-TLS.
> - The client must use RPC-over-TLS and provide a X.509 certificate
>   that verifies during TLS handshake.
>
> For both of the above cases, if the client does not satisfy the
> requirement,
> NFS4ERR_WRONGSEC is replied. This was anticipating that there would
> be pseudo-flavors for Secinfo/SecinfoNoname that the client (not the
> FreeBSD one) could use to determine why NFS4ERR_WRONGSEC was
> replied.
> --> This can easily be changed since the only RPC-over-TLS client
>       currently shipping (FreeBSD) does not depend on this error.
>
> >That seems like a sensible implementation to me.  However, it is not
> >complete and does not address the fundamental problem, that rpc-with-tls
> >makes SECINFO, as defined in RFCs 7530 and 8881 essentially useless.  It
> >was built when Auth flavors alone defined security capabilities and that
> is >no longer the case 😀.
> >
> >I’d like Rick to write a brief description of his idea.
> As above, I was anticipating implementation of pseudo-flavors in the
> FreeBSD server and see no problem with them.
>
> It just so happens, the FreeBSD client does not find Secinfo useful,
> but that is just one case (which could change some day).  It is
> mostly an implementation issue, where there is no way to easily
> keep track of "per server file system" semantics in the NFSv4 client.
> (They are either "per file" or "per mount".)
>
> >I think I  am getting the implementation idea.  We have to reach a
> >consensus on the future of SECINFO.  I hope nobody objects to augmenting
> >it with pseudoflavors because I object strongly to leaving it almost
> useless >and explaining that in rfc5661bis.
> >
> >Rick and Trond have already rejected the use of pseudoflavors.
> W.r.t. Rick, not exactly, as above.
>
> >Please explain what you mean by "leaving SECINFO useless". If a SECINFO
> >response lists AUTH_SYS and the server rejects a subsequent unprotected
> >AUTH_SYS request with AUTH_TOO_WEAK, the client can retry with >AUTH_SYS
> on a protected transport. If it doesn't have RPC-with-TLS >available, the
> unprotected request fails.
> At this time the FreeBSD server replies NFS4ERR_WRONGSEC for NFSv4
> and AUTH_TOO_WEAK for NFSv3 but, as noted above, that can easily
> be changed.
>
> rick
> [more stuff snipped]
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>