another similar enctype issue

[Shawn M Emery]

Will Fiveash wrote:

>On Wed, Sep 28, 2005 at 05:54:33PM -0400, Sam Hartman wrote:
>  
>
>>It's not clear to me that your fix is correct.  Your fix causes the
>>client to actually use des-cbc-md5 even though the client only is
>>permitted to use des-cbc-crc by policy.
>>    
>>
>
>What I saw was if default_tkt_enctypes = des-cbc-crc and the user princ
>had a des-cbc-md5 key in the princ DB, the TGT skey enctype was
>des-cbc-crc.  So it did not seem like a violation of the
>default_tkt_enctypes to me.
>
>  
>
>>There appears to be code in our KDC at least to return des-cbc-crc
>>preauth if there is a des-cbc-md5 key and vice versa.  This code will
>>never return a key the client did not request.
>>    
>>
>
>Can you tell me which function I need to look at on the KDC side?
>  
>
It's in the kdc_preauth.c module.  etype_info_helper() actually iterates 
through the client's keys in the kdb and returns those back to the 
requester.  It looks like similar enctypes are coerced if it doesn't 
find an exact match, so I don't see where the logic goes wrong at first 
glance.

Shawn.
--

>>So, I tend to consider this a KDC side issue not a client side issue.
>>    
>>
>
>  
>