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 <cnaur...@hortonworks.com> 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.java> > > > https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/ha > doop-common/src/main/java/org/apache/hadoop/security/SaslOutputStream.java > <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" <iv...@apache.org> 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 <f...@apache.org> 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 <iv...@apache.org> 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 <f...@apache.org> > >>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 <iv...@apache.org> 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 <f...@apache.org> > >> 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 <iv...@apache.org> 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 <f...@apache.org> > >> >> 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 > >><cnaur...@hortonworks.com> > >> >>>>>> 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" <f...@apache.org> wrote: > >> >>>>>>> > >> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection) > >>property > >> for > >> >>>>>> SASL > >> >>>>>>>> when running ZooKeeper? > >> >>>>>>>> > >> >>>>>>>> -Flavio > >> >>>>>>> > >> >>>>>> > >> >>>>>> > >> >>>> > >> >>>> > >> >> > >> >> > >> > >> > >
