How is a password encrypted into a keytab file?

Question

I am using keytab files on Linux systems to authenticate services with kerberos. I am wondering how this password is actually stored into that keytab file. As we know in /etc/passwd the passwords are stored after applying a one-way hashing method - so it is not possible to calculate the plaintext password from it.

But how is that done in the keytab file? The Process using the keytab somehow must know the password to authenticate the user?! Is it encrypted with a master password so it can be decrypted?

I am using this to create a keytab file:

$ ktutil
ktutil:  addent -password -p my_user@MYREALM -k 1 -e rc4-hmac
Password for my_user@MYREALM:
ktutil:  wkt my_user.keytab
ktutil:  quit

With that keytab I can get a krbtgt without entering a password. When creating the keytab there is no communication with the AD/KDC (so there is no shared secret that could be added for signing or something).

So how is the password encrypted into the keytab? If it is not a hashing algo - is it possible to decrypt it?

Venipuncture

Answer 1

In general a password-based Kerberos key comes from applying an algorithm-specific key derivation function to the user-supplied password, and uses the user principal name as salt (so that two principals with the same password will not have the same key). The actual key derivation functions used are defined in RFC 3961 and RFC 3962 however the RC4 profile is defined elsewhere (by Microsoft).

The key derivation is a one-way function so there is no feasible way to "decrypt" the key.

Birthstone

And that derived key is stored (as is) into that keytab? And that derived key can be used (as is) to authenticate a user? I don't see a real advantage compared to storing plain text passwords into config files ... Au contraire - I see people thinking keytab files are a "secure" way of storing passwords and they use them without enough caution ... – Venipuncture

The Kerberos protocol is based on symmetric (shared key) cryptography; the fact that user principals' keys are normally derived from passwords is an implementation detail. Of course, you could just store the password but then the implementation would have to derive the key every time it talks to the KDC. A keytab is only as secure as the access controls on it (same as a plain password file); I don't think anyone has ever pretended otherwise. – Birthstone

@Birthstone The arcfour salt is always empty. The salt for AES employed by MS derives from the RFC unfortunately. See here. – Greensward

@Greensward - I have read the link/your thread on the mailing list. Did you find a solution to create a working AES keytab entry without using msktutil? – Venipuncture

@slash4, yes. It is possible but annoying. What I actually did is reaching out to the msktutil devs and asked them to add necessary bits. See SF tracker. Ultimately, you will need msktutil if you are in an AD-managed environment. If still want to know how to achieve this, ping me again. – Greensward

We normally create a keytab using two algorithms: rc4-hmac, aes256-cts and are able to communicate with Microsoft AD just fine. We're uring MIT's ktutil. – Cableway