Andreas Hasenack wrote:
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
Ah, I've fixed base64 decode function ;-). This might have broken imtest.
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.
Dave Cridland is correct, openssl has an issue with line length. You
need to insert CRLFs before decoding the value.
