Key derivation when encrypting the sequence number in gss_wrap

[Sam Hartman]

>>>>> "Joseph" == Joseph Harfouch <harfouj at au1.ibm.com> writes:

    Joseph> We recently had a problem interoperating with a JAVA
    Joseph> implementation of Kerberos/gss. The problem is that JAVA
    Joseph> seems to be doing a key derivation when encrypting the
    Joseph> sequence number in gss_wrap (Which I think is the correct
    Joseph> behavior for encryption type ENCTYPE_DES3_CBC_SHA1), and

What leads you to believe this is the correct behavior?
I.E. what spec are you trying to follow?


    Joseph>     Joseph> we don't.  However, we seem to interoperate correctly with
    Joseph> you which seems to suggest that you have the same behavior
    Joseph> as us (Which we believe to be faulty).

    Joseph> The code in kg_encrypt suggests that you are trying to do
    Joseph> key derivation using KG_USAGE_SEQ , but since the
    Joseph> encryption of ctx->seq has been modified earlier to
    Joseph> ENCTYPE_DES3_CBC_RAW in krb5_gss_accept_sec_context, and
    Joseph> that encryption type does not perform key derivation, no
    Joseph> derivation is performed, and changing the USAGE value in
    Joseph> the kg_encrypt call in kg_make_seq_num (The file is
    Joseph> util_seqnum.c) has no effect.

I believe your understanding is correct.  This was a bug in our 3des
GSSAPI implementation, but we ended up shipping with this behavior and
since no spec was ever written that's how it works.



    Joseph> We are still in the early stages of investigating the
    Joseph> problem, but we are concerned that any fix we do, does not
    Joseph> break interoperability with you, but we want to correctly
    Joseph> follow the RFC of course. Could you please give us your
    Joseph> opinion/analysis of this.


I'm not aware of any RFC (or plan to write an RFC) describing 3DES
GSSAPI.  There was an internet draft at one point, but I seem to
recall that draft not actually describing what was done.  I think the
sequence number may well be the major problem with the draft.

I'm not opposed to writing a document describing 3DES GSSAPI.  I agree
it would be useful.  However I just don't know anyone who has agreed
to do the work.

Long term we hope RFC 4121 will make this sort of problem unnecessary
as everyone migrates to AES.