Without using NFSv4 with Kerberos, but using it in many other places, you mean the privacy provided by the GSS-API through Kerberos, which is implemented using gss_wrap(3)/gss_unwrap(3) . It ensures the quality of the protection parameter, but I am pretty sure that NFSv4 will leave it null => at the discretion of the mechanism.
In any case, given that the GSS-API is completely abstracted from the mechanism, you probably have no choice, but you can still do something. Include at least RC4 in your KDC, at best AES128 and AES256. Implementations will use the best available cipher. You can scan the traffic between the client and TGS ( TGS-REQ and TGS-REP ), the client and server ( NFS ) to find out what type of encryption has been negotiated, and this will be very useful for packaging / deployment. You can always read the RFC like me, but it will take a long time to understand.
Hope this helps. Of course, I could completely make a mistake in the internal functions of NFSv4.
Just did a digging, and now I'm sure my analysis is correct. RFC 7530, chapter 3.2.1 talks about the mandatory confidentiality of Kerberos 5 for krb5p , as well as AES along with HMAC-SHA1. Further reading leads to RFC 2203 (specification RPCSEC_GSS), which refers to gss_wrap/gss_unwrap .