another similar enctype issue

[Will Fiveash]

On Fri, Sep 30, 2005 at 02:22:18PM -0500, Nicolas Williams 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.

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

1. When the KDC is creating a AS_REP and adding padata to it, it uses
   the enctypes in the AS_REQ to determine which of the client's keys to
   use from the princ DB.  There is an issue here as the db2 backend is
   using similiarity matching when looking for the key which appears to
   be a violation of the DAL (see krb5_dbe_find_enctype() and
   krb5_dbe_search_enctype() in kdb_xdr.c).
   
2. The KDC is then using the enctype found in the client key
   (des-cbc-md5) which may not be a literal match to that requested in
   the AS_REQ (des-cbc-crc).  See return_etype_info2().  This appears to
   be a bug as the client code is doing a literal comparion of the
   padata enctype in the AS_REP with those it requested.

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

   When the AS server is to include pre-authentication data in a
   KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-
   INFO, if the etype field of the client's AS-REQ lists at least one
   "newer" encryption type.  Otherwise (when the etype field of the
   client's AS-REQ does not list any "newer" encryption types), it MUST
   send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for
   each enctype).  A "newer" enctype is any enctype first officially
   specified concurrently with or subsequent to the issue of this RFC.
   The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not
   "newer" enctypes.

   Hint, look at return_padata() in kdc_preauth.c and etype-info
   instance of the preauth_systems[] (no return_padata function
   defined).

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

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