[OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT

[Marcus Watts]

> Date: Fri, 16 Feb 2007 12:50:38 -0500
> From: Jeffrey Hutzelman <jhutz@cmu.edu>
> To: Marcus Watts <mdw@umich.edu>, openafs-devel@openafs.org
> cc: Jeffrey Hutzelman <jhutz@cmu.edu>
> Subject: Re: [OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT
> 
> 
> 
> On Friday, February 16, 2007 06:32:45 AM -0500 Marcus Watts <mdw@umich.edu> 
> wrote:
> 
> 
> > The intention is that the "generic" token interface be capable
> > of being augmented with with future token types (such as rxgk) in
> > the future.  The assumption is that in a given realm,
> > all db & file servers be capable of dealing with the same
> > credential type, and that is the responsibility of aklog/klog,
> > with input from the user & from the kdc, to get the appropriate
> > credential.  The "capability" call is intended to return
> > information on cm capabilities.  For now it only supports
> > rxk5 encryption types.  In the future, it might also return
> > information on other things, or have a companion pioctl
> > to allow setting things.  This might be used to get/set
> > locking behavior or fs setcrypt.
> 
> We bashed out a lot of the details of what the new interfaces will look 
> like and what the fallback and transition mechanisms need to be at the rxgk 
> hackathon last month.  Details, including the specifications for the new 
> VIOCGETTOK2 and VIOCSETTOK2 pioctls, can be found at
> 
> <http://www.afsig.se/afsig/space/rxgk-client-integration>
> 
> -- Jeff
> 

Interesting.  rxk5 already has a VIOC_GETTOKNEW VIOC_SETTOKNEW using
_CVICEIOCTL(7) and (8).  Is this a proposal to build on top of that
interface?

				-Marcus