Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of dan.creswell@gmail.com
 designates 209.85.212.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=KaEfnHbz7sKKAQF+YrmVKfoNQj2L4wAkjgDOIH6pz2sEx16k8H1qwlI3/T6R1xSrkc
         J3BeItO1d3fRWMvHChawetqTn5ZF949xENVIxAimKKCM+OSvJkBkFiVbfR6mlZThgsl1
         pijRSyDPP4IKBnI4gNO9JqD9uXf6gOmA1RUAU=
MIME-Version: 1.0
In-Reply-To: <BANLkTikLRVxLVZtaXsLcXS5ZtKWT_aUEDg@mail.gmail.com>
References: <4DF1CD08.7010906@zeus.net.au>
	<BANLkTi=KjvtvLbQeWxur=MNnLWpMLoDxog@mail.gmail.com>
	<BANLkTikLRVxLVZtaXsLcXS5ZtKWT_aUEDg@mail.gmail.com>
Date: Fri, 10 Jun 2011 16:58:38 +0100
Message-ID: <BANLkTimx9DsemKmv1NbZuLmrTY5gU50pvQ@mail.gmail.com>
Subject: Re: Security & Re: Discovery V2 migration
From: Dan Creswell <dan.creswell@gmail.com>
To: dev@river.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

:)

Agree re: users@

For a bit more context of where I'm coming from: "opinionated
software" (http://gettingreal.37signals.com/ch04_Make_Opinionated_Software.=
php)

We can potentially improve River's appeal by making some tough choices....

