Concealing keys (not even in NSS)

[Rick van Rein]

Hi,

I've looked into the mechanism for configurable crypto backends and in
particular the NSS backend, which is close to PKCS #11.

What I like about PKCS #11 is that it can conceal keys from the libkrb5
library, and thereby from the application's reachable memory.  This is
not how the NSS crypto backend is made, I found -- keys are imported
into NSS as (session) keys and used there.  If FIPS is enforced, it will
fake its patterns by unwrapping a key that was wrapped just for that sake.

This seems to me like a missed opportunity.  Am I mad to think that a
crypto backend could choose any krb5_keydata representation, and that a
pkcs11: URI [RFC7512] would be fine?  It looks like the surrounding
libkrb5 treats the keys as literals and always invoke krb5_k_decrypt()
and _encrypt() after expanding the key to an opaque krb5_key after
krb5_k_create_key() and before krb5_k_free_key(), right?

This does seem to be possible -- but how do others feel about this?


Cheers,
 -Rick

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Russ Allbery]

tseegerkrb  writes:

> I think the sshd daemon do not honor the "default_ccache_name" and uses
> the default file format.

I'm pretty sure you're correct if you're doing GSS-API authentication with
ssh.  Looking at the source code to sshd, you don't seem to get much
choice in the matter:

# ifdef HAVE_KRB5_CC_NEW_UNIQUE
problem = krb5_cc_new_unique(authctxt->krb5_ctx,
 krb5_fcc_ops.prefix, NULL, >krb5_fwd_ccache);
# else
problem = krb5_cc_gen_new(authctxt->krb5_ctx, _fcc_ops,
>krb5_fwd_ccache);
# endif

[...]

authctxt->krb5_ticket_file = (char 
*)krb5_cc_get_name(authctxt->krb5_ctx, authctxt->krb5_fwd_ccache);

len = strlen(authctxt->krb5_ticket_file) + 6;
authctxt->krb5_ccname = xmalloc(len);
#ifdef USE_CCAPI
snprintf(authctxt->krb5_ccname, len, "API:%s",
authctxt->krb5_ticket_file);
#else
snprintf(authctxt->krb5_ccname, len, "FILE:%s",
authctxt->krb5_ticket_file);
#endif

You'd need to write a PAM module that read in that ticket cache file and
wrote it back out to your preferred ticket cache format and then adjusted
KRB5CCNAME in the user's environment.  Unfortunately, there doesn't appear
to be any way of preventing the ticket cache from being temporarily
written to /tmp.

-- 
Russ Allbery (ea...@eyrie.org)  

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[tseegerkrb]

Hello,

i grep for KRB5CCNAME to the etc directory and the only match is in 
"/etc/default/slapd" and this is ok and has nothing todo with the login 
process. I think the sshd daemon do not honor the "default_ccache_name" 
and uses the default file format. I use pam_sss instead of pam_krb5. If 
i get my internet connection up again i will post my configuration files.

Thanks and best regards

On 19.09.2016 06:11, Benjamin Kaduk wrote:
> On Fri, 16 Sep 2016, t Seeger wrote:
>
>> Hello,
>>
>> i have a little problem with the 'KRB5CCNAME' environment variable. I set
>> the default_ccache_name to KEYRING:persistent:%{uid} but if i login it is
>> set to "file:/tmp/krb5cc_${uid}_XX" cause ssh sets the KRB5CCNAME
>> to file:/tmp/krb5cc_${uid}_XX...
>> I found a workaround with adding "unset KRB5CCNAME" to /etc/bash.bashrc but
>> this is not very nice.
>> Did anyone had a similar problem and found a solution?
> The KRB5CCNAME environment variable takes precedence over the default
> ccache name.  It sounds like you should check the system dotfiles for a
> KRB5CCNAME assignment and check whether pam_krb5 is doing anything
> special.
>
> -Ben



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos