[Dev] Canoga Security Design

[Chih-Chao Lam]

Hi Ben,

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 
file system?

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

<http://www.ietf.org/rfc/rfc2222.txt>
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 
> minimal.
>
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.

See <http://wiki.osafoundation.org/twiki/bin/view/Jungle/DataSharing> 
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 
features.

> 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://wiki.osafoundation.org/twiki/bin/view/Chandler/SecurityFramework

Thanks again,
chao

> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>

______________________________
Chao Lam
Open Source Applications Foundation
http://blogs.osafoundation.org/chao