[16719] in Kerberos_V5_Development
Re: Credential collections
daemon@ATHENA.MIT.EDU (Nico Williams)
Wed Mar 23 16:27:07 2011
MIME-Version: 1.0
In-Reply-To: <201103231956.p2NJugcn009682@outgoing.mit.edu>
Date: Wed, 23 Mar 2011 15:27:02 -0500
Message-ID: <AANLkTikC93-XMWamjCxhiCk6S7q_VKRcP68P1N2uN_DE@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: ghudson@mit.edu
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Wed, Mar 23, 2011 at 2:56 PM, <ghudson@mit.edu> wrote:> We need to decide how, in the core Unix code, to handle credentials> for multiple client principals. There are three facets to this> problem: API, CLI, and representation.>> API> --->> Most prior work on this problem has assumed that each ccache is for> one client principal. This is not actually required by the krb5_cc_*> data model; I think the idea flows mostly from the traditional> behavior of kinit and kdestroy.>> We have a krb5_cccol_* API for iterating over all known ccaches;
So, the problem with ccache collections is that they really bleed intothe UI. Why should the user have to be aware of per-principal ccachesand then, on top, a collection of those, when the user only reallycares about the TGTs they have, not the cached non-initial/non-TGTtickets?
One answer might be that the user might want to use subsets ofcredentials for different applications. But this is a difficultproblem because of the need to group processes that should seeparticular sets of credentials, and each OS has a different approachto this, thus this is a problem best left to the integrators. Buteven granting this answer, I think I'd rather deal in views intocredentials sets than in collections of ccaches (and if you ask whatthe difference is, the answer to that is that "ccache" is not reallysomething that users should have to be aware of).
The same, incidentally, goes for the developer. As a developer I wanta single object handle to represent access to the credential store,and I want to be able to list the client principals for which thereare credentials, and I want to be able to ask for specific tickets. Accache collection concept isn't terribly complex, but it will requiremore code if the developer has to first grab a ccache from thecollection then call krb5_get_creds() or whatever.
I'd rather add a new ccache type, APIs and CLIs for those, thatprovide a collection than add a new abstraction. Even better: I'drather extend the existing ccache file format (or not -- just clusterall TGTs in the beginning when adding credentials for additionalprincipals). Even better: I'd like a SQLite3-based ccache type and,for compatibility with non-JNI JGSS programs and programs linkedstatically, have the code also append tickets to a v4 ccache (but notsearch it).
> Heimdal supports that as well (as well as its own> krb5_cc_cache_get_first and krb5_cc_cache_get_next APIs, which operate> on a single type). The implementation works best with a daemon-backed> ccache type like API or KCM.
Well, if the implementations exist, then it's too late, and you canjust ignore the above comments.
> The options I can see for ccache lookup from the GSSAPI krb5 code are:>> 1. Use the krb5_cccol_* API, possibly adding a search operation to> that API.>> 2. Reject the idea of a cache collection iterator, and just look for> credentials of the desired client principal within the default ccache.>> 3. Use the richer kim_ccache_* API. (Requires using KIM for the first> cut implementation, which may require more resources than we have> available for this.)>> I personally prefer option 2 except that it ignores previous work.
I prefer extending the existing API to a new abstraction that buildson the old one. But if the Heimdal interfaces are gaining tractionthen you won't have much choice.
> CLI> --->> kinit and kdestroy can be used to manage multiple ccaches using the -c> flag, but it's not very convenient. The only previous work I'm aware> of in this area is in KfM, which has the following extensions:>> * "kinit principal" scans the collection for a ccache for principal,> and creates a new unique CCAPI ccache if one doesn't exist.>> * "klist -A" lists creds for all ccaches in the collection.>> * "kdestroy -A" destroys all ccaches in the collection. "kdestroy -p> principal" scans the collection for a ccache for principal and> destroys it.>> * "kswitch -c ccname" or "kswitch -p princname" sets the default> ccache in the collection. (In the normal case this translates into> a message to the CCAPI daemon. When KRB5CCNAME is set the semantics> are confusing to me and possibly broken.)
I like this except for the kswitch -c ccname case.
> The kinit change is substantial; users accustomed to the old behavior> could wind up leaving tickets around.
Indeed. I'd be happy with needing an option to not clobber the priorcredentials.
> Options I can see are:>> 1. Implement the KfM extensions.>> 2. Implement the KfM extensions, but require a kinit flag to use the> collection.
2, and/or with a krb5.conf param in addition to a kinit option.
> If we reject the idea of iterating over a cache collection, then the> KfM extensions would need to be adjusted somewhat to make sense.
Yes, but fortunately the ccache collection concept hasn't bled toomuch into the CLI.
> Representation> -------------->> Iteration over ccaches currently works best with a daemon-backed> ccache type. The daemon acts like a non-persistent filesystem> containing only ccaches, which makes it easy to search.>> Unfortunately, we don't have a daemon-backed ccache type in the core> krb5 Unix code yet. One possible answer is that this whole project> should gate on a CCAPI or KCM implementation for Unix in MIT krb5. If> we take that as the path, I'm guessing we could get the daemon-backed> ccache done for 1.10, but probably nothing beyond that in the client> identity selection space.>> So, some other options:>> 1. If we reject the idea of iterating over a cache collection, the> representation problem becomes easy; credential collections are just> FILE-format ccache files containing tickets for multiple client> principals.
The main problem with this is that if the ccache gets large thensearching for credentials gets painful. My proposal would be thatwhenever TGTs are added the ccache is re-written from scratch, withall TGTs coming first, then all other INITIAL tickets, then allcached, still-live non-INITIAL, non-TGT tickets.
My solution to the perf problem in general would be to use SQLite3 anda v4 ccache file, with all searches done via the SQLite3 DB and alladditions done to both.
> 3. We could create the notion of a per-uid directory of ccaches, and> try to somehow migrate there from the current default ccache names> (typically /tmp/krb5cc_*, often chosen by pam_krb5 or similar).
I do believe that PAM / login is the best place to create somethinglike /var/run/krb5/ccache/<UID>/. This would instantly defeat thesorts of attacks available when using well-known file names in /tmp/.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
