another similar enctype issue
William.Fiveash at sun.com
Mon Oct 3 15:39:05 EDT 2005
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?
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
More information about the krbdev