Travis Bischel created KAFKA-13464:
--------------------------------------
Summary: SCRAM does not validate client-final-message's nonce
Key: KAFKA-13464
URL: https://issues.apache.org/jira/browse/KAFKA-13464
Project: Kafka
Issue Type: Bug
Reporter: Travis Bischel
[https://datatracker.ietf.org/doc/html/rfc5802#section-5.1]
Relevant part, in "r="
nonce it initially specified. 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.
[https://github.com/apache/kafka/blob/8a1fcee86e42c8bd1f26309dde8748927109056e/clients/src/main/java/org/apache/kafka/common/security/scram/internals/ScramSaslServer.java#L149-L161]
The only verification of client-final-message is verifyClientProof:
[https://github.com/apache/kafka/blob/8a1fcee86e42c8bd1f26309dde8748927109056e/clients/src/main/java/org/apache/kafka/common/security/scram/internals/ScramSaslServer.java#L225-L235]
This function only looks at the key itself. It does not ensure that the
gs2-header is "biws" (base64("n,,")), meaning the user can erroneously specify
channel binding. This also does not check that the client's nonce is correct
(c-nonce + s-nonce).
While I'm not 100% sure on what security concerns an invalid nonce could result
in _at this stage_ of the auth flow (it's clearer in the first stage w.r.t.
replay attacks), it's likely still important to validate.
I noticed this validation is missing because my own client erroneously replies
with only the original c-nonce, not c-nonce s-nonce. The scram flow has always
worked, though. Today I changed the client-final-reply to always return nonce
"foo", which still successfully talks to Kafka.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
