handling of private events in kolab clients

[Mike Gabriel]

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: ?ffentlicher PGP-Schl?ssel
URL: <http://lists.kolab.org/pipermail/users/attachments/20090602/439d3c9b/attachment.bin>