zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Kelly <iv...@apache.org>
Subject Re: QOP SASL property
Date Sun, 11 Oct 2015 09:25:53 GMT
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 <andrew.purtell@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 <cnauroth@hortonworks.com>
> wrote:
> >
> > I filed ZOOKEEPER-2289 to track adding support for the full set of QOP
> > settings.  I did not target any specific fix version since there isn't
> > consensus yet on that.  Thank you, Flavio and Ivan.
> >
> > --Chris Nauroth
> >
> >
> >
> >
> >> On 10/9/15, 11:55 AM, "Ivan Kelly" <ivank@apache.org> wrote:
> >>
> >> Just to add, digest-md5 is obselete now[1], due to vulnerability to MITM
> >> attacks, so that case would need SSL in any case.
> >>
> >> krb is still safe though.
> >>
> >> [1] http://tools.ietf.org/html/rfc6331
> >>
> >> On Fri, Oct 9, 2015 at 7:10 PM Chris Nauroth <cnauroth@hortonworks.com>
> >> wrote:
> >>
> >>> Ivan is right.  Thank you!  I forgot about this part.
> >>>
> >>> When QOP is "auth" (the default), then SASL is just a one-time
> handshake
> >>> at the front of the connection, and the subsequent transfer of bytes
> >>> between client and server remain the same.  When QOP is "auth-int",
> SASL
> >>> needs to inspect the transferred bytes for digest-MD5 verification to
> >>> guard against man-in-the-middle tampering.  When QOP is "auth-conf",
> >>> SASL
> >>> needs to encrypt the bytes for privacy against a man-in-the-middle.
> The
> >>> latter two cases require the wrap/unwrap calls that Ivan mentioned.
> >>>
> >>> In Hadoop, we encapsulate the wrap/unwrap behind special stream
> >>> subclasses
> >>> that wrap over the underlying "raw" stream.
> >>>
> >>>
> >>>
> https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/
> >>> ha
> >>>
> >>>
> doop-common/src/main/java/org/apache/hadoop/security/SaslInputStream.java
> >>>
> >>> <
> https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project
> >>>
> /hadoop-common/src/main/java/org/apache/hadoop/security/SaslInputStream.j
> >>> ava>
> >>>
> >>>
> >>>
> >>>
> https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/
> >>> ha
> >>>
> >>>
> doop-common/src/main/java/org/apache/hadoop/security/SaslOutputStream.jav
> >>> a
> >>>
> >>> <
> https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project
> >>>
> /hadoop-common/src/main/java/org/apache/hadoop/security/SaslOutputStream.
> >>> java>
> >>>
> >>>
> >>> That's nice, because the code consuming the streams doesn't need to
> >>> worry
> >>> about repeated wrapping and unwrapping.  However, even if we set up
> >>> something like these classes in ZooKeeper, it appears the ZooKeeper
> >>> codebase isn't structured to make inserting those wrappers easy.
> >>>
> >>> This does look like it would be more invasive than I originally
> >>> described.
> >>>
> >>> --Chris Nauroth
> >>>
> >>>
> >>>
> >>>
> >>>> On 10/9/15, 7:57 AM, "Ivan Kelly" <ivank@apache.org> wrote:
> >>>>
> >>>> I think it's a fairly big change, especially since we'd then have a
> >>> lot of
> >>>> conditional if (sasl) { wrap_bytes } else { dont_wrap }. And then it
> >>>> affects all communication between server and client, which is quite
> >>> risky.
> >>>>
> >>>>> On Fri, Oct 9, 2015 at 4:54 PM Flavio Junqueira <fpj@apache.org>
> wrote:
> >>>>>
> >>>>> Ok, got it, but it sounds like we can just wrap and unwrap the bytes
> >>> we
> >>>>> are sending, no? Do you think that will end up being a lot of
> >>> changes?
> >>>>>
> >>>>> -Flavio
> >>>>>
> >>>>>> On 09 Oct 2015, at 15:38, Ivan Kelly <ivank@apache.org>
wrote:
> >>>>>>
> >>>>>> To protect the integrity of each packet, each packet needs to
be
> >>>>> wrapped
> >>>>> by
> >>>>>> SaslClient/SaslServer (see wrap/unwrap in
> >>>
> >>>
> http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/SaslClient.h
> >>>>> tml
> >>>>> ).
> >>>>>> Currently sasl is only used to initialize the connection, and
then
> >>> we
> >>>>> send
> >>>>>> over the raw socket. This changes the lifetime of the sasl
> >>>>> components, as
> >>>>>> it needs to be used with all communication. It's not like SSL,
> >>> where
> >>>>> we
> >>>>>> negotiate SSL at the start and then the SSL engine provides
a
> >>> socket
> >>>>> which
> >>>>>> we use to send data.
> >>>>>>
> >>>>>> -Ivan
> >>>>>>
> >>>>>>> On Fri, Oct 9, 2015 at 4:33 PM Flavio Junqueira <fpj@apache.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I'm not sure based on what you say that it'd be invasive.
Enabling
> >>>>>>> different types of QOP seems to be relatively straightforward,
> >>> unless
> >>>>> I'm
> >>>>>>> missing something here. Chris did a good job describing
what needs
> >>>>> to be
> >>>>>>> done, and this far I have the same understanding of the
changes.
> >>>>>>>
> >>>>>>> -Flavio
> >>>>>>>
> >>>>>>>> On 09 Oct 2015, at 15:30, Ivan Kelly <ivank@apache.org>
wrote:
> >>>>>>>>
> >>>>>>>> IMO, adding QOP to 3.4 would be a fairly large and invasive
> >>> change,
> >>>>> which
> >>>>>>>> is something which shouldn't be done on the stable branch.
> >>>>>>>>
> >>>>>>>> -Ivan
> >>>>>>>>
> >>>>>>>> On Fri, Oct 9, 2015 at 4:02 PM Flavio Junqueira <fpj@apache.org>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Not in the 3.4 branch, which is the latest stable
branch at the
> >>>>> moment.
> >>>>>>>>>
> >>>>>>>>> -Flavio
> >>>>>>>>>
> >>>>>>>>>> On 09 Oct 2015, at 15:00, Ivan Kelly <ivank@apache.org>
wrote:
> >>>>>>>>>>
> >>>>>>>>>> Is auth-int necessary if we have SSL on the
client (as there
> >>> is in
> >>>>>>>>> trunk)?
> >>>>>>>>>> My understanding is that all comms would have
to be wrapped by
> >>>>> sasl
> >>>>> if
> >>>>>>>>> you
> >>>>>>>>>> have QOP enabled.
> >>>>>>>>>>
> >>>>>>>>>> -Ivan
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Oct 9, 2015 at 9:42 AM Flavio Junqueira
> >>> <fpj@apache.org>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi Chris,
> >>>>>>>>>>>
> >>>>>>>>>>> Yeah, I was thinking along the same lines,
so sounds like a
> >>>>> plan. I
> >>>>>>> know
> >>>>>>>>>>> Raul is going to hate me for this, but I'd
really like to have
> >>>>> this
> >>>>> in
> >>>>>>>>>>> 3.4.7. It sounds like a simple enough change
that we can have
> >>> in
> >>>>>>>>> shortly,
> >>>>>>>>>>> does it sound right?
> >>>>>>>>>>>
> >>>>>>>>>>> Please go ahead with the jira if you have
time, and if you
> >>> don't
> >>>>> have
> >>>>>>>>> time
> >>>>>>>>>>> to work on the patch, just assign it to
me.
> >>>>>>>>>>>
> >>>>>>>>>>> -Flavio
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On 08 Oct 2015, at 23:16, Chris Nauroth
> >>>>> <cnauroth@hortonworks.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Flavio,
> >>>>>>>>>>>>
> >>>>>>>>>>>> It appears that the current code doesn't
give us any way to
> >>>>> control
> >>>>>>> the
> >>>>>>>>>>>> QOP, so it must be always using the
default QOP of "auth"
> >>>>>>>>> (authentication
> >>>>>>>>>>>> only).  This is because the calls to
Sasl#createSaslClient
> >>> and
> >>>>>>>>>>>> Sasl#createSaslServer pass a hard-coded
null for the
> >>> properties
> >>>>> map.
> >>>
> >>>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z
> >>>>> oo
> >>>>>>>>>>>> keeper/client/ZooKeeperSaslClient.java#L240
> >>>
> >>>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z
> >>>>> oo
> >>>>>>>>>>>> keeper/client/ZooKeeperSaslClient.java#L288
> >>>
> >>>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z
> >>>>> oo
> >>>>>>>>>>>> keeper/server/ZooKeeperSaslServer.java#L118
> >>>
> >>>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z
> >>>>> oo
> >>>>>>>>>>>> keeper/server/ZooKeeperSaslServer.java#L144
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> If we want to support setting QOP to
"auth-int"
> >>> (authentication
> >>>>> +
> >>>>>>>>>>>> integrity/man-in-the-middle tampering
protection) or
> >>> "auth-conf"
> >>>>>>>>>>>> (authentication + integrity + confidentiality/encryption),
> >>> then
> >>>>> I
> >>>>>>> think
> >>>>>>>>>>>> we'll need to make code changes to read
a new QOP
> >>> configuration
> >>>>>>>>> property,
> >>>>>>>>>>>> put it into a Map using Sasl#QOP as
the key, and then pass it
> >>>>> along
> >>>>>>> to
> >>>>>>>>>>> the
> >>>>>>>>>>>> Sasl#createSaslClient and Sasl#createSaslServer
calls.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is this what you need?  If so, then
I'd be happy to write up
> >>> the
> >>>>>>>>> proposal
> >>>>>>>>>>>> in a new JIRA.  I didn't find any existing
open JIRAs that
> >>> look
> >>>>>>>>> relevant.
> >>>>>>>>>>>>
> >>>>>>>>>>>> --Chris Nauroth
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 10/8/15, 2:06 PM, "Flavio Junqueira"
<fpj@apache.org>
> >>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Has anyone tried to use the QOP
(Quality of Protection)
> >>>>> property
> >>>>> for
> >>>>>>>>>>> SASL
> >>>>>>>>>>>>> when running ZooKeeper?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Flavio
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message