[
https://issues.apache.org/jira/browse/KAFKA-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446311#comment-17446311
]
Travis Bischel commented on KAFKA-13464:
----------------------------------------
AFAICT this compromises no integrity. I'm not sure the purpose of this final
check. The important part is the client-proof, which hashes the `c-nonce
s-nonce` into it. Sending the c-nonce s-nonce back in plaintext doesn't seem to
provide much benefit.
> 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
> Assignee: Luke Chen
> Priority: Minor
>
> [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)
