Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4CAB0387.8080508@zeus.net.au>
Date: Tue, 05 Oct 2010 20:52:55 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (trust)
References: <4C9DB5BF.8090307@zeus.net.au>
 <201010011500.49853.michal.kleczek@xpro.biz> <4CA9AE5B.7050208@qcg.nl>
 <201010041342.46272.michal.kleczek@xpro.biz> <4CA9C2B9.3060005@qcg.nl>
 <0B443A75-60BB-4313-A779-9731E2D22374@topiatechnology.com>
 <4CAAF0B3.3000508@qcg.nl>
In-Reply-To: <4CAAF0B3.3000508@qcg.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sim IJskes - QCG wrote:
> On 10/04/2010 05:49 PM, Mike McGrady wrote:
>> I think that we need to decide what the requirements are?  Anyone 
>> else thinking this?  NSA has a tee shirt saying, "We trust in trust".
>
> Defining requirements is good. But an excercise determining if jini is 
> ready for the internet is also good. This excercise can consist of 
> discussion of pros and cons of keeping the existing code, or adding 
> code to it. By having arguments and counter arguments we can build an 
> (collective) instinctive feeling for the strength and weaknesses of jini.
>
> I'm sure the original jini team had similar discussions, maybe not 
> over email, but more around a beer, or at the coffee machine. We need 
> to rebuild this team coherence.
>
> Gr. Sim
>
> BTW: i also do trust trust, and even i trust trust is trust.
>

Ok, my thoughts, the team that produced the Jini security infrastructure 
were a smart bunch, we can utilise any provider we like, it's very 
pluggable, fortunate are we.  We're also very fortunate for the 
brilliant security foundation in the JVM, Li didn't get to go all the 
way like he wanted, but his team managed to make history.

The whole escaped reference security auditing problem in Java wouldn't 
exist if Li's Guard Pattern was utilised for methods in all Java's 
security sensitive classes.

If you read the Jini Davis project interviews on Artima between Bill 
Venners and Bob Scheiffler, you soon realise that they knew Jini 
Security wasn't quite finished.

I'm not saying don't change the code, or that it's perfect (anything 
that's perfect is obsolete since it no longer changes, sorry can't 
remember the author), I'm saying, hmm there are some issues, lets 
investigate them.

Jini's model of trust is quite clever, it's a key component, 
establishment of trust has been implemented, we have SSL and Kerberos 
JERI Endpoint Client's for Unicast discovery, so the Registrar proxy 
objects (in serialized form) coming down the wire are private, between 
the client and the registrar.  We have integrity, Jini verify's that the 
CodeSource has the correct checksum, specified by the remote Registrar.  
The catch, there's this short period, where we haven't authenticated the 
Registrar, or verified the proxy, to do that we must ask the proxy for 
it's bootstrap proxy (a piece of local code) required for 
authentication.  To authenticate, we must unmarshall the proxy.

When we unmarshall the proxy, we're exposed to a DOS attack, no loss of 
private information, no real security hazard, just the irritation that 
Jini Service based Software will be made up of both Services and Clients 
and the DOS attack makes it brittle.

So I agree, trust is important.

To build team coherence, we must be prepared to listen and learn from 
the old hands who volunteer information, building cases for arguments 
just makes them fall silent.  When someone puts forward an opposing 
view, you don't have to take sides, it's better to just ask questions.

The reason that Jini wasn't a howling success like Java was not the 
fault of the code, I just think the timing wasn't right, it wasn't 
finished and has some areas we need to work on, we have people like 
Peter Jones, Tim Blackman, Dennis Reedy, Gregg Wonderly, Michel Kleczek, 
Chris Dolan, Zoltan Juhasz, Fred Oliver, Greg Trasuk, even Jim Waldo 
occasionally, Jim Hurley and Brian Murphy, who know the issues and are 
prepared to share their knowledge.  (Sorry if I've forgotten anyone - 
off the top of my head, no particular order) but we've also got our team 
of regular committers, Jonathan, Patricia, Sim, Tom and myself.

It's important we examine the code, ask questions respectfully and learn 
from each other.  It is difficult working from opposite sides of the 
world, we've got cultural differences, there's no body language to 
assist, but I'm confident we can work it out.

Cheers,

Peter.