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/