>sasl_encode called by client internally calls the sasl_gss_encode >api present in gssapi.c which calls the gss_wrap api. After the >gss_wrap gives back the encrypted data the sasl_gss_encode is putting >extra 4 bytes in front of the encrypted data and gives that back to >application. Whereas on server side (which is running on Java) it >doesn't expects those 4 bytes and hence fails. I did a test by ignoring >first 4 bytes sent from client to server before calling unwrap and then >it's working fine. It looks to me that Java is getting it wrong. From RFC 4422, §3.7: Each buffer of protected data is transferred over the underlying transport connection as a sequence of octets prepended with a four- octet field in network byte order that represents the length of the buffer. Those 4 bytes are supposed to be there. From my (limited) testing, other SASL implementations interoperate with the Cyrus-SASL GSSAPI mechanism. --Ken
