Re: [kitten] Question about AES mode in Kerberos

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

Hi Olga,

No stupid questions – I’m certainly not a cryptography expert.

The difference vs TLS is that Kerberos has long-term symmetric keys as well as session keys. Care needs to be taken using the former with AES-GCM because nonce reuse breaks the algorithm (and, with random nonces, there is an invocation limit of 2^32 which is a limit not otherwise present in RFC3961). That’s why I chose to disallow so-called “native” AEAD modes with long-term keys (see draft for a definition of “native”).

The draft I wrote is similar to RFC9325 in that it places the GSS-API sequence number in the nonce.

As for why CTS was used instead of GCM in Kerberos, as Jeff points out, it’s because GCM wasn’t around at the time.

Re: GCM-SIV, nothing has been proposed yet.

Cheers,
Luke

> On 10 Jan 2023, at 7:25 am, Olga Kornievskaia <[e-mail]> wrote:
> 
> May I ask a stupid question? Is there something inherently different
> about nonce handling/producing in Kerberos that's different from TLS?
> TLS community seems to have chosen AES-GCM as their AES mode and do
> acknowledge that nonce-reuse would lead to catastrophic failures. I'm
> not familiar with a solution they've chosen to adapt to avoid nonce
> reuse but it seems they are not discouraged from using GCM.
> 
> 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 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.
> 
> For what it's worth, I found this --
> https://calomel.org/aesni_ssl_performance.html -- which is various
> CPU's performance of AES-GCM, AES-CBC, and ChaCha which seem to say
> that AES-GCM is faster?
> 
> 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.
>