[OpenAFS-devel] aklog on MacOS X was Re: Service Ticket Questions

[Jeffrey Altman]

<Taking krbdev@mit.edu off the list>

Henry B. Hotz wrote:
> In this case you get tokens when you can and you don't when you can't  
> (like user/admin isn't in AFS).  I believe our existing AFS kernel  
> code can keep track of the tokens as-is.  If the Kerberos GUI showed  
> afs service tickets only for those identities that got valid afs  
> tokens and not otherwise then we're good.

AFS stores tokens in the uid of the user that acquired the tokens.
If you already obtained tokens for hotz@JPL.NASA.GOV and then call
kinit hotz/admin@JPL.NASA.GOV, then the AFS tokens belonging to
hotz/admin@JPL.NASA.GOV for the jpl.nasa.gov cell would replace the
tokens obtained for hotz@JPL.NASA.GOV.

In Kerberos.app you would see two credential caches with two sets
of tickets.  One for hotz@JPL.NASA.GOV and one for
hotz/admin@JPL.NASA.GOV.  For each one you would see at least a TGT
and an afs/jpl.nasa.gov@JPL.NASA.GOV service ticket.

> Just to bring another issue into the discussion.  What about if we  
> use something besides Kerberos to get AFS tokens?  Apple seems to be  
> headed in the direction of using the Keychain Manager to show PKI- 
> based permissions.  That's a pretty disjoint GUI from Kerberos.app.   
> My belief is that that's far enough off that it's worth doing  
> something about the UI confusion with tokens and Kerberos anyway.   
> Something to ponder in odd moments.

If you used something other than Kerberos to obtain the AFS tokens
then you would not have an afs service ticket in a Kerberos credential
cache for that token.  However, you would still have a token that you
would only be able to list with the afs "tokens" command.

What you really want is for Apple to provide an equivalent of the
Network Identity Manager that Asanka Herath built for Microsoft Windows.
The framework provides a concept of an Identity Module.  There can be
Identity modules for Kerberos 5, X.509/SmartCards, etc.  In addition
there are Credential modules.  We have Kerberos 5, Kerberos 4, AFS,
and there could be KX.509, etc.  The user has the ability to obtain
credentials for multiple identities at the same time.  With each
Identity module there is a primary Credential module.  The primary
credential module is responsible for performing functions such as
automatic renewals.  After the primary credential defining an identity
is obtained either initially or upon a renewal, the identity module
calls each of the credential modules to obtain credentials that are
derived from that identity.  This allows a Kerberos 5 TGT to be used to
obtain a Kerberos 4 TGT and as many AFS tokens for as many AFS cells as
are required by that identity.  Each identity can have a separate list
of AFS cells and the mechanism used to obtain the tokens (Kerberos 5,
Kerberos 5 to 4 translation, etc. can be specified per cell.  If there
was a KX.509 credential module then it could be used to obtain X.509
client certificates.

Going in the reverse direction, a X.509 Identity manager could use an
X.509 client certificate or a smartcard to obtain a Kerberos 5 TGT via
PK-INIT.  The AFS tokens could then be obtained either with the
certifcate or with the derived Kerberos 5 credential.

The credential modules are also responsible for feeding all of the
credential data into a unified GUI.  The users can then choose to
display their credentials organized by Identity and Type, or Type and
Identity, or by Location (credential store), or by a custom order
determined by manual column sorting.  Users can also choose how much
data is displayed about each credential.

This tool could be integrated with support for WS-Trust and become an
InfoCard provider.

The benefits of a tool such as the Network Identity Manager for the end
user is that there is a single location that the users go to in order to
display and manage all of their security credentials regardless of how
the credentials are obtained.

At the moment we don't have such a framework for MacOS X.  Therefore, we
have to manage with what we've got.  In that situation the appropriate
thing to do is to provide a separate AFS Token Manager tool that
displays AFS tokens for the end user regardless of what is reported by
Kerberos.app.  Kerberos.app shows the contents of the Kerberos
credential caches and that is all.  Kerberos service tickets are
preserved in the cache to optimize the time it takes to provide
applications tickets when they are asked for repeatedly.   The Kerberos
credential cache is not bound to the contents of the AFS kernel module.

Any attempt to use the Kerberos credential store contents to indicate
the presence or absence of an afs token is going to result in confused
users at one time or another.  Support personnel can use the Kerberos
credential cache as a debugging tool.  They can't use it as an indicator
 that an AFS token exists for any particular cell and principal name at
any given time.

I believe the following GUI tools are required for AFS:

(1) an AFS token manager.  This tool displays the current tokens and can
be used to obtain new ones or remove the existing ones.  This could be
replaced by a Network Identity Manager type tool if it was provided by
Apple.

(2) an AFS System Preferences tool which can be used to modify the
startup parameters for the AFS kernel module, probe the AFS Cache
Manager status, and configure the list of cells for which tokens should
be obtained when a kinit or login is performed.

(3) an AFS Finder Extension that would allow the user to manipulate
mount points, ACLs, Flush Files, Directories, or Volumes, and show
various AFS related information as reported by "fs examine" or "vos
examine".

This is not a small amount of code to write and we will need resources
in order to be able to produce it.  Anyone interested in volunteering is
invited to contact the OpenAFS gatekeepers.

Jeffrey Altman