>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
