You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Travis Bischel (Jira)" <ji...@apache.org> on 2021/11/19 06:35:00 UTC
[jira] [Commented] (KAFKA-13464) SCRAM does not validate client-final-message's nonce
[ 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)