Thanks for the deep analysis. I think we should also make OpenJDK a
little more friendly here. Either report an error early or ignore the 0
maximum recv size. We'll see which is better.
*Vinnie*: which do you prefer?
Thanks
Weijun
On 02/11/2013 07:00 AM, Hugh Cole-Baker wrote:
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
