From m.gabriel at das-netzwerkteam.de Tue Jun 2 08:28:30 2009 From: m.gabriel at das-netzwerkteam.de (Mike Gabriel) Date: Tue, 02 Jun 2009 08:28:30 +0200 Subject: handling of private events in kolab clients In-Reply-To: <200905301906.51135.martin.konold@erfrakon.de> References: <20090511184740.54005x2xd8dk6u98@mail.das-netzwerkteam.de> <200905181014.43286.bernhard@intevation.de> <200905301906.51135.martin.konold@erfrakon.de> Message-ID: <20090602082830.14247htaon3m57da@mail.das-netzwerkteam.de> hi martin, 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... best and thanks for your initiative, mike On Sa 30 Mai 2009 19:06:49 CEST Martin Konold wrote: > On Monday 18 May 2009 10:14:42 Bernhard Reiter wrote: > > Hi Mike, > Hi Bernhard, > >> On Monday 11 May 2009, Mike Gabriel wrote: >> > could there be an intermediate solution (hiding event details in the >> > Outlook GUI)? >> >> No, this wouldn't be secure. > > Well, the current situation (since years!) is that Outlook users with a Kolab > server can set the privacy flag in the UI but it is not honoured in the UI > when the event is read by someone else. > > This against the intuitive expectation of our users and a disadvantage of > Kolab compared to MS Exchange. > >> Data that needs to be kept secure from the client must not be >> transfered to the client in the first place. > > This is not entirely true. It is sufficient of the client cannot decrypt the > private data. > >> Just hiding stuff in the user interface (like Outlook does at least in >> some versions as far as I know) is not a real solution. > > Well, it is better than nothing and helps to protect the privacy in a > practical manner. > > From a MS point of view there is a difference between a private and a > confidential message. > > I therefore asked the KONSEC developers to implement the privacy > functionality > with an Exchange compatible semantic in the KONSEC Konnektor in order to gain > a real world feeling about the feasability of this task. > > In the meantime they delivered a preview version of the KONSEC > Konnektor which > offers support for the privacy feature. > > KONSEC also plana to release this to the public in the future. > > Anyone interested in having a look at the preview may write me a > personal mail > and I will provide you with a download URL. > > Currently this version of the KONSEC Konnektor (which is a MAPI Storage > Provider) denies Outlook access to the protected elements of a MAPI object > according to: > > - privacy flag > - IMAP administration rights which also represent effective control and > ownership (ACL) > - IMAP read permission (ACL) > - IMAP write permission (ACL) > > If the privacy flag is set and the user is lacking ownership the MAPI Storage > Provider denies Outlook access to the private properties (texts etc.) while > allowing access to public properties like begin and end datetime and also > denies changing/copying/moving of the private object. (This is equivalent to > how the privacy flag is handled by OL/EX) > > 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/ > -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 eMail-LeseSchreibStunde: wochentags 8h-10h mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-keys Size: 19650 bytes Desc: =?utf-8?b?w5ZmZmVudGxpY2hlciA=?= =?utf-8?b?UEdQLVNjaGzDvHNzZWw=?= Url : http://kolab.org/pipermail/kolab-format/attachments/20090602/439d3c9b/attachment.bin From martin.konold at erfrakon.de Tue Jun 2 14:17:45 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Tue, 2 Jun 2009 14:17:45 +0200 Subject: handling of private events in kolab clients In-Reply-To: <20090602082830.14247htaon3m57da@mail.das-netzwerkteam.de> References: <20090511184740.54005x2xd8dk6u98@mail.das-netzwerkteam.de> <200905301906.51135.martin.konold@erfrakon.de> <20090602082830.14247htaon3m57da@mail.das-netzwerkteam.de> Message-ID: <200906021417.46948.martin.konold@erfrakon.de> 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://kolab.org/pipermail/kolab-format/attachments/20090602/13cee0db/attachment.html