What's the driving use case behind all this? It's going to have to wait for a release in any case, so why not wait for the next release from trunk, and then use SSL + SASL auth?
On Sun, Oct 11, 2015 at 3:00 AM Andrew Purtell <[email protected]> wrote: > Because different authentication mechanisms can be plugged in and are used > on demand when znodes are accessed according to whatever the ACL specifies, > this is why we opted to tunnel SASL auth within the zookeeper protocol > instead of wrap the entire connection when contributing this feature. SASL > is just one of several possible auth methods that a client might use, even > on a single connection. Of course this is distinctly unconventional, but at > least at the time of contribution was preferred by the community. > > > > On Oct 10, 2015, at 3:53 PM, Chris Nauroth <[email protected]> > wrote: > > > > I filed ZOOKEEPER-2289 to track adding support for the full set of QOP > > settings. I did not target any specific fix version since there isn't > > consensus yet on that. Thank you, Flavio and Ivan. > > > > --Chris Nauroth > > > > > > > > > >> On 10/9/15, 11:55 AM, "Ivan Kelly" <[email protected]> wrote: > >> > >> Just to add, digest-md5 is obselete now[1], due to vulnerability to MITM > >> attacks, so that case would need SSL in any case. > >> > >> krb is still safe though. > >> > >> [1] http://tools.ietf.org/html/rfc6331 > >> > >> On Fri, Oct 9, 2015 at 7:10 PM Chris Nauroth <[email protected]> > >> wrote: > >> > >>> Ivan is right. Thank you! I forgot about this part. > >>> > >>> When QOP is "auth" (the default), then SASL is just a one-time > handshake > >>> at the front of the connection, and the subsequent transfer of bytes > >>> between client and server remain the same. When QOP is "auth-int", > SASL > >>> needs to inspect the transferred bytes for digest-MD5 verification to > >>> guard against man-in-the-middle tampering. When QOP is "auth-conf", > >>> SASL > >>> needs to encrypt the bytes for privacy against a man-in-the-middle. > The > >>> latter two cases require the wrap/unwrap calls that Ivan mentioned. > >>> > >>> In Hadoop, we encapsulate the wrap/unwrap behind special stream > >>> subclasses > >>> that wrap over the underlying "raw" stream. > >>> > >>> > >>> > https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/ > >>> ha > >>> > >>> > doop-common/src/main/java/org/apache/hadoop/security/SaslInputStream.java > >>> > >>> < > https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project > >>> > /hadoop-common/src/main/java/org/apache/hadoop/security/SaslInputStream.j > >>> ava> > >>> > >>> > >>> > >>> > https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/ > >>> ha > >>> > >>> > doop-common/src/main/java/org/apache/hadoop/security/SaslOutputStream.jav > >>> a > >>> > >>> < > https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project > >>> > /hadoop-common/src/main/java/org/apache/hadoop/security/SaslOutputStream. > >>> java> > >>> > >>> > >>> That's nice, because the code consuming the streams doesn't need to > >>> worry > >>> about repeated wrapping and unwrapping. However, even if we set up > >>> something like these classes in ZooKeeper, it appears the ZooKeeper > >>> codebase isn't structured to make inserting those wrappers easy. > >>> > >>> This does look like it would be more invasive than I originally > >>> described. > >>> > >>> --Chris Nauroth > >>> > >>> > >>> > >>> > >>>> On 10/9/15, 7:57 AM, "Ivan Kelly" <[email protected]> wrote: > >>>> > >>>> I think it's a fairly big change, especially since we'd then have a > >>> lot of > >>>> conditional if (sasl) { wrap_bytes } else { dont_wrap }. And then it > >>>> affects all communication between server and client, which is quite > >>> risky. > >>>> > >>>>> On Fri, Oct 9, 2015 at 4:54 PM Flavio Junqueira <[email protected]> > wrote: > >>>>> > >>>>> Ok, got it, but it sounds like we can just wrap and unwrap the bytes > >>> we > >>>>> are sending, no? Do you think that will end up being a lot of > >>> changes? > >>>>> > >>>>> -Flavio > >>>>> > >>>>>> On 09 Oct 2015, at 15:38, Ivan Kelly <[email protected]> wrote: > >>>>>> > >>>>>> To protect the integrity of each packet, each packet needs to be > >>>>> wrapped > >>>>> by > >>>>>> SaslClient/SaslServer (see wrap/unwrap in > >>> > >>> > http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/SaslClient.h > >>>>> tml > >>>>> ). > >>>>>> Currently sasl is only used to initialize the connection, and then > >>> we > >>>>> send > >>>>>> over the raw socket. This changes the lifetime of the sasl > >>>>> components, as > >>>>>> it needs to be used with all communication. It's not like SSL, > >>> where > >>>>> we > >>>>>> negotiate SSL at the start and then the SSL engine provides a > >>> socket > >>>>> which > >>>>>> we use to send data. > >>>>>> > >>>>>> -Ivan > >>>>>> > >>>>>>> On Fri, Oct 9, 2015 at 4:33 PM Flavio Junqueira <[email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> I'm not sure based on what you say that it'd be invasive. Enabling > >>>>>>> different types of QOP seems to be relatively straightforward, > >>> unless > >>>>> I'm > >>>>>>> missing something here. Chris did a good job describing what needs > >>>>> to be > >>>>>>> done, and this far I have the same understanding of the changes. > >>>>>>> > >>>>>>> -Flavio > >>>>>>> > >>>>>>>> On 09 Oct 2015, at 15:30, Ivan Kelly <[email protected]> wrote: > >>>>>>>> > >>>>>>>> IMO, adding QOP to 3.4 would be a fairly large and invasive > >>> change, > >>>>> which > >>>>>>>> is something which shouldn't be done on the stable branch. > >>>>>>>> > >>>>>>>> -Ivan > >>>>>>>> > >>>>>>>> On Fri, Oct 9, 2015 at 4:02 PM Flavio Junqueira <[email protected]> > >>>>> wrote: > >>>>>>>> > >>>>>>>>> Not in the 3.4 branch, which is the latest stable branch at the > >>>>> moment. > >>>>>>>>> > >>>>>>>>> -Flavio > >>>>>>>>> > >>>>>>>>>> On 09 Oct 2015, at 15:00, Ivan Kelly <[email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>> Is auth-int necessary if we have SSL on the client (as there > >>> is in > >>>>>>>>> trunk)? > >>>>>>>>>> My understanding is that all comms would have to be wrapped by > >>>>> sasl > >>>>> if > >>>>>>>>> you > >>>>>>>>>> have QOP enabled. > >>>>>>>>>> > >>>>>>>>>> -Ivan > >>>>>>>>>> > >>>>>>>>>> On Fri, Oct 9, 2015 at 9:42 AM Flavio Junqueira > >>> <[email protected]> > >>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi Chris, > >>>>>>>>>>> > >>>>>>>>>>> Yeah, I was thinking along the same lines, so sounds like a > >>>>> plan. I > >>>>>>> know > >>>>>>>>>>> Raul is going to hate me for this, but I'd really like to have > >>>>> this > >>>>> in > >>>>>>>>>>> 3.4.7. It sounds like a simple enough change that we can have > >>> in > >>>>>>>>> shortly, > >>>>>>>>>>> does it sound right? > >>>>>>>>>>> > >>>>>>>>>>> Please go ahead with the jira if you have time, and if you > >>> don't > >>>>> have > >>>>>>>>> time > >>>>>>>>>>> to work on the patch, just assign it to me. > >>>>>>>>>>> > >>>>>>>>>>> -Flavio > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> On 08 Oct 2015, at 23:16, Chris Nauroth > >>>>> <[email protected]> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Flavio, > >>>>>>>>>>>> > >>>>>>>>>>>> It appears that the current code doesn't give us any way to > >>>>> control > >>>>>>> the > >>>>>>>>>>>> QOP, so it must be always using the default QOP of "auth" > >>>>>>>>> (authentication > >>>>>>>>>>>> only). This is because the calls to Sasl#createSaslClient > >>> and > >>>>>>>>>>>> Sasl#createSaslServer pass a hard-coded null for the > >>> properties > >>>>> map. > >>> > >>> > https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z > >>>>> oo > >>>>>>>>>>>> keeper/client/ZooKeeperSaslClient.java#L240 > >>> > >>> > https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z > >>>>> oo > >>>>>>>>>>>> keeper/client/ZooKeeperSaslClient.java#L288 > >>> > >>> > https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z > >>>>> oo > >>>>>>>>>>>> keeper/server/ZooKeeperSaslServer.java#L118 > >>> > >>> > https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z > >>>>> oo > >>>>>>>>>>>> keeper/server/ZooKeeperSaslServer.java#L144 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> If we want to support setting QOP to "auth-int" > >>> (authentication > >>>>> + > >>>>>>>>>>>> integrity/man-in-the-middle tampering protection) or > >>> "auth-conf" > >>>>>>>>>>>> (authentication + integrity + confidentiality/encryption), > >>> then > >>>>> I > >>>>>>> think > >>>>>>>>>>>> we'll need to make code changes to read a new QOP > >>> configuration > >>>>>>>>> property, > >>>>>>>>>>>> put it into a Map using Sasl#QOP as the key, and then pass it > >>>>> along > >>>>>>> to > >>>>>>>>>>> the > >>>>>>>>>>>> Sasl#createSaslClient and Sasl#createSaslServer calls. > >>>>>>>>>>>> > >>>>>>>>>>>> Is this what you need? If so, then I'd be happy to write up > >>> the > >>>>>>>>> proposal > >>>>>>>>>>>> in a new JIRA. I didn't find any existing open JIRAs that > >>> look > >>>>>>>>> relevant. > >>>>>>>>>>>> > >>>>>>>>>>>> --Chris Nauroth > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 10/8/15, 2:06 PM, "Flavio Junqueira" <[email protected]> > >>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Has anyone tried to use the QOP (Quality of Protection) > >>>>> property > >>>>> for > >>>>>>>>>>> SASL > >>>>>>>>>>>>> when running ZooKeeper? > >>>>>>>>>>>>> > >>>>>>>>>>>>> -Flavio > > >
