...

Current state: Under Discussion

Discussion thread: TODO here

JIRA: TODO

Motivation

KIP-84 introduced support SASL/SCRAM with the ability to persist configuration in Zookeeper. KIP-554 extended this feature to KRaft by introducing MetadataRecords to store SCRAM configuration in KRaft logs.

KIP-554 doesn't allow the ability to describe salt, stored_key and server_key fields using the --describe flag in kafka-configs.sh due to security concerns. This makes it hard to migrate SCRAM credentials from one cluster to another, unlike its Zookeeper counterpart where the znode contents can be copied over easily. The absence of such an option prevents cluster migrations without requiring users to re-configure their passwords in the new cluster, which is a non-trivial operation for large multi-tenant clusters. The ability to safely synchronise credentials across multiple clusters is also useful in scenarios where client identities are common across different clusters as this reduces toil for end users.

This KIP therefore proposes the ability to describe the aforementioned fields in a secure way, providing Kafka cluster operators the ability to export and import SCRAM credentials.

...

We propose encrypting stored_key and server_key using AES-GCM-256 with a random 12 byte nonce.

To avoid nonce reuse attacks, we propose deriving a key for each user by using HKDFExpand (RFC 5869) with SHA256 as the hash function and contents of sasl.scram.encryption.key as PRK, DescribeUserScramCredentials={user=<username>,purpose=stored_key} or DescribeUserScramCredentials={user=<username>,purpose=server_key} as the info and 32 as length parameter. The implementation's pseudocode is therefore:

...

As alluded in the mailing list discussion for KIP-554 and RFC5802§9, there are security concerns for exposing the triple (salt, num_iterations, stored_key/server_key) over AdminAPI as that may allow a passive adversary to perform an offline dictionary attack. Additionally, it may allow a passive adversary to impersonate the server.

We therefore encrypt the stored_key and server_key fields. This is safe as the key is assumed to be only in control of the cluster operators who already have access to the KRaft logs and therefore the SCRAM configurations.

...