another similar enctype issue

[Will Fiveash]

On Mon, Oct 03, 2005 at 03:10:25PM -0400, Sam Hartman wrote:
> >>>>> "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 when searching for keys, but you do
> sometimes need to fix up the enctype as you have noticed.

But why should the database backend know about key similarity?  Doesn't
this create a dependency on the krb5_enctypes_list in the database
backend?  In order to avoid this shouldn't the similarity logic be done
by the entity that calls the KDB/DAL function when requesting a key?

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