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

[Ken Hornstein]

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

I'm sorry, that is simply not correct.  From RFC 2222, §3:

   If use of a security layer is negotiated, it is applied to all
   subsequent data sent over the connection.  The security layer takes
   effect immediately following the last response of the authentication
   exchange for data sent by the client and the completion indication
   for data sent by the server.  Once the security layer is in effect,
   the protocol stream is processed by the security layer into buffers
   of cipher-text.  Each buffer is transferred over the connection as a
   stream of octets prepended with a four octet field in network byte
   order that represents the length of the following buffer.

It's the EXACT same protocol as appears in RFC 4422.

>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.

My reading of that documentation is whomever calls unwrap() is
responsible for reading the 4-byte length, stripping it out (or
specifying an appropriate offset), and calling unwrap() with a single
data buffer.  If this is YOUR code on the server side, then that's a bug
with your code.

You may be getting confused by the differing APIs between Java SASL and
Cyrus-SASL.  The Cyrus-SASL sasl_encode()/sasl_decode() routines handle
the length and packet parsing for you; you can pass it arbitrary data
and it takes care of those messy details.  It seems like the Java SASL
routines require you to break up the data into packets and handle the
length header yourself.

>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 ?

At least on the Cyrus-SASL side, you can retrieve the SASL_MAXOUTBUF
property, and you're supposed to set "maxbufsize" in the security
properties to the maximum amount of data you'll ever read in from the
network.  As part of SASL negotation, SASL_MAXOUTBUF gets set to
what the other side expects, and you can't call sasl_encode() with
something greater than that.

--Ken