Tom Bentley created KAFKA-6272:
----------------------------------
Summary: 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 {{SaslClient}}s on clients, but
configure a different {{SaslServer}} on brokers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
