You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Flavio Junqueira <fp...@apache.org> on 2015/10/08 23:06:55 UTC
QOP SASL property
Has anyone tried to use the QOP (Quality of Protection) property for SASL when running ZooKeeper?
-Flavio
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <an...@gmail.com>
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 <cn...@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" <iv...@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 <cn...@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" <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 <fp...@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 <fp...@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 <fp...@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
> >>> <fp...@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
> >>>>> <cn...@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" <fp...@apache.org>
> >>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
> >>>>> property
> >>>>> for
> >>>>>>>>>>> SASL
> >>>>>>>>>>>>> when running ZooKeeper?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Flavio
> >
>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <an...@gmail.com>
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 <cn...@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" <iv...@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 <cn...@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" <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 <fp...@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 <fp...@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 <fp...@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
> >>> <fp...@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
> >>>>> <cn...@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" <fp...@apache.org>
> >>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
> >>>>> property
> >>>>> for
> >>>>>>>>>>> SASL
> >>>>>>>>>>>>> when running ZooKeeper?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Flavio
> >
>
Re: QOP SASL property
Posted by Andrew Purtell <an...@gmail.com>.
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 <cn...@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" <iv...@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 <cn...@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" <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 <fp...@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 <fp...@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 <fp...@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
>>> <fp...@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
>>>>> <cn...@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" <fp...@apache.org>
>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
>>>>> property
>>>>> for
>>>>>>>>>>> SASL
>>>>>>>>>>>>> when running ZooKeeper?
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Flavio
>
Re: QOP SASL property
Posted by Andrew Purtell <an...@gmail.com>.
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 <cn...@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" <iv...@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 <cn...@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" <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 <fp...@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 <fp...@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 <fp...@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
>>> <fp...@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
>>>>> <cn...@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" <fp...@apache.org>
>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
>>>>> property
>>>>> for
>>>>>>>>>>> SASL
>>>>>>>>>>>>> when running ZooKeeper?
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Flavio
>
Re: QOP SASL property
Posted by Chris Nauroth <cn...@hortonworks.com>.
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" <iv...@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 <cn...@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" <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 <fp...@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 <fp...@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 <fp...@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
>><fp...@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
>> >><cn...@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" <fp...@apache.org>
>>wrote:
>> >> >>>>>>>
>> >> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
>> >>property
>> >> for
>> >> >>>>>> SASL
>> >> >>>>>>>> when running ZooKeeper?
>> >> >>>>>>>>
>> >> >>>>>>>> -Flavio
>> >> >>>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>
>> >> >>>>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>
Re: QOP SASL property
Posted by Chris Nauroth <cn...@hortonworks.com>.
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" <iv...@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 <cn...@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" <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 <fp...@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 <fp...@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 <fp...@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
>><fp...@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
>> >><cn...@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" <fp...@apache.org>
>>wrote:
>> >> >>>>>>>
>> >> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
>> >>property
>> >> for
>> >> >>>>>> SASL
>> >> >>>>>>>> when running ZooKeeper?
>> >> >>>>>>>>
>> >> >>>>>>>> -Flavio
>> >> >>>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>
>> >> >>>>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <cn...@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 <fp...@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 <fp...@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 <fp...@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 <fp...@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
> >><cn...@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" <fp...@apache.org> wrote:
> >> >>>>>>>
> >> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
> >>property
> >> for
> >> >>>>>> SASL
> >> >>>>>>>> when running ZooKeeper?
> >> >>>>>>>>
> >> >>>>>>>> -Flavio
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>>
> >> >>
> >> >>
> >>
> >>
>
>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <cn...@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 <fp...@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 <fp...@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 <fp...@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 <fp...@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
> >><cn...@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" <fp...@apache.org> wrote:
> >> >>>>>>>
> >> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
> >>property
> >> for
> >> >>>>>> SASL
> >> >>>>>>>> when running ZooKeeper?
> >> >>>>>>>>
> >> >>>>>>>> -Flavio
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>>
> >> >>
> >> >>
> >>
> >>
>
>
Re: QOP SASL property
Posted by Chris Nauroth <cn...@hortonworks.com>.
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" <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 <fp...@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 <fp...@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 <fp...@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 <fp...@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
>><cn...@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" <fp...@apache.org> wrote:
>> >>>>>>>
>> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
>>property
>> for
>> >>>>>> SASL
>> >>>>>>>> when running ZooKeeper?
>> >>>>>>>>
>> >>>>>>>> -Flavio
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>
Re: QOP SASL property
Posted by Chris Nauroth <cn...@hortonworks.com>.
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" <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 <fp...@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 <fp...@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 <fp...@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 <fp...@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
>><cn...@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" <fp...@apache.org> wrote:
>> >>>>>>>
>> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection)
>>property
>> for
>> >>>>>> SASL
>> >>>>>>>> when running ZooKeeper?
>> >>>>>>>>
>> >>>>>>>> -Flavio
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <fp...@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.html
> ).
> > 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 <fp...@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 <fp...@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 <fp...@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 <cn...@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/zoo
> >>>>>>> keeper/client/ZooKeeperSaslClient.java#L240
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>>>> keeper/client/ZooKeeperSaslClient.java#L288
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>>>> keeper/server/ZooKeeperSaslServer.java#L118
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>>>> 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" <fp...@apache.org> wrote:
> >>>>>>>
> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection) property
> for
> >>>>>> SASL
> >>>>>>>> when running ZooKeeper?
> >>>>>>>>
> >>>>>>>> -Flavio
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <fp...@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.html
> ).
> > 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 <fp...@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 <fp...@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 <fp...@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 <cn...@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/zoo
> >>>>>>> keeper/client/ZooKeeperSaslClient.java#L240
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>>>> keeper/client/ZooKeeperSaslClient.java#L288
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>>>> keeper/server/ZooKeeperSaslServer.java#L118
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>>>> 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" <fp...@apache.org> wrote:
> >>>>>>>
> >>>>>>>> Has anyone tried to use the QOP (Quality of Protection) property
> for
> >>>>>> SASL
> >>>>>>>> when running ZooKeeper?
> >>>>>>>>
> >>>>>>>> -Flavio
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: QOP SASL property
Posted by Flavio Junqueira <fp...@apache.org>.
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.html).
> 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 <fp...@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 <fp...@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 <fp...@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 <cn...@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/zoo
>>>>>>> keeper/client/ZooKeeperSaslClient.java#L240
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>>>> keeper/client/ZooKeeperSaslClient.java#L288
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>>>> keeper/server/ZooKeeperSaslServer.java#L118
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>>>> 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" <fp...@apache.org> wrote:
>>>>>>>
>>>>>>>> Has anyone tried to use the QOP (Quality of Protection) property for
>>>>>> SASL
>>>>>>>> when running ZooKeeper?
>>>>>>>>
>>>>>>>> -Flavio
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: QOP SASL property
Posted by Flavio Junqueira <fp...@apache.org>.
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.html).
> 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 <fp...@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 <fp...@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 <fp...@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 <cn...@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/zoo
>>>>>>> keeper/client/ZooKeeperSaslClient.java#L240
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>>>> keeper/client/ZooKeeperSaslClient.java#L288
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>>>> keeper/server/ZooKeeperSaslServer.java#L118
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>>>> 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" <fp...@apache.org> wrote:
>>>>>>>
>>>>>>>> Has anyone tried to use the QOP (Quality of Protection) property for
>>>>>> SASL
>>>>>>>> when running ZooKeeper?
>>>>>>>>
>>>>>>>> -Flavio
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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.html).
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 <fp...@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 <fp...@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 <fp...@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 <cn...@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/zoo
> >>>>> keeper/client/ZooKeeperSaslClient.java#L240
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>> keeper/client/ZooKeeperSaslClient.java#L288
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>> keeper/server/ZooKeeperSaslServer.java#L118
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>> 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" <fp...@apache.org> wrote:
> >>>>>
> >>>>>> Has anyone tried to use the QOP (Quality of Protection) property for
> >>>> SASL
> >>>>>> when running ZooKeeper?
> >>>>>>
> >>>>>> -Flavio
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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.html).
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 <fp...@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 <fp...@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 <fp...@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 <cn...@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/zoo
> >>>>> keeper/client/ZooKeeperSaslClient.java#L240
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>> keeper/client/ZooKeeperSaslClient.java#L288
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>> keeper/server/ZooKeeperSaslServer.java#L118
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>>>> 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" <fp...@apache.org> wrote:
> >>>>>
> >>>>>> Has anyone tried to use the QOP (Quality of Protection) property for
> >>>> SASL
> >>>>>> when running ZooKeeper?
> >>>>>>
> >>>>>> -Flavio
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: QOP SASL property
Posted by Flavio Junqueira <fp...@apache.org>.
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 <fp...@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 <fp...@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 <cn...@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/zoo
>>>>> keeper/client/ZooKeeperSaslClient.java#L240
>>>>>
>>>>>
>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>> keeper/client/ZooKeeperSaslClient.java#L288
>>>>>
>>>>>
>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>> keeper/server/ZooKeeperSaslServer.java#L118
>>>>>
>>>>>
>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>> 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" <fp...@apache.org> wrote:
>>>>>
>>>>>> Has anyone tried to use the QOP (Quality of Protection) property for
>>>> SASL
>>>>>> when running ZooKeeper?
>>>>>>
>>>>>> -Flavio
>>>>>
>>>>
>>>>
>>
>>
Re: QOP SASL property
Posted by Flavio Junqueira <fp...@apache.org>.
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 <fp...@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 <fp...@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 <cn...@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/zoo
>>>>> keeper/client/ZooKeeperSaslClient.java#L240
>>>>>
>>>>>
>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>> keeper/client/ZooKeeperSaslClient.java#L288
>>>>>
>>>>>
>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>> keeper/server/ZooKeeperSaslServer.java#L118
>>>>>
>>>>>
>>>>>
>>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>>>> 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" <fp...@apache.org> wrote:
>>>>>
>>>>>> Has anyone tried to use the QOP (Quality of Protection) property for
>>>> SASL
>>>>>> when running ZooKeeper?
>>>>>>
>>>>>> -Flavio
>>>>>
>>>>
>>>>
>>
>>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <fp...@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 <fp...@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 <cn...@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/zoo
> >>> keeper/client/ZooKeeperSaslClient.java#L240
> >>>
> >>>
> >>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>> keeper/client/ZooKeeperSaslClient.java#L288
> >>>
> >>>
> >>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>> keeper/server/ZooKeeperSaslServer.java#L118
> >>>
> >>>
> >>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>> 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" <fp...@apache.org> wrote:
> >>>
> >>>> Has anyone tried to use the QOP (Quality of Protection) property for
> >> SASL
> >>>> when running ZooKeeper?
> >>>>
> >>>> -Flavio
> >>>
> >>
> >>
>
>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <fp...@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 <fp...@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 <cn...@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/zoo
> >>> keeper/client/ZooKeeperSaslClient.java#L240
> >>>
> >>>
> >>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>> keeper/client/ZooKeeperSaslClient.java#L288
> >>>
> >>>
> >>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>> keeper/server/ZooKeeperSaslServer.java#L118
> >>>
> >>>
> >>>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> >>> 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" <fp...@apache.org> wrote:
> >>>
> >>>> Has anyone tried to use the QOP (Quality of Protection) property for
> >> SASL
> >>>> when running ZooKeeper?
> >>>>
> >>>> -Flavio
> >>>
> >>
> >>
>
>
Re: QOP SASL property
Posted by Flavio Junqueira <fp...@apache.org>.
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 <fp...@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 <cn...@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/zoo
>>> keeper/client/ZooKeeperSaslClient.java#L240
>>>
>>>
>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>> keeper/client/ZooKeeperSaslClient.java#L288
>>>
>>>
>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>> keeper/server/ZooKeeperSaslServer.java#L118
>>>
>>>
>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>> 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" <fp...@apache.org> wrote:
>>>
>>>> Has anyone tried to use the QOP (Quality of Protection) property for
>> SASL
>>>> when running ZooKeeper?
>>>>
>>>> -Flavio
>>>
>>
>>
Re: QOP SASL property
Posted by Flavio Junqueira <fp...@apache.org>.
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 <fp...@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 <cn...@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/zoo
>>> keeper/client/ZooKeeperSaslClient.java#L240
>>>
>>>
>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>> keeper/client/ZooKeeperSaslClient.java#L288
>>>
>>>
>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>> keeper/server/ZooKeeperSaslServer.java#L118
>>>
>>>
>>>
>> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
>>> 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" <fp...@apache.org> wrote:
>>>
>>>> Has anyone tried to use the QOP (Quality of Protection) property for
>> SASL
>>>> when running ZooKeeper?
>>>>
>>>> -Flavio
>>>
>>
>>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <fp...@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 <cn...@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/zoo
> > keeper/client/ZooKeeperSaslClient.java#L240
> >
> >
> >
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> > keeper/client/ZooKeeperSaslClient.java#L288
> >
> >
> >
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> > keeper/server/ZooKeeperSaslServer.java#L118
> >
> >
> >
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> > 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" <fp...@apache.org> wrote:
> >
> >> Has anyone tried to use the QOP (Quality of Protection) property for
> SASL
> >> when running ZooKeeper?
> >>
> >> -Flavio
> >
>
>
Re: QOP SASL property
Posted by Ivan Kelly <iv...@apache.org>.
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 <fp...@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 <cn...@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/zoo
> > keeper/client/ZooKeeperSaslClient.java#L240
> >
> >
> >
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> > keeper/client/ZooKeeperSaslClient.java#L288
> >
> >
> >
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> > keeper/server/ZooKeeperSaslServer.java#L118
> >
> >
> >
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> > 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" <fp...@apache.org> wrote:
> >
> >> Has anyone tried to use the QOP (Quality of Protection) property for
> SASL
> >> when running ZooKeeper?
> >>
> >> -Flavio
> >
>
>
Re: QOP SASL property
Posted by Flavio Junqueira <fp...@apache.org>.
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 <cn...@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/zoo
> keeper/client/ZooKeeperSaslClient.java#L240
>
>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> keeper/client/ZooKeeperSaslClient.java#L288
>
>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> keeper/server/ZooKeeperSaslServer.java#L118
>
>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> 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" <fp...@apache.org> wrote:
>
>> Has anyone tried to use the QOP (Quality of Protection) property for SASL
>> when running ZooKeeper?
>>
>> -Flavio
>
Re: QOP SASL property
Posted by Flavio Junqueira <fp...@apache.org>.
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 <cn...@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/zoo
> keeper/client/ZooKeeperSaslClient.java#L240
>
>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> keeper/client/ZooKeeperSaslClient.java#L288
>
>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> keeper/server/ZooKeeperSaslServer.java#L118
>
>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
> 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" <fp...@apache.org> wrote:
>
>> Has anyone tried to use the QOP (Quality of Protection) property for SASL
>> when running ZooKeeper?
>>
>> -Flavio
>
Re: QOP SASL property
Posted by Chris Nauroth <cn...@hortonworks.com>.
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/zoo
keeper/client/ZooKeeperSaslClient.java#L240
https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
keeper/client/ZooKeeperSaslClient.java#L288
https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
keeper/server/ZooKeeperSaslServer.java#L118
https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
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" <fp...@apache.org> wrote:
>Has anyone tried to use the QOP (Quality of Protection) property for SASL
>when running ZooKeeper?
>
>-Flavio
Re: QOP SASL property
Posted by Chris Nauroth <cn...@hortonworks.com>.
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/zoo
keeper/client/ZooKeeperSaslClient.java#L240
https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
keeper/client/ZooKeeperSaslClient.java#L288
https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
keeper/server/ZooKeeperSaslServer.java#L118
https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zoo
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" <fp...@apache.org> wrote:
>Has anyone tried to use the QOP (Quality of Protection) property for SASL
>when running ZooKeeper?
>
>-Flavio