Matching the iteration count for aes encryption when using a keytab

[josephharfouch@iinet.net.au]

Hello, 

I notice that the s2kaparams entry in the ETYPE_INFO2 as described in RFC4120 
is a mechanism where the KDC can inform the client of a different iteration 
count rather the default 4096 for AES encryption, so that the client can 
match the generated key, similar to when a different salt is used.

How would this work if the key is already precalculated and stored in a keytab
, i.e if the kinit -k command used to obtain a ticket? I presume that a 
prior knowledge of the iteration count used to calculate server keys by the 
KDC would be the only way to match the key when creating a keytab entry, 
and the s2kparams value would be ignored when a keytab entry is used to decrypt 
the ticket, but I don't see any option in the ktadd command to adjust the 
iteration count when generating a key in the keytab. The syntax below 
allows for the specification of a different salt, but not a different 
iteration count. 

Even if I'm right and something is really missing, I don't see this as a big 
deal for the time being, but I presume in the future an iteration count of 4096 
would not be sufficient, and KDCs would be sending different iteration 
counts for principals including server principals, so I'm just letting you know 
in case it is really an issue. 


ktadd [-k[eytab] keytab] [-q] [-e
     key:salt_list] [principal | -glob princ_exp]
     [...]


Best Regards


Joseph Harfouch