100 likes | 183 Views
Experience Building and Supporting Secure Ad Hoc Collaborations. Deb Agarwal Lawrence Berkeley National Laboratory. Ad Hoc Collaboration - Internet2 Fall Meeting, 2004. Context. Developing and supporting collaboration tools for use by distributed science teams
E N D
Experience Building and Supporting Secure Ad Hoc Collaborations Deb Agarwal Lawrence Berkeley National Laboratory Ad Hoc Collaboration -Internet2 Fall Meeting, 2004
Context • Developing and supporting collaboration tools for use by distributed science teams • Concentrating on supporting the day-to-day work environment • Started with traditional kerberos-based and X.509-based solutions for securing collaborative environments Internet2 Fall Meeting
Security Development Environments • Shared experiment control • Instant messaging • IRC • Jabber • Peer-to-peer file sharing • SciShare Internet2 Fall Meeting
Requirements • Ability to participate from anywhere • Low threshold for entry into the system • Incorporate new users easily • No waiting for authorization to enter the system • Support for identifying trusted users • Ability to specify the type of authentication and authorization needed • Servers are not required Internet2 Fall Meeting
Approach - Architecture • Peer-to-peer system • Each site can act as both server and client or either • Specialized servers provide added value • Archiving • Certificate authority • User registry • Rendezvous point Internet2 Fall Meeting
Registration Model • Registration methods • Self • Trusted user • Administrator • Issues • Where are users registered • Who controls/administers the registry • Who decides the list of trusted users • How can identities be verified Internet2 Fall Meeting
SciShare – File-sharing • Using X.509 authentication • Pseudo certificates – accept any valid chain for these certificates • Trusted users – use trusted CA signed certificates • Users can authorize both types of certificates for access to resources • Build trust and eventually allow sharing of trust groups among users • Communication is encrypted Internet2 Fall Meeting
Jabber – Instant Messaging • Current • Designed as a client/server architecture • Users self-register for a username and password • Future • Run servers everywhere they are needed • Add support for X.509 • Augment to allow vetting of registrations • Allow specification of authentication level for entry to a room • Augment to allow definition of trust groups for particular levels of access Internet2 Fall Meeting
Crossing the borders • Escort • Accompany a user in an area they are not normally authorized to access • Host able to control the guest’s access • Vouching • A user vouches for a less privileged user • Temporarily elevates privileges of the vouchee • Vouchee able to act without escort Internet2 Fall Meeting
Some Issues for the Future • Making this intuitive for the user • Allowing elevation of credentials without compromising the security of the elevated levels • Finding communication protocols that can operate in a heterogeneous security environment • Designing the callouts and interface for adding escort and vouching to the applications • Standardization so these features are available pervasively Internet2 Fall Meeting