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

[Rick Macklem <[e-mail]>]

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]