river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: Security & Re: Discovery V2 migration
Date Fri, 10 Jun 2011 18:01:17 GMT
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 missing the META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider
file. I've tried to upgrade my djinn to v2, but it requires a flag day because 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 migration path to v2.
With the current v2 implementation, I don't think such a migration 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 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 bubble 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.   ConstrainableLookupLocator
>> 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,  x500 integrity is an obvious advantage, but the real threat 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  and
>> 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 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 before
>> the effort stopped. I don't know if any of those guys are still following
>> 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.  Peter's comments last week about the
>>>> flexibility of DiscoveryV2 inspired me to learn more about it and to
>>>> experiment a bit.  To my surprised, I found it very difficult to figure
>>>> 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 deployed
>>>> with the default preference for V1.  I 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 {
>>>>   discoveryConstraints = new BasicMethodConstraints(new
>>>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
>>>> }
>>>>
>>>> * To switch group discovery to use V2 for multicast requests:
>>>>
>>>> net.jini.discovery.LookupDiscovery {
>>>>   discoveryConstraints = new BasicMethodConstraints(new
>>>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
>>>> }
>>>>
>>>> * To create a locator that uses V2 for directed unicast discovery:
>>>>
>>>>   new ConstrainableLookupLocator(host, port,          new
>>>> 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):
>>>>
>>>>  com.sun.jini.discovery.plaintext.Client
>>>>  com.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 with
>>>> 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.  Am I wrong?  Is 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?  Is
>>>> 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
>>
>>
>>
>

Mime
View raw message