GSoC project proposal: Implement the Negotiate and Kerberos SSPs based on GSSAPI

[Kai Blin]

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 
send().

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.

Cheers,
Kai

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070303/f5d3fa16/attachment.pgp