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

Ken Hornstein <[email protected]>
Newsgroups gmane.comp.security.cyrus.sasl
Message-ID <[email protected]>
>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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.