handling of private events in kolab clients

[Martin Konold]

On Tuesday 02 June 2009 08:28:30 Mike Gabriel wrote:

Hi Mike,

> this is indeed very good news!!! i must admit i haven't had a spot on
> the konsec connector yet.
>
> please provide me with a preview download URL, so i can catch up on this...

http://download.konsec.com/beta/KONSEC_Konnektor_2_3_0_16_de_ALPHA.zip

Please  note that this version ist not officially released and does not 
encrypt the private data. It only denies Outlook access to the private 
properties.



> > As a next step I will come up with a proposal how to properly improve the
> > current system using proper encryption.
> >
> > The current implementation relies upon enforcement of the access control
> > to private objects in the MAPI Storage Provider. From the point of view
> > of Outlook this MAPI Storage Provide is a server but from a security
> > point of view the MSP is still running in the context of the client
> > workstation not of the Kolab server.
> >
> > IMHO this simple Exchange compatible approach is already a big
> > improvement compared to simply not addressing this issue. I expect a
> > number of people are already fine with this implementation. (****)
> >
> > In the future I want to have proper cryptographic methods used.
> > Though this is
> > not trivial to get right.
> >
> > - Owners of a private object are all those Kolab users with adminstrative
> > privileges on the corresponing folder.
> >
> > - Only Owners can create, copy, move and delete private objects.
> >
> > - If non-Owners with write permissions create such objects they
> > effectivly either loose control (what MS Exchange does) or the flag is
> > removed by the Connector/Konnektor when storing. The Middleware might
> > decide to warn the user
> > about this.
> >
> > - Private properties within a private object are encrypted  and decrypted
> > using a folder specific symmetric key.
> >
> > - Only Kolab users with
> >
> > - The distribution/maintenance of this symmetric(***) key is non-trivial
> >
> > - The basic idea is that the folder specific symmetric key is ONLY
> > available to those users with administration priviledges on this folder.
> > (I am currently
> > not sure how this is implemented best) (*)
> >
> > - Whenever someone is removed from the list of users with administrative
> > priviledges from the folder ALL private objects need to be reencrypted
> > with a newly created symmetric key. (**)
> >
> > (*) I am wondering how this is to be implemented.
> > The main point is that this is slowly changing folder specific
> > information which shall only be available to users with adminstrative
> > priviledges. Does anyone have a great idea how this can be implemented?
> >
> > (**) Due to the inherent incoherent nature of Kolab (offline clients
> > etc.) we must beware of race conditions and provide a mechanism to avoid
> > these. (This is solvable though!)
> >
> > (***) Choosing a symmetric key method is simple but has some drawbacks.
> > E.g. it does not protect from a malicious server/backup administrator. I
> > consider this acceptable though as long as it is well documented.
> >
> > (****) Of course the current implementation can trivially be
> > subverted using a
> > client which does not honour the privacy flag. As a first step I will
> > therefore ask the KONSEC developers to encrypt all private properties
> > using a single static key (no key management in the first step). This
> > denies access to
> > all non complying clients. Extraction of this hidden key from the
> > proprietary Konnektor is possible though really not trivial.
> >
> > I am looking forward to your feedback.

Yours,
-- martin

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20090602/13cee0db/attachment.html>