You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Luke Chen (Jira)" <ji...@apache.org> on 2021/11/19 01:55:00 UTC

[jira] [Assigned] (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:all-tabpanel ]

Luke Chen reassigned KAFKA-13464:
---------------------------------

    Assignee: Luke Chen

> 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)