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.) ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
