Без использования NFSv4 с Kerberos, но используется во многих других местах, вы имеете в виду конфиденциальность, предоставляемую GSS-API через Kerberos, которая реализована с помощью gss_wrap(3)/gss_unwrap(3). Он обеспечивает качество параметра защиты, но я вполне уверен, что NFSv4 оставит его null => по усмотрению механизма.
В любом случае, учитывая, что GSS-API полностью абстрагируется от механизма, у вас, вероятно, нет выбора, но вы все еще можете что-то сделать. Включите в своем KDC как минимум RC4, в лучшем случае AES128 и AES256. Реализации будут использовать наилучший доступный шифр. Вы можете сканировать трафик между клиентом и TGS (TGS-REQ и TGS-REP), клиентом и сервером (NFS), чтобы узнать, какой тип шифрования был согласован, и это будет очень полезно для упаковки/разворачивания. Вы всегда можете прочитать RFC, как я, но это займет много времени, чтобы понять.
Надеюсь, это поможет. Конечно, я мог ошибаться в отношении внутренних компонентов NFSv4.
Только что сделал рытье, и теперь я уверен, что мой анализ верен. RFC 7530, chapter 3.2.1 рассказывает о конфиденциальности Kerberos 5 для krb5p, а также AES вместе с HMAC-SHA1. Дальнейшее чтение приводит к RFC 2203 (спецификация RPCSEC_GSS), которая рассказывает о gss_wrap/gss_unwrap.
См. Мой обновленный ответ. –