problems with clients and cyrus-sasl-2.1.22

[Andreas Hasenack]

On Wed, May 24, 2006 at 10:16:05PM -0300, Andreas Hasenack wrote:
> On Tuesday 23 May 2006 19:50, Huaqing Zheng wrote:
> > I'm having some problems with clients linked against Cyrus SASL
> > 2.1.22.  Running imtest linked against 2.1.22 against an cyrus-imapd
> > server (also linked against 2.1.22) with GSSAPI authentication shows:
> >
> > C: A01 AUTHENTICATE GSSAPI BLAHBLAHBLAH
> > S: + BLAHBLAHBLAH
> > Authentication failed. generic failure
> > Security strength factor: 0
> 
> I just found out I'm having the same exact problem, but not will all clients: 
> just cyrus' own clients such as imtest.
> 
> > and this in the imap logs:
> > May 23 15:48:01 pobox09 imap[26261]: badlogin: pobox09.stanford.edu
> > [171.67.22.15] GSSAPI [SASL(0): successful result: security flags do
> > not match required]
> >
> > Same happens with Kerberos 4.  PLAIN and LOGIN both work fine, which
> > indicates that saslauthd is running fine against GSSAPI.  Note that
> > running the 2.1.22 client against a 2.1.21 server gives the same thing
> > whereas running the 2.1.21 client against the 2.1.22 server is working
> > fine.
> 
> I tried gssapi, digest-md5 and cram-md5,  none work. Login (both imap login 
> and sasl login) and plain do work.

Here a sample session with the "base64 decoding error":
$ imtest -m digest-md5 localhost S: * OK pandora.conectiva Cyrus IMAP4 v2.2.12-Mandriva-RPM-2.2.12-22mdk server ready C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=GSSAPI AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR LISTEXT LIST-SUBSCRIBED X-NETSCAPE
S: C01 OK Completed
C: A01 AUTHENTICATE DIGEST-MD5
S: + bm9uY2U9IkVZMEI5anR4NlNsc0tQSGhHTGovNmI4WW1qQ3BadDZCL1RGUXAva21kUEU9IixyZWFsbT0icGFuZG9yYS5jb25lY3RpdmEiLHFvcD0iYXV0aCxhdXRoLWludCxhdXRoLWNvbmYiLGNpcGhlcj0icmM0LTQwLHJjNC01NixyYzQsZGVzLDNkZXMiLG1heGJ1Zj00MDk2LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
base64 decoding error
Authentication failed. generic failure
Security strength factor: 0
C: Q01 LOGOUT
Connection closed.

At first glance, this base64 strings seems valid:
$ ./b64.py -d bm9uY2U9IkVZMEI5anR4NlNsc0tQSGhHTGovNmI4WW1qQ3BadDZCL1RGUXAva21kUEU9IixyZWFsbT0icGFuZG9yYS5jb25lY3RpdmEiLHFvcD0iYXV0aCxhdXRoLWludCxhdXRoLWNvbmYiLGNpcGhlcj0icmM0LTQwLHJjNC01NixyYzQsZGVzLDNkZXMiLG1heGJ1Zj00MDk2LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
nonce="EY0B9jtx6SlsKPHhGLj/6b8YmjCpZt6B/TFQp/kmdPE=",realm="pandora.conectiva",qop="auth,auth-int,auth-conf",cipher="rc4-40,rc4-56,rc4,des,3des",maxbuf=4096,charset=utf-8,algorithm=md5-sess

But openssl's base64 can't decode the string, so perhaps there is something
wrong:
$ echo -n bm9uY2U9IkVZMEI5anR4NlNsc0tQSGhHTGovNmI4WW1qQ3BadDZCL1RGUXAva21kUEU9IixyZWFsbT0icGFuZG9yYS5jb25lY3RpdmEiLHFvcD0iYXV0aCxhdXRoLWludCxhdXRoLWNvbmYiLGNpcGhlcj0icmM0LTQwLHJjNC01NixyYzQsZGVzLDNkZXMiLG1heGJ1Zj00MDk2LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz | openssl base64 -d
$

If I query this same server from another machine with previous sasl, it works.
I'll try now downgrading sasl.