r13 - 07 Jul 2005 - 17:44:06 - LisaDusseaultYou are here: OSAF >  Projects Web  >  DevelopmentHome > SecurityFramework > CanogaSecurityDesign

Canoga Security Design

Goal of this document is to summarize our Canoga Security Framework as we understand it currently (Jan '04) and to highlight open issues we need to resolve. This is a Design document. It lists requirements in the security area but does not particularly document implementation details to fulfilling such requirements.

Audience and Purpose. We have three core audiences for this document:

  • Higher Education Advisory Council. To keep the council apprised of our security framework, as security is a key concern of Higher Education and CSG in particular
  • Design Team. To align the design team with a common understanding of our security framework and to agree on a path to addressing the key security open issues
  • Apps and Repository Team. To provide developers with a higher-level picture of the scope of the security framework for Canoga and to provide the repository team with a set of requirements in the security arena

Security in Canoga. In the Chandler context, Security refers to the goal of providing access to relevant personal information within Chandler to its intended recipients only. It also refers to the prevention of malicious propagation of code, viruses and worms via Chandler. In this document, we organize security issues in the following key areas from the point of view of a Chandler client:

  • "Local" Repository access. This refers to the Chandler client accessing a "local" repository. Typically a local repository is a repository that's stored on the hard drive of the same computer that the Chandler client is running on, although in some cases the native OS or file system might make it possible for a user to run a Chandler client against a repository located on a networked file-server. Decisions we need to make:
    • For Canoga, we assume that a repository is only ever accessed by one Chandler client at a time. (Perhaps the repository is locked when the first Canoga client logs in, and then other clients can't access the repository directly, they can only get to data in the repository by doing Chandler browsing and sharing operations via the first client.)
    • We assume that a Canoga client is always "logged in" to one repository. Each client will probably have a default repository. Perhaps we might have some UI affordance for switching to a different repository -- the use case for this would be someone wanting to have both "home" and "work" repositories on one computer.
    • We assume that if you have logged in to your local machine, you have total access to the local repository i.e. we rely on the operating system to provide for local repository security.
    • An optional log in to Chandler and encryption of the local repository are both post Canoga features. Of course, Canoga repositories can be encrypted by the native operating system if such a feature is provided by the OS.

  • Communication with remote servers. For Canoga, remote servers refer primarily to Email (i.e. servers supporting the IMAP, POP, SMTP protocol) and Instant Messaging (XMPP/Jabber) servers. In Westwood time frame, LDAP and Calendar servers will also be required. In addition, third-party capplets may communicate with other servers such as web, web-services and NNTP servers. Decisions we have made to date:
    • The key requirements here are:
      • Ensure that passwords are not stored nor sent in the clear
      • Ensure that data content is also not sent in the clear and thus not prone to data sniffing attacks
    • We will always support TLS (SSL) as a transport where applicable
    • SASL will be the primary authentication framework supported. For Canoga, we will support the PLAIN (RFC 2595) SASL mechanism. For Westwood, we will add the GSSAPI (RFC 2078) mechanism
    • There will be some servers that will have no security requirements (e.g. polling web servers for most RSS feeds). We need to support such usage too. In Westwood, we will also need to provide central administrator mechanisms to set policies on access to such services (e.g. only allow communication to servers that support TLS)

  • Remote Repository access. This refers to a local Chandler client accessing Content Items stored in remote Chandler repositories. The closest analogy we have is a local machine accessing remote file servers on other machines. See CanogaSharingDesign20040419 [TBD] for more details.
    • Requirements:
      • What is shared? ItemCollection (and an associated view) and single Content Items
      • What permissions can a user have on what is shared?
        • Read-only
        • Edit i.e. read, write, create and delete
        • Owner/Admin: Above permissions and the ability to further give (or revoke from) other users any permissions on that collection
        • Re-publish: We might want to also have some notion of a "re-publish" right, so that I can share something with you and give you the ability to re-publish it to your friends, without my having to give you owner/admin rights to it.
      • A remote user (or potential sharer) is someone listed on the local Chandler's contacts with a unique id such as an email address or jabber id. The local Chandler user (administrator) can assign passwords to such remote users. We would like to provide mechanisms to autmatically discover peered Chandler users (e.g. via ZeroConf/Rendezvous). However, we need to ascertain the cost to implementing this feature before committing it to the Canoga plan [@@@ Dev]. Otherwise, remote users are to be discovered by the local user in an out-of-band fashion.
        • We need to provide a mechanism for remote users to change their own passwords (once they are authenticated with the old assigned password)
      • How is sharing initiated?
        • In most cases, the local user (administrator) will decide to share a view in Chandler. The administrator makes this view sharable, and assigns users (listed in her contacts) to three permission levels: read-only, edit and admin. The administrator can also assigns groups to the permission levels. Individual group members will have all the permissions assigned to the group. If a user is assigned to more than one permission level, the user will have the highest permission level granted to him/her.
        • Optionally, the administrator can elect to send emails notifying the remote users who have been given permission to share this view. The email can include a one-time keypad for first time remote users. This is a Canoga waitlist feature.
        • On receiving an email invitation (containing a remote URL) or receiving the remote URL in some other out-of-band mechanism, the remote user can access the administrator's newly shared view through the remote URL.
        • On first access of this URL in the current session, the remote user is prompted for his user name and password. On correct authentication, the remote client gains access to the item collection or Content item of the remote repository being shared.
        • Subsequent access to this URL does not require further authentication. Current session can defined as the running of the Chandler client in the same process or within X hours of access to the remote repository or both. We need more engineer input here [@@@ Dev]
        • Administrator should be able to control and revoke permissions to a particular view instantaneously either at the shared view or from the detailed view of an individual contact or group.
        • In Canoga, remote users can request for shared views only in an out-of-band fashion
      • Administrators should be able to view logs of remote access easily
      • Chandler should provide mechanisms to remember and auto-fill remote access passwords (much like modern browsers remember web site passwords). This ability can be turned off by a security policy (to support kiosk mode clients on campuses,for example)
      • Even if the repository in general is stored in the clear, passwords should be encrypted or hashed in some secure fashion
      • This description is dependent on Brian's analysis of our unified users and groups approach [@@@ Brian]

  • Code installation, propagation and sharing
    • We need to prevent malicious code to be installed as part of a third-party capplet/filter/agent
    • We need to prevent viruses and worms from propagating from Email and IM
    • We need to figure out our capplet extensibility and modularity strategy before answering the issues below [@@@ design]:
      • Will we support third-party Capplet sharing in Canoga?
      • Will we support filter sharing in Canoga?
      • Will we support agent sharing in Canoga?
    • We need more detailed email design and to hire an email developer to answer the following:
      • How will we prevent IM or Email worm/viruses in Canoga? esp:
        • Javascript vulnerabilities
        • Attachment handling
        • Email filters

Explicitly out of scope in Canoga:

  • Public Key and PKI support. By implication, the following will also not be required in Canoga:
    • S/MIME (Westwood requirement)
    • Automatic Secure Email

Next Steps:

  • Get Katie, Heikki, Jurgen to review documentation and add more detail and clarifications as necessary
  • Do a detailed step-by-step walkthrough and storyboard of a few representative scenarios. e.g.:
      • Mitch invites Esther to share his new calendar he has just set up
      • Esther wants to access Mitch's calendar for a second time
      • My wife requests access to my shopping list
  • Reconcile this doc with CanogaSharingDesign20040419 and CanogaUsersAndGroupsDesign? when these docs are ready
  • Find out cost for supporting Zeroconf and decide if this is in or out


Contributors

  • ChaoLam - 26 Dec 2003
  • BrianDouglasSkinner - 06 Jan 2004



Discussion

This makes it sound like if I'm subscribing to 500 people's vCards, then I need to have 500 accounts with 500 passwords on 500 machines. That's untenable. I'm never going to remember 500 passwords.

I don't have a good solution, either. It would be nice if there were a way for Chandler to keep my password somehow, but then it becomes more difficult to replicate my repository securely.

Chao: Added "remember password feature". Agree that there is a scaling issue involved here. Our full solution will have to wait for Westwood.

-- DuckySherwood - 27 Dec 2003


About preventing email worms etc.

  • We should disable JavaScript by default in Mail.
  • We might want to disable plugins in Mail (there are some insecure ones).
  • We might want to disable loading images & other external files from third party servers (fixes web bug).
  • We should never execute attachments automatically.

-- HeikkiToivonen - 02 Mar 2004

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r13 < r12 < r11 < r10 < r9 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.