[jira] [Commented] (KAFKA-17345) Client nonce is not checked during SASL-SCRAM-256 authentication

["Tim Fox (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-17345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874144#comment-17874144 ] 

Tim Fox commented on KAFKA-17345:
---------------------------------

Adding a bit more information:

* I think the fix should be straightfoward - ScramSaslServer needs to keep track of the nonce sent back in response 1 and verify that it's the same as the none received in request 2. Here's the equivalent check in xdg-go [https://github.com/xdg-go/scram/blob/master/server_conv.go#L129]
* Fixing this will break librdkafka - as librdkafka currently sends an incorrect nonce in request 2. So any fix will need to co-ordinate with that team to avoid breaking user apps.
* The Kafka Java client looks at first glance to be sending the correct nonce, so should not break. (Needs to be verified).

> 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
>
> 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)