Re: [PATCH 00/18] Migrate rpcsec_gss_krb5 to the crypto/krb5 library
From: Anna Schumaker
Date: Wed May 20 2026 - 18:28:18 EST
Hi Chuck,
On Wed, Apr 29, 2026, at 11:17 AM, Chuck Lever wrote:
> On Wed, Apr 29, 2026, at 2:39 AM, Jeff Layton wrote:
>> On Mon, 2026-04-27 at 09:50 -0400, Chuck Lever wrote:
>>> The rpcsec_gss_krb5 module carries its own Kerberos 5 crypto imple-
>>> mentation: key derivation, CBC-CTS encryption, HMAC checksumming,
>>> and the encrypt-then-MAC construction from RFC 8009. Keeping
>>> cryptographic code inside an RPC module means it receives review
>>> only from the SUNRPC maintainers, who lack deep crypto expertise.
>>> Vulnerabilities and algorithmic errors can persist unnoticed.
>>>
>>> Replacing the private SunRPC Kerberos implementation eliminates
>>> this duplicated audit surface. A single implementation of Kerberos
>>> 5 key derivation and authenticated encryption is easier to verify
>>> than two independent copies. New encryption types and hardware
>>> offload added to crypto/krb5 will automatically become available
>>> to SunRPC Kerberos consumers.
>>>
>>> The crypto/krb5 library handles enctype differences internally, so
>>> a single encrypt function and a single decrypt function serve all
>>> enctypes, eliminating the per-enctype dispatch table that previously
>>> existed in struct gss_krb5_enctype.
>>>
>>> RFC 4121 Section 4.2.4 requires MIC checksums to cover the message
>>> body followed by the GSS token header. The crypto/krb5 get_mic/
>>> verify_mic API hashes optional metadata before the scatterlist
>>> data, which is the wrong order for the GSS header. The header is
>>> therefore placed at the end of the scatterlist rather than passed
>>> as the metadata parameter, and a dedicated gss_krb5_mic_build_sg()
>>> helper constructs this three-section layout (checksum area, message
>>> body, token header) with proper sg_mark_end() termination.
>>>
>>> This implementation was available during the Spring 2026 NFS bake-
>>> a-thon, and received testing there.
>
>>
>> Love that diffstat. Nice work!
>>
>> One comment in general: Do you need to add Assisted-by: tags to any of
>> this? You can add this to the set:
>>
>> Reviewed-by: Jeff Layton <jlayton@xxxxxxxxxx>
>
> Thanks, applied to nfsd-testing. An Acked-by: from one of the NFS
> client maintainers would be great too.
I finally had a chance to apply this and try it out. You can add my acked-by:
Acked-by: Anna Schumaker <anna.schumaker@xxxxxxxxxxxxxxx>
>
>
> --
> Chuck Lever