You misunderstood. The problem is not forwarding Kerberos tokens, the problem is obtaining Kerberos tokens. Unless some extensions are employed, you need to use password authentication. Even if kerberos extensions are employed, you must still use kerberos auth instead of ssh public keys. If you try to use ssh public key authentication (instead of telling ssh to use kerberos authentication) you can't log-in to the machine because you can't access your home filesystem, which is kerberised. In fact, depending on your configuration, you might not be able to log-in at all since the user's filesystem might not be mounted at all (waiting for the automounter).
If you want to store user directories on kerberized NFS, users must use kerberos authentication.
Kerberos actually operates on keys. The nfs service key is typically a random one stashed in the keytab.
I don't understand the objection to Kerberos tickets -- it's a single-sign-on system. You can obtain a ticket with a public key if you want, see e.g. http://www.h5l.org/manual/HEAD/info/heimdal/Setting-up-PK_00...
I don't know how easy it aould be to use SSH keys, but I once designed an authentication system for a scientific facility that was based on PGP keys and a web of trust reflecting administrative/social structures in the days before things like Eduroam and (viable?) NFS4, but not before AFS, which has been successfully used in the same way for a long time.
I don't know why anyone would think "Kerberized" wouldn't involve Kerberos, but it's nothing specific to user directories.
OrangeFS (nee PVFS) is a userland parallel filesystem (with a kernel driver in Linux) that can use two types of public key security if you want that sort of thing, but I gather that's not widely used.
NFS tends to be living in the kernel, which sounds like a terrible place for TLS. That said, IPSec lives in the kernel to some extent, you could layer NFS on top of ipsec....
Netflix's TLS support is an extremely limited hack that suits their performance needs. It does not support initial session negotiation or rekeying. They do the former in userspace before handing off a symmetric key to the kernel, and drop connections in the latter case, relying on the client to reconnect. There's no chance it will be merged to FreeBSD; it's not a general solution.
As long as we're talking about TLS and IPSec, though, I'd point to Wireguard as maybe something viable for kernel use.
