GSSAPI interoperability problem between Java 1.5 & MIT Kerberos

[Seema Malkani]

Apparently this problem is seen only when using "des-cbc-crc" as the 
encryption type.

MIT Kerberos uses Sign Alg of (DES MAC MD5 - 00 00) for both 
"des-cbc-crc" and "des-cbc-md5" enctypes. Latest RFC's don't seem to 
indicate this. Can MIT team comment on this.

   case ENCTYPE_DES_CBC_MD5:
   case ENCTYPE_DES_CBC_MD4:
   case ENCTYPE_DES_CBC_CRC:
      ctx->signalg = SGN_ALG_DES_MAC_MD5;
      ctx->sealalg = SEAL_ALG_DES;

Also, I believe there is an open issue with using "des-cbc-crc" as the 
default_tgs_enctypes. Can MIT team comment on this.

As for the issue seen with J2SE 1.5.0, we will fix this.

Seema

Ken Hornstein wrote On 01/09/06 12:06,:

>One of our developers has discovered what I believe is a significant
>GSS interoperability problem between the latest version of Java and MIT
>Kerberos.  Specifically ...
>
>Our developer was using a Java application with Java 1.4 to talk to an
>LDAP server using Cyrus-SASL and some version of RedHad's Kerberos
>library (I mention this so it's clear it wasn't our wacky patched Kerberos
>library that was in the mix).  This program worked fine.
>
>When he upgraded to Java 5 (which I guess is also known as "Java 1.5"),
>it failed ... specifically, Cyrus-SASL on the application server would
>return, "A token is invalid".
>
>After some packet traces and judicious use of the debugger later, we
>discovered the problem was that Java 1.4 used as it's integrity algorithm
>(SGN_ALG) DES-MAC-MD5 (0x0000).  However, Java 1.5 now uses DES-MAC
>(0x0200).  Part of me thinks this was a reaction to one of the announced
>MD5 vulnerabilities, but I have no idea; I am just guessing.
>
>On the application server, this algorithm fails in k5unseal.c, around line
>137:
>
>    switch (signalg) {
>    case SGN_ALG_DES_MAC_MD5:
>    case SGN_ALG_MD2_5:
>    case SGN_ALG_HMAC_MD5:
>        cksum_len = 8;
>        if (toktype != KG_TOK_SEAL_MSG)
>          sign_usage = 15;
>            break;
>    case SGN_ALG_3:
>        cksum_len = 16;
>        break;
>    case SGN_ALG_HMAC_SHA1_DES3_KD:
>        cksum_len = 20;
>        break;
>    default:
>        *minor_status = 0;
>        return GSS_S_DEFECTIVE_TOKEN;
>    }
>
>Obviously, it falls out through this switch statement and ends up returning
>GSS_S_DEFECTIVE_TOKEN.
>
>RFC 1964 says regarding DES-MAC: "Support for this algorithm may not be
>present in all implementations."  RFC 4121 has changed things around and
>is silent on the issue.  I believe that Java is wrong in using DES-MAC
>for integrity, but what do other people think?  More importantly, is there
>a way to fix it?
>
>--Ken
>_______________________________________________
>krbdev mailing list             krbdev at mit.edu
>https://mailman.mit.edu/mailman/listinfo/krbdev
>  
>