dbentry_supports_enctype and 1DES enctypes

[Will Fiveash]

A long time ago Tom Yu wrote an e-mail describing how the MIT krb code
handles 1DES enctypes (Message-ID:
<ldv669d9a86.fsf at saint-elmos-fire.mit.edu>).  In the message there is
this:

    The session key gets chosen by iterating through the requested list
    of enctypes and finding the first match returned by
    dbentry_supports_enctype() on the server principal.  This strange
    function always matches on des-cbc-md5 if the SUPPORT_DESMD5 flag is
    set on the principal; otherwise, it will always fail to match
    des-cbc-md5.  (Curiously enough, this function lists its parameter
    as "client", while the caller passes it the server principal.)
    dbentry_supports_enctype() also always matches on des-cbc-crc,
    making the erroneous assumption that all principals will accept that
    enctype for a session key.  If these hardcoded matches fail,
    krb5_dbe_find_enctype() will get called with an explicit enctype.

The reason I'm writing about this is that I just tried an experiment
where I specified the entype of the remote "host" service princ to be
aes256-cts-hmac-sha1-96:normal thinking this would restrict the session
keys generated by the KDC to just aes256-cts-hmac-sha1-96.  What I find
if I either use telnet -x or set:

default_tgs_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 

in krb5.conf on the client side and use rsh -x is that the KDC will
issue a des-cbc-crc session key!  I found this surprising since I
expected that the KDC would use the intersection of the entypes
supported by the service principal as found in the princ. DB and those
requested by the client in the AS/TGS Req (I was not aware of Tom's
earlier message).  

Shouldn't dbentry_supports_enctype() be modified to remove the following
code?:

    /*
     * We are assuming that all entries can support MD5; this information
     * need not be kept in the database.
    */ 
    if (enctype == ENCTYPE_DES_CBC_MD5)
    return 1;

    /*
     * XXX we assume everything can understand DES_CBC_CRC
     */
    if (enctype == ENCTYPE_DES_CBC_CRC)
    return 1;

This would allow the admin to explicitly control the entypes used for
session keys for that service principal by limiting the enctypes of the
service princ's keys in the princ DB.

I also don't understand why the following config doesn't work for rsh
-x:

default_tkt_enctypes = aes256-cts-hmac-sha1-96
default_tgs_enctypes = des-cbc-crc

even if the remote host service princ key is des-cbc-crc.  I find that
the following does work:

default_tkt_enctypes = aes256-cts-hmac-sha1-96
default_tgs_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96

and the session key issues by the KDC is des-cbc-crc.  What confuses me
is why default_tgs_enctypes has to include aes256-cts-hmac-sha1-96 when
the KDC is generating a des-cbc-crc ticket.
-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)