Key derivation when encrypting the sequence number in gss_wrap

Thu Jan 12 00:21:56 EST 2006

Hi Sam,

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.

Best Regards

Joseph Harfouch

             Sam Hartman                                                   
             <hartmans at mit.edu                                             
             >                                                          To 
                                       Joseph                              
             01/06/2006 09:54          Harfouch/Australia/Contr/IBM at IBMAU  
             PM                                                         cc 
                                       krbdev at mit.edu                      
                                                                   Subject 
                                       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>
http://ftp.chello.pl/pub/rfc/search.ietf.org/internet-drafts/draft-raeburn-krb-gssapi-krb5-3des-01.txt

    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
at 10.1.

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
compatibility.

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.