Kerberos Enc Type Expectations for delegated credential within AP_REQ message.

[Darran Lofthouse]

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.
>
>