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 <[email protected]> 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: [email protected] >> 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 >>
