Hi all. During the initial implementation of the evolution-kolab plugin, we were concerned with using hardware crypto devices (TPM, trusted platform module) as a means to store and retrieve client certificates for securing TLS connections to a Kolab server (by configuring the Kolab server to require certificates for client authentication).
We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS.
These are protocols handled by Camel and the underlying NSS library. In order
to access the crypto token, we needed to supply a token PIN, which we were not
able to pass from Evo to E-D-S in version 2.30 as "live" data (pass-and-
forget). So we had to use a fake implementation: we store the user PIN along
the rest of the account data and reading it in the backend via ESource.
Clearly, this violates security (and we are saying to in our user manual), but
it demonstrates that in principle, things are working. To get this thing
right, we would need a means to ask for a security pin from within the
backend, presenting a dialog to the user (not necessariy via Evo, maybe the
new ESources and account management stuff Matt is working on could help with
that). We've succeeded here _only_ since Camel uses the Mozilla NSS lib for
securing connections.
However, there is one protocol, for which we failed to implement any
demonstrator for client-certificate-based authentication using a hardware
crypto device: LDAPS. The implementation in Evo uses the OpenLDAP lib as a
protocol implementation, which in turn uses GnuTLS for security (version 2.1x
< 2.12 at that time). The combination of OpenLDAP and GnuTLS did not allow us
to get things flying regarding the use of hardware crypto devices via the PKCS
#11 interface. Where NSS only needs a token PIN and figures out either
automatically or via external configuration files which of the possibly
multiple client certificates to use, GnuTLS needs an URI which fully
determines exactly which location inside the token to read the client
certificate from, no automatisms here. While this allows for the application
to control which cert to use (and not relying on any automatism, which may or
may not work as needed), it requires the application to do it. Now, if on top
of GnuTLS sits some protocol library like OpenLDAP, which rightfully denies to
be bothered with security details of the underlying transport lib, we've got a
problem: we must break the strict top-down layer approach and configure GnuTLS
first, then use the protocol lib like OpenLDAP. We would have needed to hack
around this directly in Evo to solve this, which clearly was (and probably is)
out-of-scope for the evolution-kolab project.
My question now is, how are the plans for Evo and E-D-S to handle these
things, mid-term and long-term? Are there plans to favor any single one
security lib, or will there be a multitude of different libs be used? GnuTLS
is sort of home-made, while NSS is alien but works for the issue described
above (which, admittedly, is a little esoteric, but *maybe* symptomatic?). In
GnuTLS, I've seen much progress with PKCS #11 (like the integration of p11-
kit), but it requires more details to be handled by the application itself.
I'm looking forward to reading your input,
Kind regards,
Christian
--
kernel concepts GbR Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
