Re: [kitten] Question about AES mode in Kerberos

[Olga Kornievskaia <[e-mail]>]

Thank you Greg for all the information. While I can't claim to
understand all the details, I now have a much better understanding of
the AES-GCM's place in the Kerberos world.

On Mon, Jan 9, 2023 at 5:55 PM Greg Hudson <[e-mail]> wrote:
>
> On 1/9/23 15:25, Olga Kornievskaia wrote:
> > May I ask a stupid question? Is there something inherently different
> > about nonce handling/producing in Kerberos that's different from TLS?
>
> The symmetric encryption facilities in TLS are in service only to the
> channel protocol.  TLS is regularly used to carry large amounts of data
> in a variety of application protocols.
>
> The symmetric encryption facilities in Kerberos are in service primarily
> to the stateless authentication protocol, which uses long-term keys.
> Kerberos channel protocols exist (KRB-PRIV and GSS), using the same
> encryption facilities, but they are used less widely than the
> authentication protocol and much less widely than TLS.
>
> It is possible to use different encryption facilities in the gss-krb5
> channel protocol from the ones used in the authentication protocol;
> Luke's work does this and there is historical precedent with older
> encryption types.  But doing so adds complexity, and therefore risk.
>
> > TLS community seems to have chosen AES-GCM as their AES mode and do
> > acknowledge that nonce-reuse would lead to catastrophic failures.
>
> This has not been completely uncontroversial or without consequence.
> Some implementations of GCM in TLS 1.2 have apparently been vulnerable
> to nonce reuse attacks; I found
> https://www.usenix.org/sites/default/files/conference/protected-files/woot16_slides_bock.pdf
> with a quick search.  See also
> https://www.metzdowd.com/pipermail/cryptography/2023-January/038092.html .
>
> > I'm not sure what kind of conclusions I should draw from the
> > statement: "The enctype can't fit within the RFC 3961 framework (I
> > believe) because it requires nonce information from an upper layer."
> > But say NFS wanted AES-GCM it would need to negotiated it with RFC
> > 4537 (support for this is btw I'm not sure is implemented in an MIT
> > library, correct?), but to do so there needs to an IANA enctype for it
> > (like aes128-gcm-hmac-sha256-128, aes256-gcm-hmac-sha384-192) which
> > there isn't one? But there are IANA numbers for AEAD_AES_128_GCM_SIV,
> > AEAD_AES_256_GCM_SIV? Also, you note that mixed different security
> > properties is problematic.
>
> I apologize for the confusion here.  I was not saying that AES-GCM
> couldn't be used within the RFC 3961 framework for lack of a number
> assignment.
>
> RFC 3961 defines a framework for encryption and checksum types for use
> in the Kerberos protocol.  This framework does not include nonce input
> from the upper layer; encryption types using nonces or IVs are expected
> to generate them internally, typically randomly.  AES-GCM is not very
> suitable for use as an RFC 3961 encryption type for this reason.
> AES-GCM-SIV is more suitable, because the enctype could use a random
> nonce and an accidental nonce reuse after many encryptions would not
> compromise the long-term key.
>
> A GSS channel protocol using AES-GCM can be defined outside of the RFC
> 3961 framework.  However, negotiating this protocol using RFC 4537 would
> require a registering an RFC 3961 enctype number corresponding to the
> new channel protocol.  Such a registration carries the risk of
> implementations adding the new enctype within their RFC 3961 libraries
> and accidentally allowing it to be used in the authentication protocol.
> This kind of mistake has happened many times within the security
> software space--every Kerberos implementation has had CVEs resulting
> from the mixture of keyed and unkeyed hashes within the RFC 3961
> checksum registry, and similar problems have resulted from the mixture
> of symmetric and asymmetric signing algorithms in JWT.
>
> It would be possible to use a separate negotiation mechanism (as Luke
> pointed out in his response to my concerns), although that would carry
> its own complexity cost.
>
> > I have no performance claims about AES-GCM over AES-CBC except for
> > what I've read from the web. Statements such as that because each
> > block can be processed individually (in parallel) that it "can" allow
> > for better performance over AES-CBC. I can see that an implementation
> > can code it up serially and then no performance gains will be had.
> > Also, perhaps the performance gains are very small even when
> > implemented in parallel and that would be useful to know.
>
> It is easy to find measurements of maximum AES-GCM speed exceeding
> maximum AES-CBC speed as cryptographic primitives in isolation.  Once
> one adds the encumbrance of a Kerberos application running over a
> network, this difference might disappear into the noise.
>
> > My quest was simply trying to understand why TLS has decided on GCM
> > (which seem to be more performant, according to some) and Kerberos did
> > not. All of this in hopes of improving NFS over Kerberos performance.
>
> There may be a reasonable justification for adopting Luke's AES-GCM work
> on the basis of NFS performance, but in my opinion a lot of footwork is
> required to show that meaningful increased performance is achievable in
> this way.  And even then there is a legitimate question of whether the
> performance benefit for this application is worth the increased
> complexity within Kerberos implementations, and the risk of nonce reuse
> vulnerabilities due to specification or implementation errors.