default_tkt_enctypes and default_tgs_enctypes linkage?

[Will Fiveash]

On Mon, Aug 29, 2005 at 04:59:18PM -0500, Will Fiveash wrote:
> 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.

What I'm trying to point out here in my long winded way is that I don't
understand the linkage between default_tkt_enctypes and
default_tgs_enctypes.  It was my understanding that default_tkt_enctypes
is used by a client for AS_REQs and default_tgs_enctypes for TGS_REQs.
In the MIT code, the enctypes specified in default_tgs_enctypes are also
used to select the TGT cred to use in creating the TGS_REQ and if the
default_tgs_enctypes does not contain a enctype that matches that of the
TGT cred then the krb code returns a "No credentials found with
supported encryption types" error.  See krb5_cc_retrieve_cred_default()
for the code.  Is this behavior really more secure?  (Note that in the
above example the KDC generates a des-cbc-crc session key for use by rsh
and the remote host even though the TGT skey is aes256.)

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