From m.gabriel at das-netzwerkteam.de Mon May 11 18:47:40 2009 From: m.gabriel at das-netzwerkteam.de (Mike Gabriel) Date: Mon, 11 May 2009 18:47:40 +0200 Subject: handling of private events in kolab clients Message-ID: <20090511184740.54005x2xd8dk6u98@mail.das-netzwerkteam.de> hi there, bernhard suggested asking the following question on the list: what is the status of this issue: https://www.intevation.de/roundup/kolab/issue1041 i read through a couple of kolab-format postings in the archive but recently (subscribed since 20080820) it seems there has been little progress concerning private events. could there be an intermediate solution (hiding event details in the Outlook GUI)? regards, mike -- 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 sunweavers.net, http://www.sunweavers.net 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/20090511/9774c4ab/attachment.bin From bernhard at intevation.de Mon May 18 10:14:42 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 18 May 2009 10:14:42 +0200 Subject: handling of private events in kolab clients In-Reply-To: <20090511184740.54005x2xd8dk6u98@mail.das-netzwerkteam.de> References: <20090511184740.54005x2xd8dk6u98@mail.das-netzwerkteam.de> Message-ID: <200905181014.43286.bernhard@intevation.de> 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. Data that needs to be kept secure from the client must not be transfered to the client in the first place. 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. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-format/attachments/20090518/224bdaba/attachment.bin From martin.konold at erfrakon.de Sat May 30 19:06:49 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Sat, 30 May 2009 19:06:49 +0200 Subject: handling of private events in kolab clients In-Reply-To: <200905181014.43286.bernhard@intevation.de> References: <20090511184740.54005x2xd8dk6u98@mail.das-netzwerkteam.de> <200905181014.43286.bernhard@intevation.de> Message-ID: <200905301906.51135.martin.konold@erfrakon.de> 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://kolab.org/pipermail/kolab-format/attachments/20090530/ee5c25a0/attachment.html