Key derivation when encrypting the sequence number in gss_wrap
harfouj at au1.ibm.com
Thu Jan 12 00:21:56 EST 2006
Thanks again for your latest reply. We are discussing this inside IBM,
given in particular the facts you stated in your last note about the
backward compatibility concerns of any change.
<hartmans at mit.edu
01/06/2006 09:54 Harfouch/Australia/Contr/IBM at IBMAU
krbdev at mit.edu
Re: Key derivation when encrypting
the sequence number in gss_wrap
>>>>> "Joseph" == Joseph Harfouch <harfouj at au1.ibm.com> writes:
Joseph> Hi Sam,
Joseph> Thanks very much for the quick and informative reply.
Joseph> The encryption type that we are using in the test case is
Joseph> encryption type 16 (des3-cbc-sha1-kd in RFC 3961). RFC
Joseph> 3961 states that key derivation for this encryption type
Joseph> should be taking place, but I can only find out how that
Joseph> is done in RFC 4120 (Section 7.5.1) for Kerberos with the
Joseph> designation of usage values . In that section they state
Joseph> that values "22-25. Reserved for use in the Kerberos
Joseph> Version 5 GSS-API mechanisms [RFC4121]." However, RFC 4121
Joseph> is for version 2 of the GSSAPI, and I cannot find an RFC
Joseph> that states the values for version 1 of GSSAPI. I only
Joseph> find this draft document which seems to match what every
Joseph> one is trying to do.
Ah. Ah. So, part of the confusion is that before RFC 4121, GSSAPI
did not use Kerberos encryption types (RFC 3961) directly. Instead,
it took the Kerberos encryption key and its own encryption with that
key. This disconnect between GSSAPI and Kerberos was the primary
motivation for RFC 4121.
Joseph> The document is
Joseph> "Triple-DES Support for the Kerberos 5 GSSAPI Mechanism"
Yep. That's an expired draft that we were working on when we wanted
to document 3DES GSSAPI. We realized that it didn't actually match
what our code did. I think the primary difference is that we ended up
using the raw encryption type and thus not doing key derivation.
I don't know if there are any other differences.
Joseph> As I said, I am fairly new to Kerberos and GSSAPI, so I'm
Joseph> not sure of the history of how things developed, but it
Joseph> seems that our code and your code is very similar to this
Joseph> draft, that it was trying to follow it (Although, I don't
Joseph> know how the draft have changed of course).
Joseph> So I think the intention was to do key derivation where
Joseph> the encryption type called for it (Otherwise we would not
Joseph> have used these usage values in the code, if they never
Joseph> would have an effect),
I agree that certainly is the intent.
Joseph> and if another implementation is
Joseph> doing this correctly, we cannot ask them to change to
Joseph> conform to our incorrect behavior.
Ah, and here I disagree. Absent a compelling security hole or
something like that, running code trumps incompatible changes that
would break shipping products. This is especially true when the draft
is an expired draft that never made it to be a standard.
The MIT behavior has been shipping since around 2001. It has been
included in Solaris 9 and Solaris 10 as well as Apple's OS X starting
As far as I can tell Heimdal has also been shipping an implementation
for years that does not derive keys for the sequence number and that
works with the MIT code base.
Microsoft does not (and does not plan to) support 3DES.
so, while I agree it would be nice to derive keys, I would need to
find a way to support this that did not break backward compatibility
with code we are shipping.
Joseph> In other words, the
Joseph> fact that the document is a draft, and not an RFC would
Joseph> have been more relevant if we didn't try to follow it at
Joseph> all. We seem to be doing key derivation correctly for the
Joseph> checksum (KG_USAGE_SIGN), but not when encryption
Joseph> (kG_USAGE_SEQ or KG_USAGE_SEAL).
Joseph> I appreciate the reluctance to change when there is no RFC
Joseph> to describe the correct behaviour, and the fact that AES
Joseph> migration would fix the problem. For our mainframe
Joseph> implementation, we have lot of backward compatibility
Joseph> issues, so we cannot rely on this change taking place
Joseph> rapidly. Anyway, please let us know if a change in this
Joseph> area would be forthcoming or not. I am also wondering how
Joseph> many other platforms have the same behavior, and whether
Joseph> you received similar questions from other implementations.
Currently I don't see how to make a change and maintain backward
There is one thing we could do here. If you are interested, you could
update Ken's draft to describe what is actually going on and publish
it as an informational RFC.
More information about the krbdev