zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Re: QOP SASL property
Date Fri, 09 Oct 2015 17:10:21 GMT
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/ha
doop-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" <ivank@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 <fpj@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 <ivank@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 <fpj@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 <ivank@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 <fpj@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 <ivank@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 <fpj@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
>><cnauroth@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" <fpj@apache.org>
wrote:
>> >>>>>>>
>> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
>>property
>> for
>> >>>>>> SASL
>> >>>>>>>> when running ZooKeeper?
>> >>>>>>>>
>> >>>>>>>> -Flavio
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>


Mime
View raw message