advice on kerberizing products

[Russ Allbery]

Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:

>> It is also worth mentioning that GSS-API is closer to being portable
>> than native Kerberos APIs, and you should use GSS as much as possible
>> to avoid some interoperability issues. It also makes your coding a lot
>> easier.
>
> I call "bullshit" on these two statements.
>
> For a SIMPLE program, your first statement is perhaps true.  But I find
> that, for example, MIT and Heimdal have a number of slightly different
> API extensions.  And I see a number of GSSAPI programs that have to do
> some magic to determine which GSSAPI library that they are using.

My experience is that GSSAPI is way more portable than the Kerberos API.
There are a *lot* of annoying little differences in the Kerberos API
between MIT and Heimdal.  Just off the top of my head, krb5_realm is
completely different, looking inside principals works differently, and
there are different free functions when walking through keytabs.  I have
to go to some length to port my software to Heimdal and the portability
glue is often quite annoying.  And it's not a one-time cost; since I
develop on MIT, Heimdal tends to break again unless I explicitly test.

By comparison, GSSAPI needs almost nothing.  The only portability code
that I've had to add for GSSAPI is to get the right library names and
header path, to handle a missing GSS_C_NT_USER_NAME, and to find the name
for GSS_KRB5_MECHANISM, and the latter two are only needed for
compatibility with rather old versions of MIT Kerberos (as I just noticed
that, accidentally, neither probes are even being done by remctl any
more).  Most importantly, none of the function signatures differ, which is
the hardest by far to handle where portability is concerned.

> And coding a lot easier?  I cannot imagine any universe where that is a
> true statement.  I've written both - the Kerberos code is smaller and
> simpler, there is simply no comparison.  Now, on the documentation front
> I will admit that GSSAPI has an edge; the RFC actually isn't too bad as
> documentation.  But I find the abundant Kerberos examples to be fine in
> that regard, and I am guessing that Kris didn't have a problem from that
> standpoint since he already has working code.

I generally agree with this; I also find the Kerberos API easier to work
with (as long as I'm not dealing with the portability mess).

> - To be fair, like Simon pointed out, if all you need is the basic GSSAPI
>   functionality then from a portability standpoint the GSSAPI is
>   probably better.  But if you were Kerberizing something like ...
>   oh, I don't know, let's say a backup system, I would bet that you
>   will quickly find that you want to do things that you cannot do via
>   GSSAPI.

Like obtain initial tickets from a keytab, for which GSSAPI provides no
functionality and which requires diving into the Kerberos API anyway
unless you're willing to require an external program.

>   It's my understanding that Thunderbird and Firefox use dlopen() or the
>   equivalent to load the GSSAPI libraries, which would make then basically
>   option 1, except with the GSSAPI.  I think in terms of portability you'll
>   need to do that anyway, since I doubt that the GSSAPI library versions
>   are the same across Heimdal and MIT.

The library names aren't even the same.

> - While Jeff suggests that you use SASL ... I actually would not.  There
>   is basically only one widely-supported open-source SASL library,
>   and that means you're moving your support issues from Kerberos or GSSAPI
>   into the SASL library.  You can always write your own SASL layer on
>   top of the GSSAPI library ... but I've done that, and that is no fun
>   either.

I agree.  Unless you really want to support non-Kerberos authentication
protocols in the same command set, SASL doesn't buy you very much and adds
a lot of additional annoyances.  (Among other things, Cyrus SASL isn't the
most portable library in the world, and I usually find reasons to dislike
it each time I have to poke at it.)  However, using just GSSAPI locks you
into Kerberos (in practice), which can be a severe limiting factor,
whereas SASL allows all those broken but popular authentication mechanisms
like PLAIN.  Also, SASL EXTERNAL gives you a leg up on doing X.509 if you
don't want to do so via PKINIT.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>