kadmin ktadd -e keysaltlist for des-cbc-md5

[Marcus Watts]

"Tom Simons" <tom.simons at gmail.com> writes:
> I'm trying to get a keytab with des-cbc-md5 encryption (no salt) from our
> kerberos 1.5 realm for a CyberSafe client. How do I specify the ktadmin
> ktadd command's "-e keysaltlist" parameter?  I tried variations on "ktadd -k
> <filename> -e ENCTYPE_DES_CBC_MD5:NONE", but get the same error:
> 
>     kadmin:  ktadd -k host.TESTMIT.keytab -e ENCTYPE_DES_CBC_MD5:NOSALT
>     ktadd: Invalid argument while parsing keysalts ENCTYPE_DES_CBC_MD5

"Tim Alsop" <Tim.Alsop at CyberSafe.Com> replied:
> kadmin.local:  ktadd -e DES-CBC-MD5:NORMAL test/princ

Case of the strings doesn't matter (I've always used lower-case).
The names of the encryption types vary slightly between releases
and between mit & heimdal.  These are fairly reliable:
des-cbc-crc
des-cbc-md4
des-cbc-md5
[1]des-hmac-sha1
des3-cbc-sha1 des3-hmac-sha1 des3-cbc-sha1-kd
rc4-hmac arcfour-hmac arcfour-hmac-md5
[1]rc4-hmac-exp
aes128-cts aes128-cts-hmac-sha1-96
aes256-cts aes256-cts-hmac-sha1-96

[1] = not in heimdal

I've often wished the mit code had a way to spit these strings out.
They can be found in MIT source in krb5/src/lib/crypto/etypes.c
In heimdal, look at lib/krb5/crypto.c (/enctype_null/).

Salt strings:

MIT			HEIMDAL
normal			pw-salt
v4
norealm
onlyrealm
special
afs3			afs3-salt

MIT source: krb5/src/lib/krb5/krb/str_conv.c
Heimdal source: lib/krb5/crypto.c (/^static struct salt_type/)

In MIT, key salt pair parsing is done in krb5_string_to_keysalts,
krb5/src/lib/kadm5/str_conv.c
and has very wonky separator logic.
pairs may be separated by , \t
and the enctype & salt may be spearated by one of :.-
(the default separators aren't used, look at krb5/src/kadmin/cli/{kadmin,keytab}.c)
Since - can be either embedded inside an enctype string or separate the enc
and salt types, things get very interesting in the code (and error reporting
becomes just as confusing to you the user.)

Heimdal appears to have very different and even more interesting
key salt pair parsing rules.  You get to name the salt, if you want,
which replaces most of the special cases in MIT.  This does require
that the salt be something you can type.

You'll note there is no "none" salt type.  In order to see "no salt"
from kadmin, you have to examine an entry that has a "key_data_ver ==
1" in the kdb, most likely because you generated a random key.  "no
salt" is literally true - data_ver==1 also means there's no salt type
or string stored in the database.  If you generate a key from a
password, it has to have salt (in theory).  The salt type & string are
part of the string to key conversion algorithm.  If you add or change
the keys for a principal using "-randkey" in MIT, you'll discover that
(a) the salt magically disappears, and (b) if you mention duplicate
encryption types with different salt, they get merged together.  In
short, it *ignores* the salts you name, except for making sure they're
valid salt types.

				-Marcus