Key derivation when encrypting the sequence number in gss_wrap

Sam Hartman hartmans-ietf at MIT.EDU
Thu Jan 5 15:20:32 EST 2006

>>>>> "Joseph" == Joseph Harfouch <harfouj at> 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.

More information about the krbdev mailing list