[Kolab-devel] handling of private events in kolab clients

[Martin Konold]

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://lists.kolab.org/pipermail/devel/attachments/20090530/ee5c25a0/attachment.html>