Use cases for kerberos credential cache type MEMORY?

Question

One of the credential cache types offered by MIT Kerberos is MEMORY. According to the documentation it is used by kadmin.

MEMORY caches are for storage of credentials that don’t need to be made available outside of the current process. For example, a memory ccache is used by kadmin to store the administrative ticket used to contact the admin server.

I have tried setting default_ccache_name = MEMORY: in /etc/krb5.conf. After doing so I made a packet capture while issuing the kinit command. From this capture I can see that a TGT was successfully obtained from the KDC. This ticket was then (obviously) lost as soon as the kinit process finished. Furthermore, it seems if persistent memory based tickets are required one can use the KEYRING ccache type.

What are the other use cases of the MEMORY credential cache type?

I assume this is not useful from a bash script for example. When the script calls kinit it will fork and upon completion the obtained ticket will not be accessible to the parent.

Is there perhaps a kerberos header file that can be included so as to keep obtained tickets in the same address space as the rest of your logic?

this is an interesting question, i didn't know this MEMORY option either, i assume there are some kind of possiblities to use it in C or Perl applications and keep the memory address location to use it afterwards, and it's better than a file so it cannot be obfuscated? or something — olivierg, Jun 16 '17 at 19:47
i suppose we can use the KRB5CCNAME variable and perform another kerberos query afterwards using this cache (automatically) — olivierg, Jun 16 '17 at 19:49
Yes that was my thought exactly. It doesn't seem so useful from the command line. I assume it must be usable from C code so that the ticket can be used internally. It certainly beats keeping this sensitive information in the (world read/writeable) `/tmp` directory! — rlf, Jun 16 '17 at 19:55

score 1 · Accepted Answer · answered Jun 24 '17 at 19:31

The answer to this question is exactly what was postulated in the comments. From your code you can include the krb5.h header. This will give you access to the functions that make up the Kerberos code base.

Below is a toy example that is adapted from the documentation.

#include <string.h>
#include <krb5.h>

int main(void)
{
    krb5_error_code ret;
    krb5_creds creds;
    krb5_principal client_princ = NULL;

    krb5_context context;
    const char* princname = "user@REALM";
    const char* password = "secret";

    krb5_init_context(&context);

    memset(&creds, 0, sizeof(creds));
    ret = krb5_parse_name(context, princname, &client_princ);
    if (ret)
        goto cleanup;
    ret = krb5_get_init_creds_password(context, &creds, client_princ,
                                       password, NULL, NULL, 0, NULL, NULL);
    if (ret)
        goto cleanup;
    ret = krb5_verify_init_creds(context, &creds, NULL, NULL, NULL, NULL);

    /* do things with the ticket (&creds) here */

    cleanup:
    krb5_free_principal(context, client_princ);
    krb5_free_cred_contents(context, &creds);

    return 0;
}

The function krb5_init_context() is what reads your configuration file and honours the MEMORY: ccache type. The obtained ticket will then be stored in this processes memory space.

This code does indeed obtain a TGT. We can verify this by taking a packet capture while it runs. We can also just dump the memory of this process and verify that the TGT is contained in it.

score 0 · Answer 2 · answered Jun 16 '17 at 19:57

The manual talks about kadmin example. It can be invoked either as a CLI with normal tickets in KEYRING or in FILEs. The other possibility is to run the commands interactively in kerberos "shell". In that case, the ticket is stored in the memory of the process where it is "more secure" and it is automatically cleaned up as the process ends.

The same way kerberos tickets and operations can be accessed from other applications using already mentioned "header" files, generally using so called GSSAPI (gssapi.h). Not completely answer to your question, but this is the way how the keberos primitives are accessed in the OpenSSH to access local kerberos ticket and authenticate to the remote server (in this case the MEMORY type would not be useful).

Use cases for kerberos credential cache type MEMORY?

2 Answers2