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/
Attachment:
signature.asc
Description: This is a digitally signed message part.