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

[Greg Hudson]

On Sat, 2010-06-05 at 03:51 -0400, Richard E. Silverman wrote:
> In constructing the SPNEGO
> token, which contains an AP_REQ with no application data in sight (not an
> empty application data field somewhere), they do indeed pass a zero-length
> buffer -- not a null in_data pointer -- to krb5_mk_req_extended().

Some information which might help to debug this:

* The code should be passing through make_ap_req_v1() in the krb5 GSS
mech.

* If the key type is DES or DES3, make_ap_req_v1 calls
make_gss_checksum() immediately, which should point checksum_data at a
non-empty checksum to be passed to krb5_mk_req_extended().

* If the key type is anything else (such as RC4), make_ap_req_v1 should
the authenticator checksum function to make_gss_checksum and pass NULL
to krb5_mk_req_extended().  In this case, krb5_mk_req_extended() should
invoke the authenticator checksum function (make_gss_checksum) which
should construct a non-empty checksum and replace in_data with it.

* krb5_mk_req_extended() should see the non-empty checksum, and from
there see that req_cksumtype == 0x8003, which means to use the in_data
directly as the checksum rather than calling krb5_k_make_checksum() over
in_data.

I don't know why, going through the code path above,
krb5_mk_req_extended() would see a zero-length in_data, either
originally or after the call to the authenticator checksum function.
(Your patch adds checks for zero-length in_data in both places; it's
unclear to me which one is actually changing the behavior you're
seeing.)