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

[Sorabh Hamirwasia]

Hi Ken,

Thanks for sharing the details. It looks like Java implementation is following RFC2222 instead and hence the difference in format.


https://docs.oracle.com/javase/8/docs/api/javax/security/sasl/SaslClient.html#unwrap-byte:A-int-int-

incoming is the contents of the SASL buffer as defined in RFC 2222 without the leading four octet field that represents the length. offset and len specify the portion of incoming to use.



Also I see we need to set maxBufSize in sasl_security_properties_t which is capped at 0XFFFFFF (for gssapi) if negotiated for auth-conf. From my understanding this parameter (after negotiation) regulates the maximum size of the encoded buffer which sasl_encode function will return. If yes then does application knows about the maximum plain text size by maxoutbuf in sasl_out_params, which they can pass to the encode function so that resulting encrypted payload doesn't exceed the maxBufSize ?



Thanks,

Sorabh

________________________________
From: Ken Hornstein <kenh at cmf.nrl.navy.mil>
Sent: Tuesday, March 21, 2017 6:08:11 PM
To: Sorabh Hamirwasia
Cc: cyrus-sasl at lists.andrew.cmu.edu
Subject: Re: Compatibility between Cyrus-SASL C GSSAPI Plugin and Java SASL GSSAPI

>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20170323/cf1a9bc7/attachment.html>