Discussion:
Credential Cache for multiple client principal names
Rick van Rein
2016-06-29 14:15:11 UTC
Permalink
Hello,

I'm trying to create [1] a mechanism to be used from multiple client
principal names, each with their own service tickets. Secure separation
between the identities is not an issue.

It is not clear to me how to do this. I suspect I should use
DIR:/var/mytool and perhaps KEYRING: on Linux, but it is not clear if
I'm supposed to read and write tickets (including krbtgt) for various
client principal names in the same cache, or that I should instead
iterate it as a credential cache collection, and prod each credentials
cache for the (default) client principal name and add a new one to the
collection if I need it.

Can you help me, or perhaps show me some examples that do this?

Thanks,
-Rick

[1] I'm working on a "TLS Pool" daemon [2] that takes TLS logic away
from applications and that will incorporate a mode for Kerberos [3].

[2] http://tlspool.arpa2.net

[3] https://tools.ietf.org/html/draft-vanrein-tls-kdh-04
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
Simo Sorce
2016-06-29 14:31:50 UTC
Permalink
Post by Rick van Rein
Hello,
I'm trying to create [1] a mechanism to be used from multiple client
principal names, each with their own service tickets. Secure separation
between the identities is not an issue.
It is not clear to me how to do this. I suspect I should use
DIR:/var/mytool and perhaps KEYRING: on Linux, but it is not clear if
I'm supposed to read and write tickets (including krbtgt) for various
client principal names in the same cache, or that I should instead
iterate it as a credential cache collection, and prod each credentials
cache for the (default) client principal name and add a new one to the
collection if I need it.
DIR or KEYRING should be equivalent for your purpose, they are both
cache collections.
Post by Rick van Rein
Can you help me, or perhaps show me some examples that do this?
Have you looked in kinit/kvno/gssapi code ?

If you set up two realms in two separate DNS domains and then kinit to
two different principals, you can see how kvno or any gssapi application
will work to store tickets in the caches to access services in the two
realms.
Post by Rick van Rein
Thanks,
-Rick
[1] I'm working on a "TLS Pool" daemon [2] that takes TLS logic away
from applications and that will incorporate a mode for Kerberos [3].
[2] http://tlspool.arpa2.net
[3] https://tools.ietf.org/html/draft-vanrein-tls-kdh-04
--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
Rick van Rein
2016-06-29 16:05:30 UTC
Permalink
Hello,

Thanks Simo!
Post by Simo Sorce
DIR or KEYRING should be equivalent for your purpose, they are both
cache collections.
Good, I seem to be onto something then :)
Post by Simo Sorce
Post by Rick van Rein
Can you help me, or perhaps show me some examples that do this?
Have you looked in kinit/kvno/gssapi code ?
Thanks! I found that kinit has another instrument, where it has one
cache, but supportive of krb5_cc_support_switch() so I could use
krb5_cc_cache_match() instead of the iteration over a cache collection,
and krb5_cc_new_unique() to add a new identity.

The kinit approach sounds lighter-weight, though I'm not yet clear if it
will let me work on any but the current cache, which could be
problematic since my TLS Pool is multi-threaded, to handle multiple TLS
connections for multiple users.

Any hints on that are welcome of course :)
Post by Simo Sorce
If you set up two realms in two separate DNS domains and then kinit to
two different principals, you can see how kvno or any gssapi application
will work to store tickets in the caches to access services in the two
realms.
Hmm, I tried that with kinit and it was confusing me -- but that might
be because its sole purpose is to initiate a cache. I will try kvno as
well then, good hint :)


Best wishes,
-Rick
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

Loading...