To understand a key salt, it's important to remember that in Kerberos you
prove your identity by being able to decrypt or encrypt data using an
encryption key that you share with the KDC.

However, a 56-bit DES key is hard for humans to remember. So, whenever a
person enters in their "Kerberos password", it is really converted to a
encryption key by a function called string2key(). This function converts the
plaintext password via a one-way hash algorithm to an encryption key. In
Kerberos 4 this is always a DES key. In Kerberos 5 it could be a key for
algorithms other than DES (but currently DES is still the most widely used
algorithm in Kerberos 5).

The string2key() function takes an optional argument called the key salt.
This is an additional input to the one-way hash algorithm. If a salt is
supplied, it is concatenated to the plaintext password and the resulting
string is converted using the one-way hash algorithm.

In Kerberos 4, a salt was never used. The password was the only input to the
one-way hash function. This has a serious disadvantage; if a user happens to
use the same password in two Kerberos realms, a key compromise in one realm
would result in a key compromise in the other realm.

In Kerberos 5 the complete principal name (including the realm) is used as
the salt. This means that the same password will not result in the same
encryption key in different realms or with two different principals in the
same realm.

AFS uses a different string2key algorithm than Kerberos 4 and Kerberos 5,
and uses the Kerberos realm name (not the cell name) as the key salt.

The MIT Kerberos 5 KDC stores the key salt algorithm along with the
principal name, and that is passed back to the client as part of the
authentication exchange. This means that if you convert your Kerberos
database from Kerberos 4 to Kerberos 5, Kerberos 5 clients can use the
correct string2key algorithm to convert your password to the matching
encryption key. The same is true with AFS, and the AFS-Kerberos 5 migration
kit comes with tools to let you do this (see Question 2.12 for more
information).

It's worth pointing out that this is only an issue for the cases when you
need to convert a plaintext password to an encryption key. Programs that
deal directly with encryption keys (such as application servers) never deal
with plaintext passwords, and as a result this is not an issue with them.

The term "kvno" is simply an acronym for "Key version number". To help
distinguish between multiple keys associated with the same principal (for
example, if a user changes his password), each key is assigned a key version
number. Key version numbers typically start at zero when the principal is
first created and are incremented by one every time the password/encryption
key is changed.