[
https://issues.apache.org/jira/browse/KAFKA-17345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Fox updated KAFKA-17345:
----------------------------
Description: (was: 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 returns 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.
According to the RFC, verifying the nonce on the server is *not* optional:
{quote}
The server MUST verify that the nonce sent by the client in the second message
is the same as the one sent by the server in its first message.
{quote}
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.
I believe there is a significant possibility that not checking the nonce makes
current Apache Kafka installations that use SCRAM susceptible to replay
attacks.)
> 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
> Priority: Critical
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
