Globus/GSI versus Kerberos

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

Globus/GSI versus Kerberos

Tim Warnock-2

I was curious if anyone has any comments (personal/political/technical)
or could point me to a decent resource comparing Globus versus
Kerberos.  I've had to work with Globus quite a bit, and the overall
trend in the existing GSI-based research grids is to move towards
centrally managed cert/key repositories despite the pure GSI notion of
keeping everything distributed.  There's a handful of new research
projects that basically take GSI and add that "centralized" portion,
although in my opinion it's starting to resemble a Kerberos
architecture.  In my case, in effort to get Globus actually working for
our users, we had to create a similar "centralized" architecture (see
gridauth.com), this ended up purposely abstracting Globus. It's
abstracted in such a way we could easily drop Globus (GSI-based CA) and
replace it with Kerberos or even a simple password hash scheme.  For our
users needs this would be perfectly suitable (and transparent), except
politically it would raise hell.

I know a lot of work has gone into building the bridge between Kerberos
and GSI, but in this case it's more a matter of utilizing a secure
authentication mechanism that's easiest to manage centrally (to the
users and developers it's all abstracted behind RESTful web services).
Any thoughts or advice would be appreciated, technical papers or
security reports comparing the two systems would be great as well.

--
Cheers,

Timothy J Warnock
Senior Data Architect - NEESit
San Diego Supercomputer Center
phone: (858) 822-5473
fax:   (858) 822-5464

University of California, San Diego
9500 Gilman Drive
La Jolla, CA 92093-0505

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

Re: Globus/GSI versus Kerberos

Ken Hornstein
>I was curious if anyone has any comments (personal/political/technical)
>or could point me to a decent resource comparing Globus versus
>Kerberos.  I've had to work with Globus quite a bit, and the overall
>trend in the existing GSI-based research grids is to move towards
>centrally managed cert/key repositories despite the pure GSI notion of
>keeping everything distributed.  There's a handful of new research
>projects that basically take GSI and add that "centralized" portion,
>although in my opinion it's starting to resemble a Kerberos
>architecture.

Back in 1999 during a meeting about inter-operable authentication (it
was actually _at_ SDSC, interestingly enough), Globus was just starting
up (this was back when Legion was still considered a viable alternative
instead of the PhD generator everyone considers it now).  The Globus
guys gave a presentation on their authentication infrastructure, and
I pointed out that they had just reinvented a lot of Kerberos, and asked
them, "How come you guys didn't just use Kerberos?".

I was given what I can only politely say was a song and dance about
Kerberos cross-realm being "too tightly bound to each other", and they
preferred the "looseness" of certificate chaining, whatever that means.

When I cornered one of the Globus guys and asked him point-blank the
same question, he told me that in his opinion the decision to do PKI
was really driven politically from the top, and he thought Kerberos
made a LOT more sense.

In a more practical vein, I will note that Sandia uses (or at least
used to use) Globus with a Kerberos GSSAPI backend instead of the GSI
backend.  This was a few years ago, so I don't know what they're doing
now.  However, they told me that they were still using Globus 1, and
that doing Globus 2 was going to be a real bear because of the changes
they made to the GSSAPI layer for Globus 2 (even doing Globus 1 with
Kerberos required some GSSAPI changes which never made it back to any
of the open-source distributions).  I dunno if they ever went to Globus
2 or not (I made be remembering the version numbers wrong, but to me
this was the gist of what Pat Moore told me).  This to me illustrates
one of the problems with the GSSAPI ... to do the real interesting stuff,
you end up having to dig down into mechanism-specific extensions and
you lose the "generic" part of GSSAPI.

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

Re: Globus/GSI versus Kerberos

Douglas E. Engert
In reply to this post by Tim Warnock-2


Tim Warnock wrote:

>
> I was curious if anyone has any comments (personal/political/technical)
> or could point me to a decent resource comparing Globus versus
> Kerberos.  I've had to work with Globus quite a bit, and the overall
> trend in the existing GSI-based research grids is to move towards
> centrally managed cert/key repositories despite the pure GSI notion of
> keeping everything distributed.  There's a handful of new research
> projects that basically take GSI and add that "centralized" portion,
> although in my opinion it's starting to resemble a Kerberos
> architecture.  In my case, in effort to get Globus actually working for
> our users, we had to create a similar "centralized" architecture (see
> gridauth.com), this ended up purposely abstracting Globus. It's
> abstracted in such a way we could easily drop Globus (GSI-based CA) and
> replace it with Kerberos or even a simple password hash scheme.  For our
> users needs this would be perfectly suitable (and transparent), except
> politically it would raise hell.
>
> I know a lot of work has gone into building the bridge between Kerberos
> and GSI, but in this case it's more a matter of utilizing a secure
> authentication mechanism that's easiest to manage centrally (to the
> users and developers it's all abstracted behind RESTful web services).
> Any thoughts or advice would be appreciated, technical papers or
> security reports comparing the two systems would be great as well.
>

