handling of private events in kolab clients
martin.konold at erfrakon.de
Sat May 30 19:06:49 CEST 2009
On Monday 18 May 2009 10:14:42 Bernhard Reiter wrote:
> 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
> 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
From a MS point of view there is a difference between a private and a
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
- privacy flag
- IMAP administration rights which also represent effective control and
- 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
- 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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the format