kadm5_rename_principal salt question

[Sam Hartman]

>>>>> "John" == John Hascall <john at iastate.edu> writes:

    John> 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.

    John> 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.

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

We'd be interested in the resulting code.

    John> Do we know at what version of the clients this
    John> salt-awareness appeared?
It's been there for a long time.  Probably pre-1.0.  The most modern
form appeared in 1.3, although I'd expect anything newer than 1.2.5 to
also work well.

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

No.
That should already be supported.

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

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


I'm not convinced that you'll avoid preauth_failed for renamed
principals unfortunately.