[
https://issues.apache.org/jira/browse/KAFKA-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16274241#comment-16274241
]
Tom Bentley commented on KAFKA-6272:
------------------------------------
To fix this we would have to apply SASLPrep to usernames and password for SASL
Plain and SCRAM. Doing that could deny authentication to existing users because:
1. SASLPrep-ing the password before computing client proof (in the SASL client)
will mean the client produces a different proof when the output of SASLPrep
differs from the input. Using an upgraded broker it insufficient because the
password hashes in ZooKeeper will have been computed using unprepped passwords.
2. Likewise, if a new user account is added (which preps the password) then an
old client won't authenticate.
To address this we would need to change how the passwords were stored in
zookeeper to include two hashes -- one computed from a prepped password and
another from an unprepped passwork. We could then use the version of the
APIVERSION request from the client to determine which stored hash to use when
performing SASL SCRAM authentication.
At some time in the future, when we no longer support clients which don't do
the SASLpreping we would stop needing both kinds of hash in ZooKeeper.
All of which is basically a long-winded way of saying this will require a KIP.
> SASL PLAIN and SCRAM do not apply SASLPrep
> ------------------------------------------
>
> Key: KAFKA-6272
> URL: https://issues.apache.org/jira/browse/KAFKA-6272
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 1.0.0
> Reporter: Tom Bentley
> Assignee: Tom Bentley
> Priority: Minor
>
> [RFC 5802|https://tools.ietf.org/html/rfc5802] (SASL SCRAM) says:
> {quote}
> Before sending the username to the server, the client SHOULD
> prepare the username using the "SASLprep" profile [RFC4013] of
> the "stringprep" algorithm [RFC3454] treating it as a query
> string (i.e., unassigned Unicode code points are allowed).
> {quote}
> ScramSaslClient uses ScramFormatter.normalize(), which just UTF-8 encodes the
> bytes.
> Likewise [RFC 4616|https://tools.ietf.org/html/rfc4616] (SASL PLAIN) says:
> {quote}
> The presented authentication identity and password strings, as well
> as the database authentication identity and password strings, are to
> be prepared before being used in the verification process. The
> [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
> preparation algorithm. The SASLprep preparation algorithm is recommended to
> improve the likelihood that comparisons behave in an expected manner. The
> SASLprep preparation algorithm is not mandatory so as to allow the server to
> employ other preparation algorithms (including none) when appropriate. For
> instance, use of a different preparation algorithm may be necessary for the
> server to interoperate with an external system.
> {quote}
> But the comparison is simply on the bare strings.
> This doesn't cause problems with the SASL components distributed with Kafka
> (because they consistently don't do any string preparation), but it makes it
> harder to, for, example, use the Kafka {{SaslClients}} on clients, but
> configure a different {{SaslServer}} on brokers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
