[OpenAFS-devel] configurable cryptosystem support

[Marcus Watts]

Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> Date: Thu, 18 Jan 2007 16:27:47 -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] configurable cryptosystem support
> Message-ID: <FE486567912DF232337755E1@sirius.fac.cs.cmu.edu>
> In-Reply-To: <200701180937.EAA11984@quince.ifs.umich.edu>
> 
> On Thursday, January 18, 2007 04:37:27 AM -0500 Marcus Watts 
> <mdw@umich.edu> wrote:
> 
> > I'm in the process of adding "configurable crypto support" to k5ssl,
> > part of rxk5 for openafs.  I have the configuration logic working with
> > all the features listed below, I just have to merge it in with other
> > changes also in the queue (such as windows support, verifykt, etc...)
> >
> > At build time, configure -help will advertise this option (among others):
> >
> > 	  --enable-k5ssl-crypto                {,no,only}{des,des3,rc4,aes}
> 
> I'm confused.  Exactly what is k5ssl?  A raw crypto library?  An RFC3961 
> library?  Something else?
> 
> 

There is no portable crypto or kerberos support in any kernel.  So the
original purpose of k5ssl was to provide that support for rxk5 -- um,
yes, that would be more or less RFC 3961,3962,4757,etc, +/- various
features.  Originally I thought most kernel environments would provide
a non-portable crypto interface modelled on openssl, so k5ssl started
off as a kerberos crypto framework wrapped around "libcrypto" from
openssl.  Actual kernels turned out to have much more complicated
crypto interfaces so k5ssl now has its own complete crypto library
(des,rc4,etc.) to provide the basic crypto functions needed as well.

Unless somebody else intends to provide a portable kernel kerberos
framework, I think k5ssl is going to have a permanent role for that.

The only real contender I know of for k5 in the kernel is the CITI
nfsv4 kerberos work which is part of the linux kernel.  Last I saw, it
only did des, & only existed in linux.  At some point I need to compare
notes with Rees & company and see what I have that they don't have &
visa-versa.  < net/sunrpc/auth_gss/gss_krb5_crypto.c >.  At a very
quick glance, it does appear to have a good hookup with the native
linux 2.6 crypto framework.  In fact, its has its own unique api with
a very intimate relation with linux.  While this is all very interesting,
it's a long ways away from being useful for openafs + rxk5.

One of the original charges the openafs folks defined for "rx + k5" was
that it had to not depend on any external library.  I think we can
agree today that wasn't a realistic goal, but as it happens, there are
indeed many challenges in depending on the native kerberos 5
environment.  So, k5ssl has gotten "smarter" - and in userland code
when linked against openssl it was long ago capable of supplying all
the functions needed for an rxk5 server.  Today k5ssl is also capable
of getting service tickets and performing initial authentication, which
are the remaining services needed for rxk5 clients.  This is definite
overkill and in the long run hopefully the need for this will
disappear.  For right now though, it means I can make a self-contained
.dmg file for any modern macintosh that will just install and work
using only the advertised entry points in the macintosh kerberos
environment, which I could not otherwise easily do.

So far as "RFC 3961" +/- features goes -- the s2k functions in those are
only needed for initial authentication, and are never needed in the kernel.
So k5ssl provides that as a separate module that isn't built for the
kernel.  RFC 3961 defines a "pseudo-random" function for each crypto
system.  I would dearly love to use that in rxk5 - but I don't know
of any public implementation, entry points, or test vectors.
RFC 3961 contains a set of 'assigned numbers' for crypto systems,
but specifically omits any mention of which ones might be "required".
I don't know of any current k5 standard that doesn't "require"
des-cbc-crc, but I think we all agree we want to be able to build
openafs without this, so what I'm providing here is a mechanism where
people can do this.  I added additional flexibility in part because I
want to be able to easily test the "PGetCapabilities" call, which is
one of the other things on my queue of "things to do".

				-Marcus Watts