krb5_keytab_intro(3)

✨ krb5_keytab_intro ✨

okay bestie, welcome to krb5_keytab_intro(3) from the Heimdal Kerberos 5 library 💖 this is the girlies' guide to keytabs, and honestly? iconic behavior.

🎀 NAME 🎀

krb5_keytab_intro — the keytab handling functions, aka the whole vibe 💅

---

🦋 Kerberos Keytabs 🦋

so like, the actual functions live here: Heimdal Kerberos 5 keytab handling functions ✨

Keytabs are the long term key storage for servers — they're literally the server's equivalent of password files. no cap. 🗝️

Normally, the only functions that are actually useful for a server are the ones that let you specify what keytab to use, handing that info off to other core functions like krb5_rd_req() krb5_kt_resolve(), and krb5_kt_close(). that's the whole job fr fr 🫶

🌸 Keytab names 🌸

A keytab name is on the form type:residual. The residual part is specific to each keytab-type — so like, every type has its own lil personality for that part 💫

When a keytab-name is resolved, the type is matched with an internal list of keytab types. If there's no matching keytab type, the default keytab is used. The current default type is FILE. periodt.

The default value can be changed in the configuration file /etc/krb5.conf by setting the variable [defaults]default_keytab_name. go off, config file 👑

The keytab types that are implemented in Heimdal are:

• file — stores the keytab in a file, and the type's name is FILE. The residual part is a filename. For compatibility with other Kerberos implemtation WRFILE and JAVA14 is also accepted. WRFILE has the same format as FILE. JAVA14 have a format that is compatible with older versions of MIT kerberos and SUN's Java based installation. They store a truncted kvno, so when the knvo excess 255, they are truncted in this format. 😭 (yes the kvno gets chopped, that's just how it is)
• keytab — stores the keytab in a AFS keyfile (usually /usr/afs/etc/KeyFile), and the type's name is AFSKEYFILE. The residual part is a filename.
• memory — The keytab is stored in a memory segment. This allows sensitive and/or temporary data not to be stored on disk. The type's name is MEMORY. Each MEMORY keytab is referenced counted by and opened by the residual name, so two handles can point to the same memory area. When the last user closes using krb5_kt_close() the keytab, the keys in they keytab is memset() to zero and freed and can no longer be looked up by name. ✨ (sensitive data really said "and i oop, gone")

bestie take note: once that last handle closes a MEMORY keytab, the keys get memset() to zero and freed, and you genuinely cannot look them up by name anymore. no take-backs 💀

⭐ Keytab example ⭐

This is a minimalistic version of ktutil. literally so cute, so demure 🎀

int
main (int argc, char **argv)
{
    krb5_context context;
    krb5_keytab keytab;
    krb5_kt_cursor cursor;
    krb5_keytab_entry entry;
    krb5_error_code ret;
    char *principal;

    if (krb5_init_context (&context) != 0)
        errx(1, "krb5_context");

    ret = krb5_kt_default (context, &keytab);
    if (ret)
        krb5_err(context, 1, ret, "krb5_kt_default");

    ret = krb5_kt_start_seq_get(context, keytab, &cursor);
    if (ret)
        krb5_err(context, 1, ret, "krb5_kt_start_seq_get");
    while((ret = krb5_kt_next_entry(context, keytab, &entry, &cursor)) == 0){
        krb5_unparse_name(context, entry.principal, &principal);
        printf("principal: %s0, principal);
        free(principal);
        krb5_kt_free_entry(context, &entry);
    }
    ret = krb5_kt_end_seq_get(context, keytab, &cursor);
    if (ret)
        krb5_err(context, 1, ret, "krb5_kt_end_seq_get");
    ret = krb5_kt_close(context, keytab);
    if (ret)
        krb5_err(context, 1, ret, "krb5_kt_close");
    krb5_free_context(context);
    return 0;
}

---

and that's the whole page, bestie 💖 this one's Version 7.8.0, dated Tue Nov 15 2022 — shoutout to the Heimdal Kerberos 5 library for keeping our server keys safe. slay, stay keyed, and always krb5_kt_close() your handles 🫶✨💅