MIT vs Heimdal comparison with respect to GSSAPI library

[Jaideep Padhye]

Thanks a lot for your reply Greg. I have couple more questions:
1] Does MIT GSSAPI/KRB5 have multi-realm support. Can you force the libraries to use the realm you specify for a particular context?
2] Does the MIT GSSAPI support exporting a context and then importing it in a new machine. For example, if  I am running a server on one VM and  I need to transfer the state of the GSSAPI connection to another VM over network. Do you think this is possible with MIT gssapi?



--- On Thu, 1/6/11, Greg Hudson <ghudson at MIT.EDU> wrote:

From: Greg Hudson <ghudson at MIT.EDU>
Subject: Re: MIT vs Heimdal comparison with respect to GSSAPI library
To: "Jaideep Padhye" <jdthebigj at yahoo.com>
Cc: "krbdev at mit.edu" <krbdev at mit.edu>
Date: Thursday, January 6, 2011, 1:07 PM

On Thu, 2011-01-06 at 14:50 -0500, Jaideep Padhye wrote:
> 2] Support for Header signing with all encryption types. I tried using Heimdal 
> recently but their *_iov  functions are not feature complete yet and only 
> support the AES cipher. Does MIT support all ciphers?

Yes, the MIT _iov code supports all ciphers (since 1.7).

> 3] Which one is better for an event driven programming model. I would not like 
> my thread to block until the gssapi finishes its communication with KDC. I would 
> like my code to take care of the IO.

In both versions, the krb5 mechanism will block communicating with the
KDC unless you already have a service ticket for the appropriate
service.  Both versions will also make getaddrinfo() queries which will
block on DNS communication.

Since 1.9, the MIT library supports IAKERB, which proxies AS and TGS
requests through the server side and therefore does not communicate with
the KDC (although it still makes getaddrinfo queries).  Your application
must specify the IAKERB mechanism, and the server must support IAKERB
for it to work.

Alternatively, you can get a service ticket yourself in an event-driven
manner using the krb5_init_creds_* or krb5_tkt_creds_* APIs (the former
for AS requests and the latter for TGS requests), if you have your own
code for communicating with the KDC.  Heimdal only has the
krb5_init_creds_* APIs as far as I know.  MIT has had krb5_init_creds_*
since 1.8 and krb5_tkt_creds_* since 1.9.  Once you have an appropriate
service ticket, you can use the krb5 mechanism without blocking on KDC
communication (although it will still make getaddrinfo queries).

> 4] 64 bit support for Linux

Both libraries have this.

> 5] Compliance with Microsoft implementations (all versions of Windows after 
> Win2k).

Both libraries should be interoperable with Microsoft implementations
modulo bugs (which have popped up in the past but tend to get reported
and fixed pretty quickly).  DCE-style GSSAPI has been available in MIT
krb5 since 1.7.