Re: [kitten] Question about AES mode in Kerberos

[Luke Howard Bentata <[e-mail]>]

> * The motivation appears to be performance, but meaningful performance gains have not been demonstrated in the context of a GSS application.

Agreed. Another motivation could be diversity (using GMAC instead of HMAC-SHA).

> * GCM is a fragile encryption mode; any mistakes in the nonce input would lead to a catastrophic security vulnerability.

True.

> * This work creates an enctype unsuitable for general use, but which would require an entry in the IANA enctypes registry to be negotiable with RFC 4537.  Putting algorithms with very different security properties registered in the same registry has proven to lead to security issues (such as CVE-2010-1324).

True. I suppose this could be avoided by using a distinct negotiation mechanism (e.g. another AD type in the AP-REQ).

> * The enctype can't fit within the RFC 3961 framework (I believe) because it requires nonce information from an upper layer.

True, although this is addressed by draft-howard-krb-aead-00.

> * Microsoft's reason for interest ("something [...] for post-sha256") doesn't seem to match up with a GSS-only enctype.

Not speaking for MS of course, however Windows doesn’t expose RFC3961 APIs, only RFC4121 (via SSPI with the Kerberos and PKU2U SSPs).

> A general-purpose enctype using AES-GCM-SIV (RFC 8452) and random nonces would be a better fit for Kerberos, but I don't see a good reason to specify it unless compelling performance gains can be demonstrated.

Noted.

— Luke

PS. NegoEx does RFC3961 checksums, but that’s not directly relevant here as Kerberos is never negotiated by NegoEx. It should also be safe to use draft-howard-gssapi-aead with a fixed zero nonce for NegoEx checksums, because AFAICT checksum keys are not reused (they are per-mechanism and per-direction). Having said that, the fact this is not straightforward to reason about is an argument in favour of your second and third points.