problems with clients and cyrus-sasl-2.1.22

[Alexey Melnikov]

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.