add shared secret auth capabilities to kolab-saslauthd and support at least CRAM-MD5
Closed, ResolvedPublic


Due to a seamless migration of a few thousand fat client users from a very different mail system to kolab
we need imap authentication with shared secret supporting at least CRAM-MD5 mech.

We thought about some other ways to go to do the fat client user/settings migration but non of them was
as painless as getting kolab-saslauthd supporting shared secret auth with at least mech CRAM-MD5.

We know that this requires plaintext passwords stored on the auth backend, because that's how it works now.
For some other reason/tool authentications this will be required in future anyway so it's not making a big
difference here.


Ticket Type

Event Timeline

The suggested solution (to support CRAM-MD5 or DIGEST-MD5 in kolab-saslauthd) is very likely not the most efficient solution.

In fact, even if a very narrow and specific set of circumstances is already met by currently available, server-side infrastructure, the details matter and severely influence large code structures.

I would be very interested in the details of the research performed, that allowed you to determine CRAM-MD5 support in kolab-saslauthd was the least painful option to pursue -- normally, I'm the one to make such a determination, so I'm interested in your thoughts.

We are fully aware of the fact, that kolab-saslauthd is not a full implementation but based on this RFC our request is just to get kolab-saslauthd closer to this.
And based on the second point of weeknesses explaination, based on RFC 2104, it could be possible to add some security too.

I didn't say the last but the easiest.
The options we thought about:

  1. reconfigure about 40k fat client configurations either at first use or on one big change action and add a lot capacity to user support if fat client reconf didn't do
  1. change auth from kolab-saslauthd to cyrus-saslautd with auxprop and ldapdb pwcheck_method: auxprop auxprop_plugin: ldapdb mech_list: PLAIN LOGIN DIGEST-MD5 CRAM-MD5 ldapdb_uri: ldap://ladpserver.domain.tld ldapdb_id: proxyuser ldapdb_pw: proxy_secret ldapdb_mech: DIGEST-MD5 ldapdb_starttls: try
  1. change auth from kolab-saslauthd to cyrus-saslautd with saslauthd and rimap to authenticate against the old imap server
  2. write and deploy a tool/script reconfiguring all fat client configs
  3. add shared secret auth to kolab-saslauthd with at least CRAM-MD5 mech

-> 1) high user impact very many involved individuals
-> 2) big change in system design here with some big risks in LDAP capabilities (associatedDomain)
-> 3) never tried and needs reconfiguration after removal of the old mail server
-> 4) useless one time time & money invest for an only use once solution with risks very closed to 1)
-> 5) invest time & money to develop kolab-saslauthd to support more functions of RFC 4422 under special considerations of RFC 2104 even the security question is not such a big thing anymore

The time for each of those options seam to be very closed together whereas we can not say how much time and effort option 5 would take.

Do you have some other suggetions on how to switch those up to 40k user accounts on oune big bang?
We need a big bang because of some aspects of the current individual mail, mailinglist and group mailing routes prohibit a block by block migration with some kind of mail dispatch gateway.

We will take under consideration, the need to support an existing desktop client already configured with CRAM-MD5 -- all implications included.

However, we also need to consider the development path to any solution provided, and the path to carrying such solution forward.

We'll take this under consideration and discuss.

vanmeeuwen closed this task as Resolved.Jun 18 2016, 9:01 AM
vanmeeuwen claimed this task.

The proposed solution for enabling CRAM-MD5 and DIGEST-MD5 based authentication is documented here: