another similar enctype issue

[Sam Hartman]

>>>>> "Will" == Will Fiveash <William.Fiveash at sun.com> writes:

    Will> On Fri, Sep 30, 2005 at 02:22:18PM -0500, Nicolas Williams
    Will> wrote:
    >> On Fri, Sep 30, 2005 at 01:24:25PM -0400, Sam Hartman wrote: >
    >> etype_info_helper
    >> 
    >> Exactly, if the principal has a long-term key of one enctype
    >> that has similar enctypes, then the KDC ought to offer all of
    >> them for pre-auth modulo realm policy.  And the code is there
    >> for that, so if Will is seeing failures that indicate that the
    >> KDC is not offering des-cbc-crc, then maybe we have a bug.
    >> 
    >> > My concern is not what happens to the session key, but what
    >> happens to > the reply key.
    >> 
    >> Me too.

    Will> After looking at this more closely with Nico, here is what
    Will> we discovered:

    Will> 1. When the KDC is creating a AS_REP and adding padata to
    Will> it, it uses the enctypes in the AS_REQ to determine which of
    Will> the client's keys to use from the princ DB.  There is an
    Will> issue here as the db2 backend is using similiarity matching
    Will> when looking for the key which appears to be a violation of
    Will> the DAL (see krb5_dbe_find_enctype() and
    Will> krb5_dbe_search_enctype() in kdb_xdr.c).

No, similarity should be used wehn searching for keys, but you do
sometimes need to fix up the enctype as you have noticed.
   
    Will> 2. The KDC is then using the enctype found in the client key
    Will> (des-cbc-md5) which may not be a literal match to that
    Will> requested in the AS_REQ (des-cbc-crc).  See
    Will> return_etype_info2().  This appears to be a bug as the
    Will> client code is doing a literal comparion of the padata
    Will> enctype in the AS_REP with those it requested.

This is in fact a bug.

    Will> 3. The KDC is returning only a PA-ETYPE-INFO2 even though
    Will> the AS_REQ only contains des-cbc-crc.  That appears to
    Will> violate the text in rfc4120 below:
*sigh*


    Will> So I now understand Sam's point that the problem I'm seeing
    Will> is not on the client side but instead it is the KDC code
    Will> that is buggy.

    Will> -- Will Fiveash Sun Microsystems Inc.  Austin, TX, USA
    Will> (TZ=CST6CDT)