Experience Building and Supporting Secure Ad Hoc Collaborations

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

2. 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

3. Security Development Environments • Shared experiment control • Instant messaging • IRC • Jabber • Peer-to-peer file sharing • SciShare Internet2 Fall Meeting

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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