zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: QOP SASL property
Date Sun, 11 Oct 2015 00:59:40 GMT
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 <cnauroth@hortonworks.com> 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" <ivank@apache.org> 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 <cnauroth@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.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" <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