GSoC project proposal: Implement the Negotiate and Kerberos
SSPs based on GSSAPI
kai.blin at gmail.com
Sat Mar 3 13:33:50 CST 2007
On Saturday 03 March 2007 18:35, Dan Kegel wrote:
> Kai wrote:
> >My toy idea is to not implement the ASN.1 stuff myself but instead make
> >use of GSSAPI for this....
> Can you explain for us non-knowledgeable folks what ASN.1 stuff
> you're talking about?
ASN.1 is a standard, formal method of describing communication protocols,
among other things. (See http://en.wikipedia.org/wiki/ASN1)
Negotiate (called so by Microsoft, RFC 2478 calls it SPNEGO) uses the
distinguished encoding rules. So does Kerberos 5.
If I want to work with SPNEGO data coming over the wire, I need a DER parser.
There's libtasn1 from the GNUTLS project, but that's unusable due to licensing
reasons. I haven't looked into using e.g. Heimdal's asn1 lib, though.
> >Should using GSSAPI not work for us for whatever reason, I think it should
> > be well within the GSoC timeframe to bite the bullet and cobble together
> > an ASN.1 parser for Negotiate, handle negotiation in Wine and use libkrb5
> > for Kerberos.
> When I first looked at gssapi back in '98 or so, it seemed to
> be mostly an annoying convenience layer that just got in
> the way of my project (which was to add authentication to
> a network game library).
Incidently, this is the way Microsoft went with DirectPlay. (Up until dplay9,
where they added a SHA-1 checksum (and another checksum they call 8-bit, I
haven't looked at that yet.). But I'm rambling.
> Here's a rule of thumb: if a convenience layer does any networking
> for you, it will do it wrong. Let's look at Heimdal's
> networking, for instance. In heimdal, its networking
> implementation uses select(). We've spent a lot of time purging
> all select()'s from Wine's source tree because any application
> that uses select() breaks once you have fd's in your app with
> values above 1024. Sure, we can fix that by submitting
> patches to Heimdal to use poll() instead, but there are are
> sure to be other problems.
> The best thing to do is eschew all functions that do networking
> for you, and do it all yourself.
Yeah, that makes sense to me. SSPI doesn't do networking, either. :)
> So, can you do what you're thinking of without being forced
> to let gssapi do networking for you?
As far as I can see, GSSAPI doesn't do networking at all. Heimdal's example
code uses krb5_send to send stuff, but the mit example code uses plain POSIX
GSSAPI is more interesting than my last try with GENSEC, as GSSAPI is
MIT-licensed. I've been burnt by licensing issues before, which is why I have
a backup plan this time, and that's reinventing the wheel if I can't use the
old one. I'd just like to avoid it if possible.
Kai Blin, <kai Dot blin At gmail Dot com>
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin/
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070303/f5d3fa16/attachment.pgp
More information about the wine-devel