[OpenAFS-win32-devel] rxk5 openafs for windows work in progress--seems
to work
Jeffrey Altman
jaltman@secure-endpoints.com
Tue, 02 Jan 2007 00:28:14 -0500
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
>