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.220.171 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=BGtKkabfQnHEZz7rzUySPgA+2kWAIyyGiBfk3sJjDy2LKlpSvMqAHBp5924gv1Plza
         1gM08W0x8Cp594Wz0zgU/ltZGcw2Lfto54Jj7lrOl5Xn7aknqyXexZc7YydVd4OFDcXw
         DGAazEtbjv83YbH+ZF8ZQxN9L0A5KsRrWV5GU=
MIME-Version: 1.0
In-Reply-To: 
 <77F1E32F67C8D5479858C0C7E93EB465072D94A7@WAL-MAIL.global.avidww.com>
References: <4DF1CD08.7010906@zeus.net.au>
	<BANLkTi=KjvtvLbQeWxur=MNnLWpMLoDxog@mail.gmail.com>
	<77F1E32F67C8D5479858C0C7E93EB465072D94A7@WAL-MAIL.global.avidww.com>
Date: Fri, 10 Jun 2011 19:01:17 +0100
Message-ID: <BANLkTi=5ezKsPfLJC7nT4hCqiZQXMrdqEA@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

Okay, so what is a pragmatic migration then?

That tells us something about potential solutions. Although there
probably isn't one if we're saying we can't ever disrupt clients....

On 10 June 2011 18:28, Christopher Dolan <christopher.dolan@avid.com> wrote=
:
> But v2 isn't backward compatible with anything, even itself if you're mis=
sing the META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider f=
ile. I've tried to upgrade my djinn to v2, but it requires a flag day becau=
se any existing v1 clients will never be able to speak to v2 servers if the=
 clients lack the provider file.
>
> I think a prerequisite for deprecation of v1 would be a pragmatic migrati=
on path to v2. With the current v2 implementation, I don't think such a mig=
ration is possible.
>
> Chris
>
> -----Original Message-----
> From: Dan Creswell [mailto:dan.creswell@gmail.com]
> Sent: Friday, June 10, 2011 10:47 AM
> To: dev@river.apache.org
> Subject: Re: Security & Re: Discovery V2 migration
>
> 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 x=
500
>> discovery implementations, unfortunately, if the unicast discovery
>> implementation being used doesn't comply with constraints for Authentica=
tion
>> and Confidentiality, the constraints are re tried against the unmarshall=
ed
>> 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 bubbl=
e up
>> during discovery.
>>
>> I think we should change this specifically for Authentication and
>> Confidentiality constraints, if these are requested but not satisfied du=
ring
>> 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 provi=
de a
>> way for existing deployments to migrate.
>>
>> LookupLocator performs unicast discovery v1. =A0 ConstrainableLookupLoca=
tor
>> 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 the
>> 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 thr=
eat to
>> security occurs during Unicast Discovery, when unmarshalling attacks can
>> 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 lega=
cy
>> 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 r=
eply
>> 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 a=
s
>> stated. I thought the resources were defined in the default Jini 2.0 JAR
>> 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 befor=
e
>> the effort stopped. I don't know if any of those guys are still followin=
g
>> 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 i=
f
>>> 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 about=
 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 fig=
ure
>>>> out how to turn V2 on (I ended up reading a lot of source code), and i=
t
>>>> looks like it's nearly impossible to migrate in a backward compatible
>>>> way, i.e. continuing to fully interact with services that were deploye=
d
>>>> 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" and
>>>> 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 Reggies
>>>> 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 wi=
th
>>>> an error message about unknown format IDs.
>>>>
>>>> So, the only solution I can see is to start shipping new services with
>>>> 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 about=
?
>>>> 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 fir=
st
>>>> and then retry with V1?
>>>>
>>>> I feel like I'm missing some central point...
>>>>
>>>> Chris
>>
>>
>>
>