incompatibility between Heimdal GSSAPI and MIT GSSAPI for aes256-cts-hmac-sha1-96 credentials?

[Karsten =?utf-8?q?K=C3=BCnne?= <karsten.kuenne@desy.de>]

Hi,

I just spend some time in order to track down a problem with OpenSSH 4.2p1 and 
GSSAPI credential delegation. It turns out that there seems to be some 
incompatibility between the Heimdal implementation and the MIT 
implementation.

If I link sshd against Heimdal (0.7.1) and ssh against MIT KRB5 (1.4 in this 
case) and turn on "GSSAPIauthentication=yes" and 
"GSSAPIDelegateCredentials=yes" in the ssh_config and try to connect with the 
MIT-ssh to the Heimdal-sshd and use a aes256-cts-hmac-sha1-96 ticket I can 
see that sshd enters gsskrb5_accept_delegated_token, then subsequently it 
enters rd_cred2  where it finds the cred.enc_part.etype to be 18 (around line 
97 in rd_cred.c). It then tries to enter krb5_decrypt_EncryptedData where it 
fails in verify_checksum. I don't know why it fails there other than that the 
comparison of the checksums just fails because they're indeed different.

Now, if I try to connect with a Heimdal-ssh to the Heimdal-sshd I can see that 
the cred.enc_part.etype is 0 and krb5_decrypt_EncryptedData is never entered 
and everything works (I kind of expected that).

If I renew my ticket and force it to be des3-cbc-sha1 and then connect with 
the MIT-ssh to the Heimdal-sshd I see that the cred.enc_part.etype is also 0 
and krb5_decrypt_EncryptedData is never entered and everything is fine.

If I connect with the Heimdal-ssh to the MIT-sshd everything works as well.

So, the only case which doesn't work is delegating aes256-cts-hmac-sha1-96 
credentials from MIT to Heimdal. I don't know who's at fault here but maybe 
someone with a deeper understanding of the protocol than me can have a look.


Karsten.