Kerberos packets appear to be larger

Jeremy Hunt jeremyh at optimation.com.au
Fri Aug 9 07:31:20 EDT 2013


Greg Hudson wrote:
> On 08/08/2013 05:48 PM, Jeremy Hunt wrote:
>>   From what you say, I presume any of these configuration fields in the
>> krb5.conf field
>>           default_tkt_enctypes
>>           default_tgs_enctypes
>>           permitted_enctypes
>>           kdc_req_checksum_type
>>           ap_req_checksum_type
>>           safe_checksum_type
>> would only have an affect once the key was regenerated. Is that correct?
> No, I was talking about supported_enctypes specifically, because that
> affects the salt types used when a principal's keys are generated.
>
> However, of the parameters you listed above, I think only the client
> default_tkt_enctypes would affect the size of the AP-REP, and only in
> the sense that including an AES enctype would make the reply smaller by
> allowing it to omit a couple of padata elements.
Empirical testing by me shows changing kdc_req_checksum_type and 
ap_req_checksum_type does affect the size of the AP-REP packets.I 
haven't tested them all and I tested by changing both together. So I 
cannot report which of them affected the size.

What I found was that changing the password with kpasswd or kadmin cpw 
or adding a new principal generally changed the size of the AP-REP 
packet for different values of these checksum variables. I changed both 
checksum variables to the same value in my testing. However I found 
using kdb_util dump then load reset the size of the AP-REQ packet to the 
786 value I originally reported. Probably kdb_util doesn't look at these 
configuration settings at all.

I haven't done exhaustive testing because this creates a chicken and egg 
situation for us and indicates that we have to come up with another 
solution. I can say that using CRC32 as the checksum type increases the 
size of the AP-REP packet and using RSA MD5 significantly reduces the 
size of the AP-REP packet.

Thanks again for your hard work Greg. I hope this discussion helps others.

Jeremy


More information about the Kerberos mailing list