ccache using linux keyring

[Alexandra Ellwood]

On Apr 14, 2005, at 2:39 PM, Kevin Coffman wrote:

>>
>>> This assumes that my default realm is CITI.UMICH.EDU and I've gotten
>>> several ticket for the CITI.UMICH.EDU realm.  Then I've done
>>>     % setenv KRB5CCNAME KEYRING:/tmp/krb5cc_20010_umich
>>>     % kinit kwc at UMICH.EDU
>>> and then ran the utility to make /tmp/krb5cc_20010_umich my active
>>> ccache.  gssd will then try to use my UMICH.EDU tickets to get
>>> service tickets to negotiate NFSv4 gss contexts.
>>>
>
> After discussing this here with Bruce, I think having more than one
> ccache in the session ring is unnecessary.  If you want to do this
> sort of thing, you would do the equivalent of a setpag and get into
> a new session keyring.  That still leaves the problem of gssd finding
> the ccache w/o environment variables.  However, naming the keyring
> something like "krb5ccache:<residual>" and having only one ccache
> in a session ring would allow it to work.

There are a bunch of Kerberos sites with multiple realms which for  
various (political) reasons cannot share keys.  As a result, users at  
these sites need to get multiple TGTs for different client principals  
(ie: me at A.EXAMPLE.COM, me at B.EXAMPLE.COM, etc).  When using file or  
CCAPI based ccaches, these sites currently get one ccache per client  
principal and use KRB5CCNAME or the CCAPI default ccache concept to  
control which applications are using which sets of tickets.

Single sign-on issues aside, these sites would like their users to  
not have to constantly switch which ccache they are looking at.   
Instead, they want the Kerberos libraries to search for the correct  
principal (based on heuristics yet to be determined).  Given the way  
the existing ccache formats work, this would most likely involve  
searching over a list of ccaches.

Anyway, you might want to keep these sites is mind when deciding  
whether or not the keyring implementation will support multiple  
ccaches in a single keyring.  Even if it is possible to search across  
multiple keyrings, doing so would add keyring-specific code to the  
searching code in the krb5 libraries.  This would be undesirable  
because of the increased complexity.


--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>