Re: [kitten] Question about AES mode in Kerberos

[Greg Hudson <[e-mail]>]

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.