NegativeArraySizeException in JGSS / SASL

[Hugh Cole-Baker]

Having done a bit more debugging, it looks like an oddity within Cyrus-SASL's
GSSAPI plugin. If no minimum security strength factor is specified for the
acceptor, it will allow integrity and privacy protection to be negotiated,
but it will just send 0 for the maximum recv size. If I add "minssf=1" to the
sasl-secprops setting on the OpenLDAP server, the server will send a max recv
size of 65536, the Java code can successfully communicate with the server,
and all is well.

Regards
Hugh

On 10 Feb 2013, at 15:39, Weijun Wang <weijun.wang at oracle.com> wrote:

> Hi Hugh
> 
> You can report a bug at http://bugs.sun.com/.
> 
> The problem seems to be at this line
> 
> > FINE: KRB5CLNT07:Client max recv size: 65,536; server max recv size: 0; rawSendSize: -69
> 
> where the server max recv size is 0. This is quite strange. I am thinking that a wrong packet is received.
> 
> Can you adjust the log level to FINER and send me the debug output? You can send it directly to me if you are afraid the mysterious hex data might contain anything sensitive.
> 
> Thanks
> Weijun
> 
> On 02/10/2013 09:54 PM, Hugh Cole-Baker wrote:
>> Hi there,
>> 
>> I'm running into an exception when trying to communicate with an OpenLDAP server
>> using SASL GSSAPI for authentication, with integrity and privacy protection
>> (i.e. with the javax.security.sasl.qop property set to auth-conf).
>> 
>> I think the problem may be related to the SASL client
>> (com.sun.security.sasl.gsskerb.GssKrb5Client) negotiating a negative rawSendSize
>> value which is then used as an array length. If I turn on FINE logging I see:
>> 
>> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
>> FINE: SASLIMPL01:Preferred qop property: auth-conf
>> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
>> FINE: SASLIMPL02:Preferred qop mask: 4
>> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
>> FINE: SASLIMPL03:Preferred qops : 4 0 0
>> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
>> FINE: SASLIMPL04:Preferred strength property: null
>> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
>> FINE: SASLIMPL05:Cipher strengths: 4 2 1
>> com.sun.security.sasl.gsskerb.GssKrb5Client <init>
>> FINE: KRB5CLNT01:Requesting service name: ldap at dir-1.dev.local
>> com.sun.security.sasl.gsskerb.GssKrb5Client doFinalHandshake
>> FINE: KRB5CLNT06:Server protections: 7
>> com.sun.security.sasl.gsskerb.GssKrb5Client doFinalHandshake
>> FINE: KRB5CLNT07:Client max recv size: 65,536; server max recv size: 0; rawSendSize: -69
>> com.sun.security.sasl.gsskerb.GssKrb5Client doFinalHandshake
>> FINE: KRB5CLNT08:Selected protection: 4; privacy: true; integrity: true
>> Exception in thread "main" java.lang.NegativeArraySizeException
>> 	at sun.security.jgss.krb5.CipherHelper.aes256Encrypt(CipherHelper.java:1367)
>> 	at sun.security.jgss.krb5.CipherHelper.encryptData(CipherHelper.java:722)
>> 	at sun.security.jgss.krb5.WrapToken_v2.<init>(WrapToken_v2.java:200)
>> 	at sun.security.jgss.krb5.Krb5Context.wrap(Krb5Context.java:861)
>> 	at sun.security.jgss.GSSContextImpl.wrap(GSSContextImpl.java:385)
>> 	at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(GssKrb5Base.java:103)
>> 	at com.sun.jndi.ldap.sasl.SaslOutputStream.write(SaslOutputStream.java:89)
>> 	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:428)
>> 	at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:547)
>> (cut..)
>> 
>> I've been able to cut down the test case to a simple program which logs in using
>> JAAS to obtain a Kerberos ticket, then tries to connect to the LDAP server via
>> JNDI, using GSSAPI for security, and tries to perform an LDAP search. With this
>> test case I've been able to reproduce the bug on OpenJDK 7 on Ubuntu 12.04
>> (package version 7u9-2.3.4-0ubuntu1.12.04.1) and Oracle's JDK for Mac 1.7.0_13.
>> I have also tried the EA build of JDK 8 for Mac from Oracle
>> (b76-macosx-x86_64-07_feb_2013) which shows the same problem.
>> 
>> All the systems I've been testing on are part of a Kerberos realm with a MIT
>> Kerberos KDC (v 1.10) and the JREs I've been testing have the unlimited-strength
>> cryptography policies installed, which means they're able to use AES-256
>> encryption types in Kerberos (apart from JDK 8 since I couldn't find a
>> download for the policy files for that one).
>> 
>> I'm not sure if this is a bug in OpenJDK or something to do with my test
>> environment- I can attach the test case if necessary. If it is a bug in OpenJDK,
>> what's the best place to report it? I checked on http://openjdk.java.net/ but
>> couldn't find a link to a public bug tracker.
>> 
>> Regards
>> Hugh
>>