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)