Bez korzystania z NFSv4 z Kerberos, ale używał go w wielu innych miejscach, odwołujesz się do poufności dostarczonej przez GSS-API przez Kerberos, która jest zaimplementowana z gss_wrap(3)/gss_unwrap(3). Zapewnia parametr jakości ochrony, ale jestem pewien, że NFSv4 pozostawi go null => według uznania mechanizmu.
W każdym razie, biorąc pod uwagę, że GSS-API całkowicie usuwa mechanizm, prawdopodobnie nie masz wyboru, ale wciąż możesz coś z tym zrobić. Włącz w swoim KDC co najmniej RC4, w najlepszym razie AES128 i AES256. Implementacje wykorzystają najlepszy dostępny szyfr. Możesz skanować ruch między klientem a TGS (TGS-REQ i TGS-REP), klientem i serwerem (NFS), aby zobaczyć, który rodzaj szyfrowania został wynegocjowany, a to będzie wysoce wykorzystywane do pakowania/rozpakowywania. Zawsze możesz czytać RFC tak jak ja, ale to zajmie dużo czasu, aby zrozumieć.
Mam nadzieję, że to pomoże. Oczywiście mógłbym całkowicie mylić się z wewnętrznymi NFSv4.
Właśnie wykonałem trochę kopania i jestem przekonany, że moja analiza jest prawidłowa. RFC 7530, chapter 3.2.1 mówi o obowiązkowej prywatności Kerberos 5 dla krb5p, a także AES wraz z HMAC-SHA1. Dalsze czytanie prowadzi do RFC 2203 (specyfikacja RPCSEC_GSS), która mówi o gss_wrap/gss_unwrap.
Wyświetl moją zaktualizowaną odpowiedź. –