Kerberos Enc Type Expectations for delegated credential within AP_REQ message.

Darran Lofthouse darran.lofthouse at jboss.com
Thu Sep 11 15:48:04 UTC 2014


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.





More information about the security-dev mailing list