On 10 June 2011 16:53, Tom Hobbs <tvhobbs@googlemail.com> wrote:
> At risk of aligning myself with the flamebait ;-), =A0this isn't a bad id=
ea.
> We've got a number of major version number style changes in the pipeline.
> Lets talk about the possibility of rolling this into that.
>
> Lets also make sure such discussions find their way onto users@ as well
> though.
>
> Cheers Dan.
>
> On 10 Jun 2011 16:47, "Dan Creswell" <dan.creswell@gmail.com> wrote:
>> Controversial position: Why don't we just deprecate the entirety of V1?
>>
>> That means less work to do, no nasty dark corner workarounds as we try
>> and retain compatibility, a clear policy on what will work with what
>> etc. Fact is V2 has been around so long that most people are surely
>> using it by now?
>>
>> I just am not a fan of backward compatibility without some very good
>> reasons, history shows this sort of "holding onto the past" to be a
>> nightmare for all concerned. One needs to look no further than the JDK
>> itself which is full of cruft and cut corners for the sake of
>> compatibility.
>>
>> On 10 June 2011 08:51, Peter Firmstone <jini@zeus.net.au> wrote:
>>> _Unicast Discovery v2 - Unmarshalling Attack with Registrar proxy._
>>>
>>> During unicast discovery, we have the option of using SSL, Kerberos or
> x500
>>> discovery implementations, unfortunately, if the unicast discovery
>>> implementation being used doesn't comply with constraints for
> Authentication
>>> and Confidentiality, the constraints are re tried against the
> unmarshalled
>>> registrar proxy, bypassing the security benefits these implementations
>>> provide.
>>>
>>> I believe this was an oversight to allow codebase integrity constraints
> to
>>> bubble up as Unfulfilled Constraints to the upper layer, where they're
>>> checked against the unmarshalled proxy, unfortunately it appears to be =
a
>>> mistake to allow Authentication and Confidentiality constraints to bubb=
le
> up
>>> during discovery.
>>>
>>> I think we should change this specifically for Authentication and
>>> Confidentiality constraints, if these are requested but not satisfied
> during
>>> discovery we should throw an UnsupportedConstraintException.
>>>
>>> Doing so avoids the DOS unmarshalling attack which is possible during
>>> unmarshalling of an unauthenticated registrar proxy.
>>>
>>> _Unicast Discovery v1_
>>>
>>> In light of Unicast Discovery v1's total lack of support for security, =
I
>>> believe we should deprecate it, for this to happen we also need to
> provide a
>>> way for existing deployments to migrate.
>>>
>>> LookupLocator performs unicast discovery v1. =A0 ConstrainableLookupLoc=
ator
>>> extends LookupLocator and is used for v2 unicast discovery constraints.
>>>
>>>
>>> _But what about Multicast Discovery?
>>>
>>> _Multicast discovery produces a LookupLocator which is used by Unicast
>>> Discovery to retrieve a registrar proxy.
>>>
>>> _Multicast Request Protocol v1
>>>
>>> _Please add any security concerns here.
>>>
>>> No integrity support - how much of a problem is this?
>>>
>>> _Multicast Request Protocol v2
>>>
>>> _x500 integrity supported_
>>>
>>> __Multicast Announcement Protocol v1
>>>
>>> _Please add any security concerns here.
>>>
>>> No integrity support, packets can be modified in transit, but this
> doesn't
>>> seem to be much of a concern for announcement anyway.
>>> _
>>> __Multicast Announcement Protocol v2
>>>
>>> _x500 integrity supported.
>>>
>>> Note that Multicast v2 supports x500 integrity constraints, in addition
> to
>>> plain text, while it doesn't prevent someone viewing the contents of th=
e
>>> packet, it ensures the packets contents haven't been tampered with.
>>>
>>> I don't see a reason to deprecate Multicast Discovery v1 for existing
>>> deployments, =A0x500 integrity is an obvious advantage, but the real th=
reat
> to
>>> security occurs during Unicast Discovery, when unmarshalling attacks ca=
n
>>> occur.
>>>
>>> So we could, in theory at least, use a LookupLocator from Multicast v1
>>> discovery with Unicast v2 discovery in newly deployed clients =A0and
>>> registrars to remain network compatible with existing clients that only
>>> support D v1.
>>>
>>> Figuring out how to solve the migration problem?
>>>
>>> I think most of the migration problem exists with Multicast, so for
> legacy
>>> support reasons a djinn could employ Multicast v1 with a combination of
>>> Unicast v1 (for older clients) and v2 for the latter.
>>>
>>> Registrar's could have providers for both v1 and v2 discovery and thus
> reply
>>> to both.
>>>
>>> This will require some revisions to discovery utilities (implementing
>>> DiscoveryGroupManagement) for our next release, in order to provide an
>>> upgrade path for existing djinn's.
>>>
>>> Any ideas?
>>>
>>> Cheers,
>>>
>>> Peter.
>>> *
>>> *_
>>> _
>>>
>>>
>>>
>>>
>>> Hi Peter.
>>>
>>> I don't remember enough about this to know for sure if this problem is =
as
>>> stated. I thought the resources were defined in the default Jini 2.0 JA=
R
>>> files, but that could have changed after my time. Mike Warres was the
>>> initial author of this stuff, but others at Sun took over from him befo=
re
>>> the effort stopped. I don't know if any of those guys are still followi=
ng
>>> the conversation.
>>>
>>> - Tim
>>>
>>> On Dec 12, 2010, at 2:31 PM, Peter Firmstone <jini@zeus.net.au> wrote:
>>>
>>>> Tim,
>>>>
>>>> Do you know of an alternative plan to Chris' suggestion, for migration
>>>> from Discovery V1 to V2?
>>>>
>>>> It probably all happened too long ago to remember now, just wondering =
if
>>>> anything comes to mind?
>>>>
>>>> I'll look into it further too.
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>> Since its inception, my project has been using DiscoveryV1 and we've
>>>>> never dealt with Jini constraints. =A0Peter's comments last week abou=
t
> the
>>>>> flexibility of DiscoveryV2 inspired me to learn more about it and to
>>>>> experiment a bit. =A0To my surprised, I found it very difficult to fi=
gure
>>>>> out how to turn V2 on (I ended up reading a lot of source code), and =
it
>>>>> looks like it's nearly impossible to migrate in a backward compatible
>>>>> way, i.e. continuing to fully interact with services that were deploy=
ed
>>>>> with the default preference for V1. =A0I would LOVE to be told that I=
've
>>>>> made a mistake or missed something important...
>>>>>
>>>>> * To switch Reggie to use V2 for multicast announcements:
>>>>>
>>>>> com.sun.jini.reggie {
>>>>> =A0 discoveryConstraints =3D new BasicMethodConstraints(new
>>>>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
>>>>> }
>>>>>
>>>>> * To switch group discovery to use V2 for multicast requests:
>>>>>
>>>>> net.jini.discovery.LookupDiscovery {
>>>>> =A0 discoveryConstraints =3D new BasicMethodConstraints(new
>>>>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
>>>>> }
>>>>>
>>>>> * To create a locator that uses V2 for directed unicast discovery:
>>>>>
>>>>> =A0 new ConstrainableLookupLocator(host, port, =A0 =A0 =A0 =A0 =A0new
>>>>> BasicMethodConstraints(new InvocationConstraints(null,
>>>>> DiscoveryProtocolVersion.TWO)));
>>>>>
>>>>>
>>>>> * To tell DiscoveryV2 how to encode and decode the messages, create a
>>>>> file called
>>>>> "META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider" an=
d
>>>>> put in lines (for example):
>>>>>
>>>>> =A0com.sun.jini.discovery.plaintext.Client
>>>>> =A0com.sun.jini.discovery.plaintext.Server
>>>>>
>>>>> However (and this is the key problem), any deployed clients or Reggie=
s
>>>>> which lack the
>>>>> META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider file
>>>>> will not be able to decode the incoming messages and will drop them
> with
>>>>> an error message about unknown format IDs.
>>>>>
>>>>> So, the only solution I can see is to start shipping new services wit=
h
>>>>> the DiscoveryFormatProvider file in place, and then wait several
>>>>> releases until all of my old deployments have been retired, and then
>>>>> turn on the V2 preference. =A0Am I wrong? =A0Is there a trick to get
>>>>> already-deployed clients to use a format ID that they don't know abou=
t?
>>>>> Surely other people have had similar problems deploying brand-new
>>>>> DiscoveryFormatProvider implementations?
>>>>>
>>>>> Is there a way to make services send out both V1 and V2 multicasts? =
=A0Is
>>>>> there a way to tell LookupDiscovery.UnicastDiscoveryTask to try V2
> first
>>>>> and then retry with V1?
>>>>>
>>>>> I feel like I'm missing some central point...
>>>>>
>>>>> Chris
>>>
>>>
>>>
>