SCRAM does not validate client-final-message's nonce

[twmb]

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/vectorizedio/redpanda/blob/b47889b51497e4e7c39b3adf8daef0e1d816f133/src/v/security/scram_authenticator.cc#L73-L75

This function only looks at the stored key, not the client's c= nor r= parameters.

This function only looks at the key itself. It does not ensure that the channel-binding (c=) 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.

Also ref: KAFKA-13464.

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 Redpanda.

JIRA Link: CORE-786