advice on kerberizing products

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

advice on kerberizing products

Kristen J. Webb
Hi All,

I originally posted this to the krbdev list, and was pointed
here.....

After doing some research on my own, I now have lots of questions.
I have a simple implementation that uses sendauth and recvauth
as a starting point.  It works on my setup, but when I try it in a
Heimdal environment I get some expected results:

h.test: error while loading shared libraries: libcom_err.so.3: cannot open
shared object file: No such file or directory

Trying to be clever, I link it to a previous version:

ln -s libcom_err.so.2.1 libcom_err.so.3

h.test: /usr/local/lib/libcom_err.so.3: no version information available
(required by h.test)

So now I'm thinking that static linking is the way to go.
BTW: we used static linking in a previous kerb4 implementation.

However, when I try to configure with --enable-static
Both 1.6.3 and 1.5.4 give the same error:

configure: error: Sorry, static libraries do not work in this release.

I even tried going all the way back to 1.4.4, where
configure worked, but make bombed right away.

1. Is there an MIT release that is recommended for doing static builds?

2. If not, should I be considering building against Heimdal instead?

3. My original goal was to provide a kerberized binary that would work
in both environments.  Are there any other recommendation or advices
on how to do this?

Thank you very much in advance!

Kris
--
Mr. Kristen J. Webb
Teradactyl LLC.

PHONE: 1-505-242-1091
EMAIL: [hidden email]
VISIT: http://www.teradactyl.com

  Home of the

  True incremental Backup System

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: advice on kerberizing products

Ken Hornstein
>After doing some research on my own, I now have lots of questions.
>I have a simple implementation that uses sendauth and recvauth
>as a starting point.  It works on my setup, but when I try it in a
>Heimdal environment I get some expected results:
>[...]

You've discovered an unfortunate truth - it's difficult to ship a
third-party application that links against Kerberos libraries and
expect it to be portable.  And since the Heimdal and MIT Kerberos
libraries aren't API compatible, you either have to pick one or the
other, or port to both (in my experience, porting to both isn't hard,
it's just annoying).

More and more operating systems are shipping with Kerberos libraries, but
they're not universal just yet.  I can only offer suggestions based on what
I have seen other vendors do in your position:

1) Dynamically load all Kerberos functions at runtime with dlopen() or
   the equivalent.

2) Encapsulate all of your Kerberos functionality into an open-source
   module or program and have your customers compile that particular bit
   themselves.

3) Include with your product a complete copy of whatever Kerberos
   implementation you prefer.

>From the customer's perspective, 1) is easier.  2) is easier for you,
as it pushes some of the issues back onto the customer, but it might
present some interesting support challenges.  I don't recommend 3); I'm
only including it for the sake of completeness.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: advice on kerberizing products

Tim Alsop-2
Ken wrote:

> You've discovered an unfortunate truth - it's difficult to ship a
> third-party application that links against Kerberos libraries and
> expect it to be portable.  And since the Heimdal and MIT Kerberos
> libraries aren't API compatible, you either have to pick one or the
> other, or port to both (in my experience, porting to both isn't hard,
> it's just annoying).

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.

> More and more operating systems are shipping with Kerberos libraries,
but
> they're not universal just yet.  I can only offer suggestions based on
what
> I have seen other vendors do in your position:

> 1) Dynamically load all Kerberos functions at runtime with dlopen() or
>    the equivalent.

> 2) Encapsulate all of your Kerberos functionality into an open-source
>    module or program and have your customers compile that particular
bit
>    themselves.

> 3) Include with your product a complete copy of whatever Kerberos
>    implementation you prefer.

4) Since your company is developing and selling commercial products to
   customers and providing support service that the customer expects for
   such products, perhaps you could partner with a vendor who provides
   a cross platform Kerberos implementation, so you get a consistent and
   supported solution, for any operating system your product may run on.

   Also, your customers get a complete solution that is fully supported
   by yourself and the partner company. I represent one such company,
   namely "CyberSafe".