Here are some personal as well as technical comments. But I wil try and
stay away from an thing political.

I wrote the original GSSAPI part of GSI version 1.0.x, but have not been
active in the Globus project for a number of years and have not kept up
with what was going on in versions 3 and above. I am still very active in
the Kerberos community.

There have been (and maybe) some sites using the Kerberos GSSAPI with
Globus. But this was early on, and I have not talked to them on
what they are doing today.

A main differences between GSI and Kerberos is that the credentials
are symmetric in GSI (both sides use X509 certificates and keys
and the GSI in effect uses the SSL/TLS protocols), but in Kerberos they
are usually asymmetric, (the client uses a ticket, the server a keytab.)
Globus does a lot of user-to-user authentication, where user processes are
started on a machine, and act as servers to other processes on
other machines usually started by the same user. They authenticate between
each other, using "user-to-user". Kerberos has this concept as well, where a
server can be using a ticket. But the Kerberos GSSAPI does not support this.
There was a IETF draft from 2001:
    "draft-swift-win2k-krb-user2user-03.txt"
based on Microsoft's implementation that is used with SSPI. There
are also mods available for MIT krb5-1.3.x to add this support.

Another difference is the GGF defined some extensions to gssapi
that addressed some needs of Globus from a GSSAPI.  For example, Storing
of the delegated credentials, delegation at any time, access to additional
information in the credentials and setting of additional options. Early
versions of Globus where careful to test if these where available in the
gssapi mech being used. I am not sure about testing with current versions.
The  IETF Kitten group is aware of this document which was published as an
IETF informational draft:
   "draft-engert-ggf-gss-extensions-01.txt"
A more up to date version can be found at:
  http://www-fp.globus.org/security/standards/draft-ggf-gss-extensions-09.doc
The user-2-user mods for krb5-1.3.x also had a few of these extensions as
well.

There is also a mech_glue to allow a server like sshd to use either the
Kerberos or GSI gssapi. But note that sshd does not need any of the gss
extensions :
  http://grid.ncsa.uiuc.edu/gssapi-mechglue/

If you to contact me, I can try and put you in touch with some of the
sites that are/have used Kerberos with Globus. You may also want to ask
your questions on the <[hidden email]> mail list.


--

  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
Reply | Threaded
Open this post in threaded view
|

Re: Globus/GSI versus Kerberos

Anne & Lynn Wheeler
In reply to this post by Tim Warnock-2
Ken Hornstein wrote:
> When I cornered one of the Globus guys and asked him point-blank the
> same question, he told me that in his opinion the decision to do PKI
> was really driven politically from the top, and he thought Kerberos
> made a LOT more sense.

the original pk-init draft for kerberos specified certificateless
operation
http://www.garlic.com/~lynn/subpubkey.html#certless

you basically registered a public key with kerberos in lieu of a
password and then used digital signature authentication with the onfile
public key (no PKI and/or digital certificates required).
http://www.garlic.com/~lynn/subpubkey.html#kerberos

this was basically an authentication technology upgrade w/o having to
introduce any new business processes and extraneous infrastructure
operations.

it was later that certificate-based operation was added to the kerberos
pk-init draft.

i gave a talk on this at the global grid forum #11
http://www.garlic.com/~lynn/index.html#presentation

at the meeting there was some debate on kerberos vis-a-vis radius as
an authentication &amp; authorization business process infrastructure.

note that in addition to their having been a non-PKI,
<b>certificate-less</b>
authentication upgrade for kerberos (using onfile public keys), there
has been a similar proposal for RADIUS; basically registering public
keys in lieu of passwords and performing digital signature
authentication with the onfile public keys.
http://www.garlic.com/~lynn/subpubkey.html#radius

Straight forward upgrade of the authentication technology w/o having
to layer on a separate cumbersome PKI business process.

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