Subject: Re: SASL (RFC 4422) to draft questionnaire

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Oct 2008 11:35:55 +0100

Chris Newman wrote:

> Here's a proposed questionnaire for an implementation report.
>
> I am not volunteering to compile responses to the questions, but I am 
> willing to answer these questions for my implementations.
>
>         - Chris

Ok, here are my responses (shamelessly copied from Chris' response and 
modified accordingly).

> ---
> RFC 4422 Implementation Questionnaire
> ===============================================
> 0. Contact and Description
> Organization Name:

Isode Limited (implementation A - plugin based generic SASL implementation)
MessagingDirect (implementation B - plugin based generic SASL 
implementation)
Epsylon Technologies (implementation C)

> Implementation (Software or Service) Name:

CMU SASL (implementation A)

> 1. Have you implemented SASL and/or SASL mechanism?

Yes. I've implemented CRAM-MD5 in Epsylon Technologies' SMTP servers 
(implementation C) and IDK mail client library (both written in Delphi).

I've implemented/maintained client and server DIGEST-MD5 plugin in CMU 
SASL (implementations A) and implementation B [variants of the same 
implementation].
I've updated/maintained GSSAPI client and server side plugin in 
implementation B and maintained implementation B in general.

I've integrated CMU SASL into SMTP, IMAP, POP, ManageSieve and LDAP 
servers (with some help from my Isode co-workers).
I've integrated CMU SASL into an IMAP client.
My co-worker Dave Cridland implemented hardcoded SASL EXTERNAL client 
and server implementation in Isode's XMPP server (for server-to-server 
traffic).

I am also a co-editor of the latest SMTP AUTH document revision and 
reviewed use of SASL in XMPP.

> 1.5. Is your implementation of SASL derived from, or dependent upon, 
> any  other implementation (such as a SASL library)?  If so, explain.

Isode is using a fork (around 2004) of CMU SASL with some changes.

> 2. Which SASL mechanisms have you implemented?

The following SASL mechanism included in CMU SASL (implementation A) are 
used by Isode:
PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, NTLM, GSSAPI, EXTERNAL.

Isode also has a standalone SASL EXTERNAL implementation.

Implementation B had:
PLAIN, CRAM-MD5, DIGEST-MD5, GSSAPI

Implementation C:
CRAM-MD5

All implementations included both client side and server side 
implementations of various SASL mechanisms.

> 3. For how long has it been deployed?

CMU SASL is older than 10 years.
MessagingDirect SASL library is also older than 10 years.

For Isode products:
SMTP AUTH is available since early 2003.
LDAP authentication is available since late 2003.
IMAP/POP/ManageSieve authentication is available since around 2005.

> 4. What features have NOT been implemented from SASL?

SASLPrep - this requires quire a bit of effort to build various tables, etc.

SASL security layers *are* implemented in Isode's IMAP/POP server. Some 
mail clients (in particular Apple Mail) can use GSSAPI security layer.
Also note that Isode's IMAP/POP servers implement stacking of SASL 
security layers with TLS, even though it doesn't look like this is used 
by any clients.

The IMAP client doesn't check for a mechanism list modified by an 
attacker, so it doesn't close the connection (a SHOULD in RFC 4422).

Isode's ManageSieve server never emits "additional data with success". 
But Isode's LDAP server uses this feature.

> 5. What features of SASL or SASL mechanisms are problematic for your 
> implementation?

See answers to question 4.

> **6. Please add any other comments you wish to share:

Isode's IMAP server also implements SASL-IR (SASL initial response 
extension).

We have not implemented SASLprep because we have no customer demand for it.

SASL EXTERNAL is implemented in server-to-server XMPP, but it is not 
clear if other XMPP servers are actually using it.

We continue to advertise the non-standard LOGIN mechanism in SMTP as it 
is used by Outlook Express (and probably Outlook).
This mechanism is also advertised in all other Isode servers, whenever 
PLAIN is also advertised.

SASL proxy authentication feature is used for management of user's mail 
over IMAP.

We had some minor problems with DIGEST-MD5 interoperability. We disable 
DIGEST-MD5 reauthentication due to code thread safety concerns. It is 
not clear if any clients are using this feature. DIGEST-MD5 security 
layer doesn't seem to be interoperable/used.

"Additional data with success" used to cause problems in LDAP: an older 
version of OpenLDAP (client side) was unable to cope with this (fixed in 
a later version), while LDAP Administrator were unable to work without 
this feature. (LDAP Administrator we've tested in Isode was using 
Microsoft LDAP API, so it might have been a problem with the Microsoft 
LDAP library.)

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 11 Oct 2008 12:46:01 -0600

> clear if other XMPP servers are actually using it.

SASL EXTERNAL is implemented in other XMPP servers but AFAIK has not yet
been widely tested. The XMPP Standards Foundation plans to organize some
testing of this feature in the next few months as we work to improve the
security of the XMPP network.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/