Key derivation when encrypting the sequence number in gss_wrap

[Joseph Harfouch]

Hi Sam,

Thanks very much for the quick and informative reply.

The encryption type that we are using in the test case is encryption type
16 (des3-cbc-sha1-kd in RFC 3961). RFC 3961 states that key derivation for
this encryption type should be taking place, but I can only find out how
that is done in RFC 4120 (Section 7.5.1) for Kerberos with the designation
of usage values .  In that section they state that values "22-25.  Reserved
for use in the Kerberos Version 5 GSS-API mechanisms [RFC4121]." However,
RFC 4121 is for version 2 of the GSSAPI, and I cannot find an RFC that
states the values for version 1 of GSSAPI. I only find this draft document
which seems to match what every one is trying to do.

The document is

http://ftp.chello.pl/pub/rfc/search.ietf.org/internet-drafts/draft-raeburn-krb-gssapi-krb5-3des-01.txt

"Triple-DES Support for the Kerberos 5 GSSAPI Mechanism"

and in this document, they state the values below

"3. Key Derivation

   For purposes of key derivation, we add three new usage values to the
   list defined in [KrbRev]; one for signing messages, one for sealing
   messages, and one for encrypting sequence numbers:


   +--------------------------------------------------------------------+
   |             name                                    value          |
   +--------------------------------------------------------------------+
   |         KG_USAGE_SEAL                                22            |
   |         KG_USAGE_SIGN                                23            |
   |         KG_USAGE_SEQ                                 24            |
   +--------------------------------------------------------------------+"


So, all of this matches with your recollection that there is no RFC, but a
draft document.

As I said, I am fairly new to Kerberos and GSSAPI, so I'm not sure of the
history of how things developed, but it seems that our code and your code
is very similar to this draft, that it was trying to follow it (Although, I
don't know how the draft have changed of course).

So I think the intention was to do key derivation where the encryption type
called for it (Otherwise we would not have used these usage values in the
code, if they never would have an effect), and if another implementation is
doing this correctly, we cannot ask them to change to conform to our
incorrect behavior. In other words, the fact that the document is a draft,
and not an RFC would have been more relevant if we didn't try to follow it
at all. We seem to be doing key derivation correctly for the checksum
(KG_USAGE_SIGN), but not when encryption (kG_USAGE_SEQ or KG_USAGE_SEAL).

I appreciate the reluctance to change when there is no RFC to describe the
correct behaviour, and the fact that AES migration would fix the problem.
For our mainframe implementation, we have lot of backward compatibility
issues, so we cannot rely on this change taking place rapidly. Anyway,
please let us know if a change in this area would be forthcoming or not. I
am also wondering how many other platforms have the same behavior, and
whether you received similar questions from other implementations.

Thank you very much for your assistance.


Regards, Joseph








                                                                           
             Sam Hartman                                                   
             <hartmans-ietf at mi                                             
             t.edu>                                                     To 
                                       Joseph                              
             01/06/2006 04:20          Harfouch/Australia/Contr/IBM at IBMAU  
             AM                                                         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> 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.