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 >
