[Dev] Canoga Security Design
chao at osafoundation.org
Sat Jan 3 10:31:27 PST 2004
Thanks for your very helpful and timely response. I'm obviously no
security expert, so such feedback from the community was exactly what
we were hoping for. Questions and comments below.
On Jan 3, 2004, at 6:00 AM, Ben Laurie wrote:
> 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?
This is a new insight to me and good to know. When is there minimal
value? When an attacker has a few minutes of physical access to your
>> + 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
>> o SASL will be the primary authentication framework
>> supported. For Canoga, we will support the PLAIN (RFC 2595) SASL
> This allows the authenticator to masquerade as the authenticee, which
> strikes me as a very bad thing in a peer-to-peer system.
We're adopting just for server (e.g. IMAP, SMTP, POP) authentication.
Does this still pose a problem?
Can you explain how an authenticator can masquerade as the authenticee?
and its ramifications?
> > For Westwood, we will add the GSSAPI (RFC 2078) mechanism
> GSSAPI is an API, not a SASL mechanism.
I'm just referring to the SASL RFC 2222 where it states:
7.2. GSSAPI mechanism
The mechanism name associated with all mechanisms employing the
GSSAPI [RFC 2078] is "GSSAPI".
Is it clearer just to say Kerberos v5 support?
>> # 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
This is more a convenience feature to communicate a password between
sharer and sharee in-band rather than out of band and to verify that an
email invitation to share is going to the right email address, and then
to allow the recipient to change passwords. When an email invitation to
share is generated by Chandler, it includes an obfuscated Chandler URL
that is only active on first use. On this first use, the user is then
asked to choose a password.
under Obfuscated URLs for more details.
>> * 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?
Yeah, this wasn't clear. I meant no end-user visible public key
> I notice there's no meat at all in the code sharing section, which
> strikes me as the most important and interesting security issue.
Well, we have to start somewhere :) We'll be dealing with these issues
after we finalize on our capplet extensibility and modularity framework
and after we hire a good email developer? Any leads?
Also, see Heikki's Security Framework paper for an high-level scoping
of some of the issues:
> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
Open Source Applications Foundation
More information about the Dev