If a client provides a mechanism that is not enabled (or supported) in the broker, the server rejects the mechanism and returns the set of enabled mechanisms in the error response. I thought Gwen's question was asking how a client would be able to determine what mechanisms are supported in the broker, when support for new mechanisms are added. A version indicator wouldn't really tell you what mechanisms are actually enabled in the broker. You either need a failed SASL handshake as you do now, or we could have server send the list to the client prior to the client choosing its mechanism. I don't know if there a requirement for clients to query mechanisms from the broker, but if there was, it would be better to do so prior to SASL handshake rather than after.
On Mon, Apr 4, 2016 at 9:08 PM, Ismael Juma <ism...@juma.me.uk> wrote: > Rajini, it's a good point that not all mechanisms may be enabled. However, > we can handle that case by rejecting a mechanism requested by the client > without having to initially provide a list of mechanisms right? > > Ismael > > On Mon, Apr 4, 2016 at 8:57 PM, Rajini Sivaram < > rajinisiva...@googlemail.com > > wrote: > > > 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 > > > -- Regards, Rajini
