Key derivation when encrypting the sequence number in gss_wrap
hartmans-ietf at MIT.EDU
Thu Jan 5 15:20:32 EST 2006
>>>>> "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.
More information about the krbdev