[Dev] Canoga Security Design

[Ben Laurie]

Chih-Chao Lam wrote:

> I've written up a design document on our security framework plans for  
> Canoga thus far. Appreciate your comments on the wiki page or on this  
> list.
> 
> <http://wiki.osafoundation.org/twiki/bin/view/Chandler/ 
> CanogaSecurityDesign>

>     *  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:
>           o The key requirements here are:
>                 + Ensure that passwords are not stored nor sent in the clear

Not storing passwords in the clear is generally a lost cause, since you 
have to decrypt them to use them. Not that it hurts, but the security 
value is minimal, especially in an application where they will be in 
constant use.

BTW, are you aware that the standard Jabber server stores your passwords 
clear?

>                 + Ensure that data content is also not sent in the clear and thus not prone to data sniffing attacks
>           o We will always support TLS (SSL) as a transport where applicable
>           o SASL will be the primary authentication framework supported. For Canoga, we will support the PLAIN (RFC 2595) SASL mechanism.

This allows the authenticator to masquerade as the authenticee, which 
strikes me as a very bad thing in a peer-to-peer system.

 >  For Westwood, we will add the GSSAPI (RFC 2078) mechanism

GSSAPI is an API, not a SASL mechanism.

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

It isn't entirely clear what you mean here, but the value of a one-time 
pad that's communicated over an insecure channel is pretty minimal.

> Explicitly out of scope in Canoga:
> 
>     * Public Key and PKI support. By implication, the following will also not be required in Canoga:

Errr ... so how are you going to use TLS, then?

I notice there's no meat at all in the code sharing section, which 
strikes me as the most important and interesting security issue.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff