Ignore my ramblings, I have just checked the code at the tip for OpenJDK
9 and I find the changes I think need making to earlier versions have
already been made for 9 ;-)
From 9 the encryption type of the session key is no longer taken into
account and instead the encryption type of the enc part is and a
NULL_KEY used only when appropriate otherwise the session key is used.
Regards,
Darran Lofthouse.
On 11/09/14 16:48, Darran Lofthouse wrote:
Hello there, I am currently attempting to get to the bottom of some
interoperability issues regarding the handling of Kerberos AP_REQ
messages that contain a delegated credential.
Before I start raising bug reports I wanted to pass it through you guys
first in case there is a strong opposition to this being raised as a
Java bug.
The kind of error messages I am seeing are: -
http://fpaste.org/132824/
http://fpaste.org/132825/
In short the class 'sun.security.jgss.krb5.InitialToken' is making an
assumption as to if the enc type for the delegated credential is NULL
based on the enc type of the session key.
If I follow through the call to the constructor in
'sun.security.krb5.KrbCred' there is even a comment saying the key will
always be NULL even though that is no longer true so it looks like this
block of code has been modified at some point to start to support an
EncryptionKey.
The reason this is a problem is that I have Mac OS clients that will
always use NULL regardless of the algorithm for the session key, I also
have Linux clients that will use the session key regardless of the
algorithm.
After researching this I am yet to find anything that tells me the
algorithm for the session key should affect if the credential is
encrypted which is why I am questioning if that is a valid approach.
My proposal would be to update the code within InitialToken to skip
trying to decide to use EncryptionKey.NULL_KEY, instead just keep the
try / catch block for the key and sub-key. Within
sun.security.krb5.KrbCred just before decrypt is called it would be
possible to check the encType and check for the NULL type and substitute
in the NULL_KEY at that point.
Where the delegated credential is encrypted the existing checks would
still apply to identify any encType mis-match - so overall this change
would be to use the EncryptionKey.NULL_KEY only when absolutely
confirmed it is required.
I am happy to create a Jira issue and e-mail over a proposed patch but
as I say I just wanted to run this by you guys before I start down that
patch.
Regards,
Darran Lofthouse.
