river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Security & Re: Discovery V2 migration
Date Fri, 10 Jun 2011 23:15:37 GMT
I tend to agree with Dan, there's some cruft we need to dispose of, 
however we might be able to make the transition period easier for users, 
so I make the following proposal / suggestion:

Currently Discovery is either all v1 or all v2.

 From what I can see the migration problem is with multicast.

It looks like (with some minor modifications) we can migrate an existing 
Discovery v1 djinn by requiring all registrar nodes to be modified as 
follows:

   1. Registrars support and respond to both versions of Unicast request
      protocols (v1 for migration only).
   2. The Registrar only uses Multcast Announcement Protocol v2
   3. The Registrar responds to both versions of  Multicast Request
      Protocol.

Clients and services use only one version, older existing deployments 
use Discovery v1, new deployments use discovery v2.

We can branch a transition release for Registrars, including required 
functionality.

Our next release can have Discovery v1 removed while the Registrar 
transition branch can be maintained until everyone's environments have 
been converted.

We might also be able to solve the problem using modular builds, with an 
alternate discovery module.

Cheers,

Peter.

Christopher Dolan 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