KRB5KRB_AP_ERR_MODIFIED: MIT Kerberos 1.8.1 & arcfour-hmac-md5 session key

[Richard E. Silverman]

I tracked down the bug.  The routine krb5_mk_req_extended() in
src/lib/krb5/krb/mk_req_ext.c creates the authenticator for an AP_REQ.
This authenticator includes a checksum over the AP_REQ application data.
The routine recognized a null in_data pointer as indicating that no
application data was present -- but it did not also recognize the same
situation when in_data points to an empty buffer.  The simple patch below
fixes the bug.

I don't yet know the details of why it failed with RC4, but succeeded with
other ciphers.  I suspect it's related to RC4 being a stream cipher, while
the others are block ciphers; perhaps somehow, it ended up creating a
correct checksum in one case and an invalid one in the other because of
this difference when applied to null data.  I'll figure that out later.

===========================================================================
diff -Naur mit-krb5/src/lib/krb5/krb/mk_req_ext.c patched/src/lib/krb5/krb/mk_req_ext.c
--- mit-krb5/src/lib/krb5/krb/mk_req_ext.c	2010-03-29 20:24:53.000000000 +0000
+++ patched/src/lib/krb5/krb/mk_req_ext.c	2010-06-04 16:08:30.000000000 +0000
@@ -149,7 +149,7 @@
     }
 
 
-    if (!in_data && (*auth_context)->checksum_func) {
+    if ((!in_data || in_data->length == 0) && (*auth_context)->checksum_func) {
         retval = (*auth_context)->checksum_func( context,
                                                  *auth_context,
                                                  (*auth_context)->checksum_func_data,
@@ -158,7 +158,7 @@
             goto cleanup;
     }
 
-    if (in_data) {
+    if (in_data && in_data->length != 0) {
         if ((*auth_context)->req_cksumtype == 0x8003) {
             /* XXX Special hack for GSSAPI */
             checksum.checksum_type = 0x8003;
===========================================================================

>>>>> "res" == Richard E Silverman <res at qoxp.net> writes:

    res> After upgrading to MIT Kerberos 1.8.1, I get
    res> KRB5KRB_AP_ERR_MODIFIED while trying to authenticate to certain
    res> devices; so far, a NetApp filer, and Windows hosts running
    res> BitVise WinSSHD and MS SQL Server (alll part of a Windows AD
    res> realm).  Clients are OpenSSH, Samba, and FreeTDS on Solaris.  The
    res> same combinations work correctly with 1.6.3.  For example:

    res> -----------------------------------------------------------------------

    res> % kinit Password for res at FOO.COM:

    res> % smbclient -k //fshome1/res session setup failed:
    res> NT_STATUS_MORE_PROCESSING_REQUIRED did you forget to run kinit?

    res> % klist -ef Ticket cache: FILE:/tmp/krb5cc_11500_aicJWR9646
    res> Default principal: res at FOO.COM

    res> Valid starting Expires Service principal 06/02/10 03:08:15
    res> 06/02/10 13:08:16 krbtgt/FOO.COM at FOO.COM renew until 06/03/10
    res> 03:08:15, Flags: FRIA Etype (skey, tkt): ArcFour with HMAC/md5,
    res> ArcFour with HMAC/md5 06/02/10 03:08:21 06/02/10 13:08:16
    res> fshome1$@FOO.COM renew until 06/03/10 03:08:15, Flags: FRA
    ---> Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
    res>                            ---------------------

    res> # Now, put this in krb5.conf: # # [libdefaults] #
    res> default_tkt_enctypes = des-cbc-md5 des-cbc-crc

    res> % kinit Password for res at FOO.COM:

    res> % smbclient -k //fshome1/res OS=[Windows 5.0] Server=[Windows
    res> 2000 LAN Manager] smb: \> quit

    res> % klist -ef Ticket cache: FILE:/tmp/krb5cc_11500_aicJWR9646
    res> Default principal: res at FOO.COM

    res> Valid starting Expires Service principal 06/02/10 03:08:54
    res> 06/02/10 13:08:58 krbtgt/FOO.COM at FOO.COM renew until 06/03/10
    res> 03:08:54, Flags: FRIA Etype (skey, tkt): DES cbc mode with
    res> RSA-MD5, ArcFour with HMAC/md5 06/02/10 03:09:00 06/02/10
    res> 13:08:58 fshome1$@FOO.COM renew until 06/03/10 03:08:54, Flags:
    res> FRA
    ---> Etype (skey, tkt): DES cbc mode with RSA-MD5, ArcFour with
    ---> HMAC/md5
    res>                            -------------------------

    res> -----------------------------------------------------------------------

    res> Packet capture of the CIFS traffic for the failed smbclient
    res> command shows KRB5KRB_AP_ERR_MODIFIED returned from the server
    res> when the session key (and hence the authenticator) use
    res> arcfour-hmac-md5.  If I force it to use DES instead, it works.

    res> The problem is present in 1.8 as well.

    res> Before I dive into figuring out what's gone wrong here, I'd like
    res> to know if anyone's seen this?

    res> Thanks,

    res> -- Richard Silverman res at qoxp.net