Tim Fox created KAFKA-17345:
-------------------------------
Summary: Client nonce is not checked during SASL-SCRAM-256
authentication
Key: KAFKA-17345
URL: https://issues.apache.org/jira/browse/KAFKA-17345
Project: Kafka
Issue Type: Bug
Components: security
Affects Versions: 3.8.0
Reporter: Tim Fox
It appears that the SCRAM server side implementation in Apache Kafka is not
checking that the nonce sent during the second request from the client during
authentication using SASL-SCRAM-256 is the same as the nonce returned from the
server in the first response from the server.
SCRAM RFC is here [https://datatracker.ietf.org/doc/html/rfc5802]
The part of the RFC that says the client should return the same response that
it received from the server is here:
{quote}The client then responds by sending a "client-final-message" with the
*same nonce* and a ClientProof computed using the selected hash function as
explained earlier.
{quote}
Here's the part of the RFC saying to check nonces:
{quote}The server *{_}verifies the nonce*{_} and the proof, verifies that the
authorization identity (if supplied by the client in the first
message) is authorized to act as the authentication identity, and, finally, it
responds with a "server-final-message", concluding the authentication exchange.
{quote}
It appears that latest Apache Kafka _does not_ verify the nonces are the same,
contrary to the RFC. I.e.
[https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/scram/internals/ScramSaslServer.java#L152]
- i.e. there is no check on the nonce.
I stumbled upon this while creating a Kafka compatible server in golang and
using the xdg golang library - which is known to be strictly RFC compliant.
[https://github.com/xdg-go/scram]
This implementation *does* check that the nonce sent from the client in the
second request is the same as the one returned from the server in the first
request, and this results in an authentication failure when using it with a
librdkafka client as it appears that librdkafka *does not* send the same nonce
it received from the server in the second request. I have filed a related issue
with librdkafka to cover that:
[https://github.com/confluentinc/librdkafka/issues/4814]
In summary, this means, that a client (for example librdkafka) which sends an
incorrect nonce in the second request of SASL-SCRAM-256 authentication
(contrary to the RFC) can still pass authentication with Apache Kafka.
I am not a security expert and I do not know if this enables an exploit or
vulnerability in Apache Kafka, but I have filed this as critical to be on the
safe so you can take a closer look.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
