Experience Building and Supporting Secure Ad Hoc Collaborations Deb Agarwal Lawrence Berkeley National Laboratory Ad Hoc Collaboration - Internet2 Fall Meeting, 2004

Internet2 Fall Meeting 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