kadm5_rename_principal salt question

[John Hascall]

Ken Raeburn writes:

> The string-to-key method in general is specified to take the password  
> and salt as inputs, though RC4 doesn't use the salt if I recall  
> correctly.  The salt can be specified by the KDC, but there's a  
> default method for generating the salt from the principal name and  
> realm if the KDC doesn't supply it.  In the MIT database, "normal"  
> salt type means to use this default, and "special" means some random  
> string stuffed in the database.
> 
> For principal renaming, if the database entry originally used  
> "normal" salt type (and has anything other than an RC4 key), the  
> default salt string needs to be generated (using the old principal  
> name) and stored in the new entry as type "special".  If the entry  
> originally used "special", it stays unchanged.  There are some other  
> types which should also be examined to see if they need converting.

In another message Marcus Watts writes:
> My recollection from having chased this down a *long* time ago
> is that "KRB5_KDB_SALTTYPE_NORMAL" isn't sufficient; you have
> to make it "KRB5_KDB_SALTTYPE_SPECIAL".  As long as you don't
> have more than one salt (per enc type) that maps into
> KRB5_KDB_SALTTYPE_SPECIAL this works fine.  It does require that
> the client understand preauth sufficiently to pick up the salt.

Thanks Guys!
So, it looks like I do have a prayer of getting to work what I need to.

Do we know at what version of the clients this salt-awareness appeared?

Also, I'm expecting I'm going to have to do some (possibly ugly) mucking
in the checking of pre-auth data, too right?

We've used "des-cbc-crc:v4" keytypes ever since we upgraded to K5
lo this many years ago.  One side effect of "v4" (aka "no") salt is
that renaming principals is easy.  And, as many of you are sick of
hearing, "renames w/o password changes" are a big deal here too.

Now we have a WebCT system which is authenticating, and (unlike most
clients which send a preauth-less request initially), it includes
pre-auth in its initial request.  But this preauth is using
"des-cbc-crc:normal".  So every one of these gets a PREAUTH_FAILED
log entry in kdc.log which makes our log-scanner/IDS think that
our WebCT servers are constantly attacking.  And, so it's exempted
and we'd never see a real attack.

So, now I finally have the Causa Bella I need to add keytypes
(I want AES and maybe RC4 and I'll throw in des-cbc-crc:normal for WebCT).

But it occurs to me that "des-cbc-crc:special" in general may not match
"des-cbc-crc:normal" so I'm guessing I may have to bend a few things in
the pre-auth checking code as well?

Thanks again,
John