[jira] [Created] (KAFKA-13464) SCRAM does not validate client-final-message's nonce

["Travis Bischel (Jira)" <ji...@apache.org>]

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)