[OpenAFS-win32-devel] rxk5 openafs for windows work in progress--seems to work
Marcus Watts
mdw@umich.edu
Tue, 02 Jan 2007 04:16:02 -0500
> Message-ID: <4599ED6E.4070500@secure-endpoints.com>
> Date: Tue, 02 Jan 2007 00:28:14 -0500
> From: Jeffrey Altman <jaltman@secure-endpoints.com>
> To: Matt Benjamin <matt@linuxbox.com>, Marcus Watts <mdw@umich.edu>
> CC: openafs-gatekeepers@openafs.org, openafs-win32-devel@openafs.org
> Subject: Re: [OpenAFS-win32-devel] rxk5 openafs for windows work in progress--seems
> to work
>
> Matt and Marcus:
>
> Thanks for all of the work you've done on rxk5.
>
> I see that Matt is creating a modified version of KFW in order to export
> two functions:
>
> krb5_encrypt_tkt_part() and encode_krb5_ticket()
>
> I also see Marcus has provided definitions for both of those functions
> within afs-rxk5-r1512-m34.patch as part of k5ssl [1]. Am I reading the
> code correctly that k5ssl is an implementation of the MIT krb5 API
> implemented on top of OpenSSL's libcrypt? If so, under what
> circumstances is this functionality being used? I don't think we want
> to be importing a krb5 library into the OpenAFS distribution. That
> would make three that we are supporting: (Heimdal, MIT and k5ssl). [2]
>
> One of my serious concerns about k5ssl is that it is exporting functions
> that are private symbols in the MIT API. It is one thing to provide an
> alternate implementation of MIT's API but if that is what we are going
> to do, then we need to adhere to their API and not or utilize symbols
> that are private within their name space. If we want to extend their
> API, that is fine but we must do so without causing pollution. Any
> functions we add should use a function name prefix that we lay claim to.
> For example "afskrb5_" or "rxk5_krb5_", etc.
>
> I do believe the hardest political job we are going to have is in
> convincing MIT to accept a new API. If MIT were to publish a public
> version of encode_krb5_ticket() for example, it would look like this:
>
> krb5_error_code KRB5_CALLCONV krb5_encode_ticket
> (krb5_context ctx, const krb5_ticket *rep, krb5_data **code);
>
> The function would be exported on Windows as __stdcall (KRB5_CALLCONV)
> and not __cdecl (KRB5_CALLCONV_C). The function being public would
> accept a krb5_context as the first parameter regardless of whether or
> not it is used. If we are going to declare such a function, lets at
> least follow their conventions but not pollute their name space.
>
> One of the things that I feel very strongly about is that until
> such time as MIT decides to export this functionality, we can't
> ship modified versions of KFW. For testing privately that is ok
> but we really can't be distributing those libraries. This leaves
> me with two thoughts:
>
> (a) OpenAFS for Windows can shipped a modified MIT krb5_32.dll
> under the name afskrb5_32.dll and include it as part of the
> OAFW installer. This library would effectively re-export
> the contents of the krb5_32.dll library and add copies of
> the functions that are not being exported.
>
> (b) Since we have k5ssl and I already build OpenSSL for many other
> purposes, perhaps a short term solution would be to build k5ssl
> for Windows and statically link to libeay.lib.
>
> Regarding afscreds.exe, it is deprecated. I do not want to
> see more work be done on it. It may be in OpenAFS 1.6 or it may
> not be. I would rather it be left alone. The Network Identity
> Manager plug-in was designed to permit new token acquisition methods
> to be added. I would prefer to see that be the only GUI method for
> obtaining krb5 based tokens.
>
> My final thought is on the subject of DES. The Elders have issued
> a statement that we are removing support for DES. rxk5 is part of
> that solution. I would prefer that rxk5 not provide any support
> for DES. (If rxk5 must provide support for DES, it must include
> DES-CBC-MD5 and DES-CBC-MD4 in addition to DES-CBC-CRC. Windows 2003
> really doesn't want to use DES-CBC-CRC.)
>
> That's all for now.
>
> Happy New Years!!!!
>
> Jeffrey Altman
>
> [1] k5ssl is in my opinion a horrible name. We aren't implementing
> RFC 2712 and we aren't implementing "ssl" and if we were we should be
> calling it "tls". If this is a private version of a krb5 library for
> openafs then lets call it that: "afskrb5". The fact that it is
> implemented on top of OpenSSL's libcrypt is really irrelevant.
>
> [2] OpenSSL may very well be interested in importing some krb5
> functionality into their ASN.1 library in order to be able to implement
> RFC 2712 without relying on the ASN.1 library from MIT or Heimdal.
>
>
>
>
> Matt Benjamin wrote:
> > Hi Guys,
> >
> > I've made all the pieces of the openafs for windows rxk5 port
> > available--the thing appears to work, though I'm the only one it has
> > worked for thus far.
> >
> > I'm sending this in the current form per Derrick's request, not to
> > submit it per se, obviously. Marcus plans to merge applicable changes
> > to his head branch, which has MacOS and other changes, and make new m*
> > patches available, as normal recently.
> >
> > There are several bits (source patches, installers, etc), and links to
> > download them, and brief writeup, are here:
> >
> > http://linuxbox.com/tiki/tiki-index.php?page=winrxk5
> >
> >
> > Matt
> >
> > Derrick J Brashear wrote:
> >> could we see the windows work in progress?
> >>
> >> On Wed, 6 Dec 2006, Matt Benjamin wrote:
> >>
> >>> I'm working on Windows rxk5, and could have something to merge with
> >>> Marcus fairly shortly (if that's relevant). I'm happily using the
> >>> Unix stuff at 1510-m28.
> >>>
> >>> Matt
> >>>
> >>> Jim Rees wrote:
> >>>> Is it time to drop this into 1.5.x, or at least HEAD?
> >>>>
> >>>
> >>>
> >
> >
> > --
> >
> > Matt Benjamin
> >
> > The Linux Box
> > 206 South Fifth Ave. Suite 150
> > Ann Arbor, MI 48104
> >
> > http://linuxbox.com
> >
> > tel. 734-761-4689
> > fax. 734-769-8938
> > cel. 734-216-5309
> >
>
>
Happy New Year!
Hm. The following is way too long. Sorry for the length
but I wanted to try to answer as many of Jeff's points as I could.
Yes, "k5ssl" turns out to have to been a less good name in retrospect.
I think I prefer k5afs to your suggestions; mostly because it's
shorter to type. Early versions of k5ssl had 2 character source file
names, so that "wc ??.c" produced interesting results.
It's been my goal all along to use the existing kerberos libraries
where possible. In fact, rxk5 has support for yet another kerberos
library - shishi. This was mostly proof of concept; there are
licensing and code maturity issues for actually using it.
I'm not wild about the resulting ifdef mess either, although
honestly heimdal wasn't much better.
k5ssl is there mainly to deal with things where the existing kerberos
libraries don't handle. The first & foremost reason is to support
kerberos 5 crypto functionality in the kernel. I don't think there's any
real alternative here in terms of portability and functionality. Linux
has a limited subset of kerberos 5 functionality inside of the kernel
(for nfsv4, des only); other operating systems provide only basic
crypto code mainly for use with ipsec with various idiosyncratic
interfaces.
There are a number of problems with existing kerberos libraries -
including:
//1 - krb5_decrypt_tkt_part
this is a server-side problem, especially with
pre-packaged MIT kerberos.
The problem is that the server needs to decrypt/decode the
ticket, verify it's a good ticket, then decrypt the
authenticator, and use that to initialize the server side of
the connection. A key function here is the function of
krb5_decrypt_tkt_part, which is trivially provided by heimdal
and shishi. Only in MIT, and mostly (only?) in prepackaged builds,
this function isn't available, nor is any interface available
that allows this to be easily implemented. I talked with Sam
Hartman about this, and I think we have more or less an
understanding about a function that would solve this and answer
Sam's concerns. It's going to take a while for that to
propagate out...
//2 - com_err issues.
Each of these might exist and is likely to be an afs issue in a
given environment. They all has gratuitous incompatibilities, and
often also depending on version & build configuration:
e2fsprogs - tytso, debian linux
heimdal - kth, various
mit - from source for unix,
also windows, macosx, solaris
and especially (!) openafs
problems include:
compiling error tables
non-standard bases - or openafs special errors
linking error tables into error table list.
pthread support
lower-case (negative) error codes
long vs. int error codes.
Presumably all of these can be worked out. Someday.
So far, people mainly ignore these. In the openafs distribution,
aklog reports numeric codes. That sucks.
//3 - ability to "forge" tickets - or
krb5_encrypt_tkt_part() and encode_krb5_ticket()
This is needed by "-localauth". Traditionally, this is
part of the kdc, so the relevant code doesn't necessarily
have public interfaces. Um. Yes, this is something else
to talk with Sam Hartman about.
//4 - unoptimized crypto
Existing kerberos code is targetted mostly at "low performance"
use such as initial authentication. Little work is put
into using hardware assist, inner loops in assembler, etc.
There's also the case of environments that don't have kerberos
or want the flexibility to independently upgrade kerberos and openafs.
Yes, supporting an extra different kerberos API would be a problem. To
avoid that, k5ssl implements something that is very close to the MIT
api. That's one of the reasons k5ssl uses MIT function names wherever
possible. Places where k5ssl provides "private" functions not part of
the api are prefixed krb5i_. It is unfortunate that Heimdal and MIT
use the same function names, yet different field names. Partly as a
sign of protest (but mostly because I don't believe in magic), k5ssl
uses the same field names as MIT with different offsets. Mixing any of
k5ssl,mit,heimdal will produce sickness or core dumps. If you wouldn't
want to mix mit+heimdal, then by the same token you shouldn't want to
mix k5ssl+mit or k5ssl+heimdal.
For krb5_encode_ticket, that's certainly up to the MIT folks.
They already provide a krb5_decode_ticket that doesn't
require a context, & there are a handful of other such
"special" functions.
For what it's worth, there are a few places where the MIT
API has particularly annoying problems:
* krb5_get_prompt_types is a really sucky way to avoid adding
adding ".type" to krb5_prompt.
* krb5_check_transited_list takes a krb5_data -- in
fact .tr_type is ignored. Logically it should take
a krb5_transited and emit KRB5KDC_ERR_TRTYPE_NOSUPP
(or some server side analog) if .tr_type !=
KRB5_DOMAIN_X500_COMPRESS.
But these are just pet peeves of mine...
Yes, the "ssl" in k5ssl means eay ssl or openssl. It doesn't mean ssl
per se, so "tls" would be just plain wrong--I think. In unix there are 2
libraries for openssl: libssl which I don't use, and libcrypto, which provides
basic crypto, asn.1, and a 'generic' interface to the crypto
functions. Only the stuff in libcrypto is useful for kerberos 5. I
choose to the use the "wrapper" crypto stuff in openssl, mostly in the
(probably mistaken) belief that it would be similar to the crypto
support found in some modern kernels. It turned out the crypto support
in the first two kernels we looked at (linux, openbsd) were much more
different and complicated than we had expected, so I put together a
companion crypto library using a similar interface to openssl for use
inside the kernel. Using a "similar" interface allows to me to cheat
again: by keeping the same API I don't have to maintain an extra
different kind of code.
Actually, the OpenSSL folks already have some basic asn.1 decoding
routines in libcrypto already. (Probably broken -- bitstrings in k5
are weird.) There's almost certainly an opportunity here. My openssl
asn.1 parsing code is not very clever and doesn't use the really pretty
macros they have - it probably could be much shorter and nicer if it
did. The MIT folks seem to positively hate openssl (licensing problems
or something else?), although heimdal can build with openssl. The cool
thing about openssl is that lots of people have put work into assembler
assist & hardware support. The licensing problem concerns me a bit; I
don't know if that's really a problem.
For des - rxk5 has only very limited knowledge of des (or any other
crypto system.) It (and k5ssl) absolutely does support des-cbc-md4 and
des-cbc-md5. rxk5 is intended to not require des and to be capable of
running in a des-free environment. k5ssl has support for des - but all
of it can be easily turned off. I went to some effort to make sure
that all of the crypto systems it supports can be independently turned
on & off. There's a file "k5s_config.h" that defines what it supports;
right now that's statically made, but it could easily be made
configurable. There's also some makefile magic that would need to be
done to make that work right. Of course, if the intent were to just
not provide it, statically turning it off would suffice. Probably
something should be done about rc4-hmac-exp as well; Heimdal choose not
to support it and that's probably a good thing today. The main reason
for the des code (and the experimental cast,rc6 code) is to ensure that
the basic framework correctly handles all the corner cases.
Interesting things happen when the checksum size != block size.
I agree shipping modified special versions of KfW is unpalatable.
Either of your solutions seems workable in theory. Adding
encode_krb5_ticket does present one problem; there's the pyramid of
functions it in turn depends on that also have to be implemented.
There is an alternative implementation of this in k5ssl (which uses
asn.1 functions from openssl). Or the heimdal parser could be used as
was done for rxkad's k5 ticket handling. For k5ssl, I think the only
real problem is deciding how to handle the credential cache. If need
be, k5ssl does have the framework for adding extra credential cache
types.
I am very much first & foremost thinking of k5ssl as a short-term
solution for all of the various annoying problems. My hope is in the
long-term most of the reason for it will go away. I expect only the
subset needed in kernel to remain as a more or less permament
solution.
I've been telling rees & derrick about successive versions
of rxk5. With the next m release, I will tell
openafs-gatekeepers@openafs.org
unless people object. My hope is to shortly tell openafs-devel@
about it as well.
-Marcus