SASL mechanisms are configurable properties and slightly different from versions since the fact that a broker version *can* support a mechanism doesn't actually mean that a broker *does* support that mechanism. SASL implementations typically interact with external authentication servers, so I would expect many Kafka brokers to enable a only subset of mechanisms supported in a particular broker version. We don't enable Kerberos because we don't have a Kerberos authentication server.
KIP-43 originally contained a mechanism negotiation phase where the broker sent the list of supported mechanisms to the client before SASL handshake to enable client to choose an enabled mechanism. This was removed after feedback from the community as being unnecessary. Wouldn't it be better to reinstate that part of the handshake if we want clients to be able to determine mechanisms enabled in the broker? It may be better than a version indicator in the Kafka protocol that cannot be obtained until the handshake completes. On Mon, Apr 4, 2016 at 8:41 PM, Magnus Edenhill <mag...@edenhill.se> wrote: > As Jun says the SASL (and SSL) handshake is not done using the Kafka > protocol > and is performed before any Kafka protocol requests pass between client and > server. > > It might make sense to move the SASL handshake from its custom protocol > format > into the Kafka protocol and make it use the proper Kafka protocol framing. > > (For SSL this is isnt needed since TLS has its own _standardised_ > hand-shake format and existing SSL implementations take care of it.) > > 2016-04-04 21:20 GMT+02:00 Ismael Juma <ism...@juma.me.uk>: > > > An option would be to add a version for the handshake in the KIP-35 > > response. > > > > Ismael > > On 4 Apr 2016 20:09, "Gwen Shapira" <g...@confluent.io> wrote: > > > > > I think the challenge here is that even after KIP-35 clients will not > > know > > > whether the server supports new sasl mechanisms or not, so non-Java > > clients > > > will have to assume it is not supported (and will therefore lag behind > on > > > features). > > > > > > I think this highlights a short-coming of KIP-35, and I'm wondering if > > > there are good ways to address this. > > > > > > Gwen > > > > > > > > > On Mon, Apr 4, 2016 at 12:05 PM, Jun Rao <j...@confluent.io> wrote: > > > > > > > I think with KIP-43, the existing way of sasl handshake during > > connection > > > > still works. It's just that if you want to support non-GSSAPI, you > will > > > > need a new sasl handshake implementation in the client. It's > > unfortunate > > > > that Protocol currently only covers the communication after the > > > connection > > > > is ready to use, but not during handshake. For now, we can probably > > just > > > > document this change during handshake since changing the > implementation > > > is > > > > optional. > > > > > > > > Thanks, > > > > > > > > Jun > > > > > > > > On Mon, Apr 4, 2016 at 11:28 AM, Gwen Shapira <g...@confluent.io> > > wrote: > > > > > > > > > Hi Kafka Team, > > > > > > > > > > As a practical test-case of KIP-35, I'd like to turn your attention > > to > > > > > KIP-43: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-43 > > > > > > > > > > KIP-43 makes an interesting modification to the protocol, but only > > > under > > > > > specific conditions: > > > > > > > > > > "*Client flow:* > > > > > > > > > > 1. If sasl.mechanism is not GSSAPI, send a packet with the > > mechanism > > > > > name to the server. Otherwise go to Step 3. > > > > > - Packet Format: | Version (Int16) | Mechanism (String) | > > > > > 2. Wait for response from the server. If the error code in the > > > > response > > > > > is non-zero, indicating failure, report the error and fail > > > > > authentication. > > > > > 3. Perform SASL authentication with the configured client > > mechanism > > > > > > > > > > *Server flow:* > > > > > > > > > > 1. Wait for first authentication packet from client > > > > > 2. If this packet is a not valid mechanism request, go to Step 4 > > and > > > > > process this packet as the first GSSAPI client token > > > > > 3. If the client mechanism received in Step 2 is enabled in the > > > > broker, > > > > > send a response with error code zero and start authentication > > using > > > > the > > > > > specified mechanism. Otherwise, send an error response including > > the > > > > > list > > > > > of enabled mechanisms and fail authentication. > > > > > - Packet Format: | ErrorCode (Int16) | EnabledMechanisms > > > > > (ArrayOf(String)) > > > > > | > > > > > 4. Perform SASL authentication with the selected mechanism. If > > > > mechanism > > > > > exchange was skipped, process the initial packet that was > received > > > > from > > > > > the > > > > > client first." > > > > > > > > > > > > > > > I'd love to know how this will be communicated to clients via > > > > > VersionRequest proposed in KIP-35 (mostly because Jun and I need to > > > > review > > > > > KIP-43 and we want to be sure we are not breaking the new protocol > at > > > the > > > > > same time we introduce it) > > > > > > > > > > Do we: > > > > > 1. Bump protocol version of every single Request? Even though > unless > > > you > > > > > are using a new sasl mechanism nothing changes? > > > > > 2. Ignore and not bump protocol? If so, how will clients know that > > new > > > > > sasl.mechanisms are supported? > > > > > 3. Something else? > > > > > > > > > > Gwen > > > > > > > > > > > > > > > -- Regards, Rajini
