On 5/31/2023 4:08 PM, David Howells wrote:
Fair point. In rxgk, I use key_len, key_bytes, block_len, cksum_len plus the name for procfs purposes. I also wonder if I need separate key_len and key_bytes if I'm not supporting DES (DES keys gets expanded IIRC). Also, some of the checks I'm doing could perhaps be moved into the krb5 lib.
The "K" in RXGK is RFC3961 without support for weak ciphers. No DES, no 3DES
and no RC4-HMAC. DES keys are never expanded. The supported ciphers are * aes128-cts-hmac-sha1-96 (RFC3962) * aes256-cts-hmac-sha1-96 (RFC3962) * aes128-cts-hmac-sha256-128 (RFC8009) * aes256-cts-hmac-sha384-192 (RFC8009)There are other Kerberos ciphers that could be used with RXGK but there are no RXGK server implementations that use them. None of the RFC3961 ciphers or the RFC3961 interfaces support AEAD modes.
Luke Howard proposed "AEAD Encryption Types for Kerberos 5" https://datatracker.ietf.org/doc/draft-howard-krb-aead/ to IETF Kitten which would add AES128 and AES256 GCM, CCM, and OCB modes. However, there is some resistance to these additions because at the moment all RFC3961 ciphers are safe for use with long term keys and repeating cipher state; AEAD modes are not.
RXGK can be constrained such that it is safe for use with AEAD modes and I would like to see Luke's draft be adopted if only because CTS-HMAC is not supported by Intel QAT and GCM is. Adoption of Luke's draft would not only benefit AuriStorFS but NFSv4 gss-krb5 as well.
My suggestion is that the kernel should provide an RFC3961 API for use by gss_krb5 applications. AEAD modes can be added to that if and when Luke's draft is adopted.
Jeffrey Altman
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
