Compatibility between Cyrus-SASL C GSSAPI Plugin and Java SASL GSSAPI

[Ken Hornstein]

>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