more ldap concerns

[Will Fiveash]

On Fri, Jun 02, 2006 at 05:26:00AM -0600, Praveenkumar Sahukar wrote:
> >>> On Fri, Jun 2, 2006 at  7:27 AM, in message
> <20060602015713.GB4031 at sun.com>,
> Will Fiveash <William.Fiveash at sun.com> wrote: 
> 
> > While trying to setup a LDAP directory for KDB use I ran
> > 
> > kdb5_ldap_util - D "cn=directory manager" create
> > 
> > I see:
> > 
> > Default enctype not specified: "des3- cbc- sha1" will be added as the
> default 
> > enctype and to the list of supported enctypes.
> > 
> > This appears to be hard coded in kdb5_ldap_create():
> > 
> >     if ( !(mask & LDAP_REALM_DEFENCTYPE) && (rparams != NULL)) {
> >     rparams- >defenctype = ENCTYPE_DES3_CBC_SHA1;
> >     mask |= LDAP_REALM_DEFENCTYPE;
> >     printf("Default enctype not specified: \"des3- cbc- sha1\" "
> >         "will be added as the default enctype and to the "
> >         "list of supported enctypes.\n");
> > 
> > How is this realm object attribute (krbDefaultEncType) being used? 
> And
> > why ENCTYPE_DES3_CBC_SHA1?
> 
> If supported_enctypes is not defined in kdc.conf, the
> "des3-hmac-sha1:normal des-cbc-crc:normal" combination is used as the
> code default. The krbDefaultEncType attribute value is present to
> override this code default value. 
> 
> ENCTYPE_DES3_CBC_SHA1 is assumed as the default since this is the code
> default too. 

I have a problem with this.  See my comments further down for more.

> =======================================================================
> > 
> > Second I see (in src/plugins/kdb/ldap/libkdb_ldap/ldap_realm.c):
> > 
> > int supportedenctypes[] = { ENCTYPE_DES_CBC_CRC, ENCTYPE_DES_CBC_MD4,
> 
> > ENCTYPE_DES_CBC_MD5,
> >                             ENCTYPE_DES3_CBC_SHA1, 
> > ENCTYPE_AES128_CTS_HMAC_SHA1_96,
> >                             ENCTYPE_AES256_CTS_HMAC_SHA1_96, 
> > ENCTYPE_ARCFOUR_HMAC, - 1};
> > 
> > int supportedsalttypes[] = { KRB5_KDB_SALTTYPE_NORMAL,
> KRB5_KDB_SALTTYPE_V4,
> >                              KRB5_KDB_SALTTYPE_NOREALM, 
> > KRB5_KDB_SALTTYPE_ONLYREALM,
> >                              KRB5_KDB_SALTTYPE_SPECIAL, - 1};
> > 
> > Do we really want more hard coded lists of supported enc/salt types?
> > Note, these valures are being stored in the realm container objects
> via
> > kdb5_ldap_util create.  What happens if the KDC is modified to
> support
> > more enctypes?  Does this mean the realm container must be updated?
> 
> Yes this will lead to additional configuration steps to the realm
> container. We will change the code to derive the lists from the krb5
> library. 

The way the k*.conf enctype parameters work now is that if they are not
set in the k*.conf file then the code uses an internal version of the
enctype parameter to determine what enctypes to use.  This is good
because if the code is updated to support new enctypes, the k*.conf
files do not have to change.  If you are specifying these parameters in
various objects in the directory by default you are limiting the krb
code and possibly creating more work for the admin.  I don't think the
enctype parameters should be instantiated by default, only if the admin
specifies the parameter settings via the command line.

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