> From the customer's perspective, 1) is easier.  2) is easier for you,
> as it pushes some of the issues back onto the customer, but it might
> present some interesting support challenges.  I don't recommend 3);
I'm
> only including it for the sake of completeness.

I don't recommend option 3 either, but there are companies that have
chosen this
path, e.g. Oracle. Instead, I recommend you look at option 4.

Thanks,
Tim


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: advice on kerberizing products

Simon Wilkinson
In reply to this post by Ken Hornstein

On 23 Apr 2008, at 20:23, Ken Hornstein wrote:

>>
> 1) Dynamically load all Kerberos functions at runtime with dlopen() or
>    the equivalent.
>
> 2) Encapsulate all of your Kerberos functionality into an open-source
>    module or program and have your customers compile that  
> particular bit
>    themselves.
>
> 3) Include with your product a complete copy of whatever Kerberos
>    implementation you prefer.

4) Use GSSAPI

If you only need the functionality that the GSSAPI interface  
provides, then using it can be far more portable than native Kerberos  
calls. For example, Mozilla ships precompiled binaries for both  
Firefox and Thunderbird which work with any vendor's GSSAPI libarary.

S.
 
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: advice on kerberizing products

Kristen J. Webb
Hi Simon,

My current concern with the GSSAPI approach is that
I do not understand how tightly bound it is
with Kerberos yet (or vice-versa).  Is it possible
that I may run into situations where Kerberos
is used w/o access to gssapi libraries?

If so, would I be back to Ken's option 3 with GSSAPI?

BTW: Thanks to everyone for your feedback so far!
K

Simon Wilkinson wrote:

> On 23 Apr 2008, at 20:23, Ken Hornstein wrote:
>> 1) Dynamically load all Kerberos functions at runtime with dlopen() or
>>    the equivalent.
>>
>> 2) Encapsulate all of your Kerberos functionality into an open-source
>>    module or program and have your customers compile that  
>> particular bit
>>    themselves.
>>
>> 3) Include with your product a complete copy of whatever Kerberos
>>    implementation you prefer.
>
> 4) Use GSSAPI
>
> If you only need the functionality that the GSSAPI interface  
> provides, then using it can be far more portable than native Kerberos  
> calls. For example, Mozilla ships precompiled binaries for both  
> Firefox and Thunderbird which work with any vendor's GSSAPI libarary.
>
> S.
>  
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Mr. Kristen J. Webb
Teradactyl LLC.

PHONE: 1-505-242-1091
EMAIL: [hidden email]
VISIT: http://www.teradactyl.com

  Home of the

  True incremental Backup System

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: advice on kerberizing products

Kenneth G Raeburn
On Apr 23, 2008, at 18:12, Kristen J. Webb wrote:
> My current concern with the GSSAPI approach is that
> I do not understand how tightly bound it is
> with Kerberos yet (or vice-versa).  Is it possible
> that I may run into situations where Kerberos
> is used w/o access to gssapi libraries?

For UNIX, rarely, I think.  Both MIT and Heimdal ship libraries for  
both.  The GNU project's Shishi doesn't have a GSSAPI library  
incorporated, but they do have a GSS library available as a separate  
package that could also be installed.  I don't know if there are other  
implementations where you don't automatically get or can't easily get  
your hands on a GSSAPI library.

On Windows, MIT's Kerberos for Windows package provides both  
libraries; if you prefer to go with the native implementation, the  
story is a bit more complicated, but using GSSAPI in your protocol  
still is a win.

--
Ken Raeburn, Senior Programmer
MIT Kerberos Consortium

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: advice on kerberizing products

Ken Hornstein
In reply to this post by Tim Alsop-2
>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.

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 make no bones about not being a huge fan of the GSSAPI, and I
freely admit that I'm in the minority.  I use it when it is appropriate
(basically, when I need to interoperate with a protocol that has
been standardized to use it), but when I write something for myself
I always find the Kerberos API simpler and more versatile.

A few other comments, based on what other people said:

- 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.

  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.  But I will note that in the case
  of Thunderbird and Firefox GSSAPI was the only choice, since the whole
  point of adding Kerberos support to those programs was to support
  protocols that used the GSSAPI.  Well, I suppose Simon could have generated
  GSSAPI tokens using raw Kerberos calls and a lot of bit-fiddling, but
  even I'm not that crazy :-)

- The two major open-source Kerberos implementations include GSSAPI
  libraries.  In theory, depending on who you talk to, there are a billion
  different GSSAPI mechanisms and you have to make sure your code can
  handle non-Kerberos mechanisms.  In practice, however, you can basically
  consider GSSAPI as "the other" Kerberos API.

- 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.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: advice on kerberizing products

Russ Allbery
Ken Hornstein <[hidden email]> 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 ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: advice on kerberizing products

Jeffrey Altman-2
In reply to this post by Kristen J. Webb
Kristen J. Webb wrote:
> Hi Simon,
>
> My current concern with the GSSAPI approach is that
> I do not understand how tightly bound it is
> with Kerberos yet (or vice-versa).  Is it possible
> that I may run into situations where Kerberos
> is used w/o access to gssapi libraries?
>
 From my perspective the win with GSSAPI is that not only do
you obtain a higher degree of platform portability with GSSAPI
than you do with Kerberos v5 APIs, but you also obtain a high
degree of protocol interoperability.

If you restrict yourself to GSSAPI you are able to write services
for UNIX that can communicate with Windows Kerberos SSP
based clients; or Windows Kerberos SSP based services that
communicate with UNIX GSSAPI clients.

In addition, not all of the major UNIX operating systems
expose Kerberos APIs.  The biggest one is Solaris which provides
GSSAPI and no Kerberos v5.

Another reason for avoiding the direct Kerberos v5 APIs
is that it is not simply a MIT vs Heimdal world.  The GNU
implementation is different and even in the MIT derived  family
of implementations there are differences.  Sun has modified
a number of interfaces that make direct compilation against
their headers (if they were available) an additional level of
complexity.

Ken H. is correct that if all you want to do is use Kerberos v5
and you know that is what you need, it is much easier to add
Kerberos v5 authentication by coding to one of the implementations.
It is only when the added complexity of dealing with all of the
incompatible APIs that you are left wondering if the long term
support costs are worth the short term gain in ease of implementation.

Regardless of which method you decide to follow I believe that
dynamically selecting the library to load at runtime has major
benefits for an application provider.  Doing so permits you to
work with a variety of implementations based upon the choices
of the local system administrator and not be dependent upon
the choices of the operating system packager.

I too would avoid SASL unless you absolutely need it because
the protocol you are implementing specifies it.

Jeffrey Altman



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: advice on kerberizing products

Jeffrey Altman-2
Another reason for dynamically loading the libraries with dlopen() is
that your
application is not purely dependent upon Kerberos for authentication.  If
Kerberos or GSSAPI is not available, should your application refuse to
execute?

If the application functionality is useful without network authentication,
then dlopen() is definitely the way to go.

Jeffrey Altman


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: advice on kerberizing products

Douglas E. Engert
In reply to this post by Kristen J. Webb


Kristen J. Webb wrote:
> Hi Simon,
>
> My current concern with the GSSAPI approach is that
> I do not understand how tightly bound it is
> with Kerberos yet (or vice-versa).  Is it possible
> that I may run into situations where Kerberos
> is used w/o access to gssapi libraries?
>

In addition to Ken Raeburn's comments, the original Solaris 10
shipped with the GSSAPI, but hid the underlying Kerberos  API.
But last year they relented and exposed the Kerberos API too.

On Windows the Microsoft SSPI has a different API then GSSAPI,
but they use the same protocol, and can interoperate with
other GSSAPI implementaitons.

Although GSSAPI is generic, and can have more mechanisms then
Kerberos, Kerberos is the predominant mechanism for GSSAPI.

I would go with GSSAPI if at all possible.

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos