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

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.
>
> 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?
>
> Thank you


-- 
Michele Amoretti, Ph.D. Student
Dip. di Ingegneria dell'Informazione, Università degli Studi di Parma
Parco Area delle Scienze, 181A I-43100 Parma Italy
Phone: +39-(0521)-906147  Fax: +39-(0521)-905723

Home page:
http://dsg.ce.unipr.it/People/Amoretti.html
Ph.D. project page (Service-oriented P2P Architecture):
http://dsg.ce.unipr.it/research/SP2A