Re: [JXTA discuss] how to stop malicious peers?

Michele Amoretti wrote:

>I am interested in this discussion, too. Mohamed (or someone else), could you 
>answer to Matteo's questions? Thnk you very much.
>
>
>On Saturday 09 April 2005 10:39, Matteo Bisi wrote:
>  
>
>>I would develop a secure rdv policy control for my secure group, in which
>>there are a new MembershipService for peer's authentication and group
>>admission,
>>and a new AccessService for managing peers' authorizations.
>>In this groups, a peer (edge or rdv) can have different 'roles', (e.g. from
>>the least to the
>>most important: 'newbie', 'searcher', 'publisher', 'admin').
>>For each role, a peer can perform only, well-defined, actions.
>>
>>What I need is a sort of "capabilities"-based access control, so I would be
>>sure that a peer which is a 'newbie' can not perform unauthorizaded
>>actions. For this purpose, I think to create a specific access table for
>>each authenticated peer,
>>to store the operations it can perform.
>>In this scenario, there is no centralized table, but instead when a peer is
>>authenticated, it is
>>given a number of credential. Each credential is associated with a
>>particular operation. It is something like having a ring full of keys
>>rather than a single key.
>>I suppose to meet this requirements through a specific AccessService
>>implementation.
>>
>>    
>>

So far so good.

>>The main problem is: an hackered peer can skip the access control, thus trying to perform unauthorizated actions, and my AccessService become useless...
>>To prevent this situation, I want to dispose some further 'check points'
>>that can block this wrong attempt. An idea could be: if a rdv (or some admin peers), is
>>able to check if a peer which is attempting to perform an action (which involves a
>>discovery task, such as 'publishing' or 'discoverying'), has or not the right permissions, it
>>should block it in some way. To do this, I need to modify some JXTA sources and to add a custom rdv policy for checking this permissions.
>>The ACL solution seems good, but it should be updated runtime, so I don't know if it is the best choice.
>>
>>What are the more suitable sources I should modify?
>>Only the EdgePeerRdvService and the RdvPeerRdvService?
>>Or should implement a new RendezVousService?
>>    
>>

I think imposing a low level quota, small enough to allow a peer to 
establish connections/routes, and authenticate at the transport layer is 
the most efficient and least resource intensive (cpu, network, memory, 
and disk).

I can see this being addressed as follows:

- All peers connecting for the first time are alloted a quota (limited 
number of messages, and size)
- Such peers must establish credentials before any quotas are lifted.
- Peers failing to establish credentials within a specified time period 
are gray listed (there ought to be an IP to ID mapping to prevent a jxta 
peer masquerading)
- Peers maybe removed from the gray list after a specified timeout (minutes)
- Provide transports access to AccessService/AccessList whereby a 
transport can accept or sever connections, and augment access control 
for a given peer.  

I also think the AccessService/AccessList should be enhanced to provide 
access control by package, whereby services can enforce higher level 
policies.


This would be a good addition to the platform and would like to see it 
formalized into a enhancement for the upcoming release.

Mohamed