[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MIT versus Heimdal Kerberos 5

on Mon, Jan 13, 2003 at 07:54:10PM +0100, Frank Lenaerts wrote about Re: MIT versus Heimdal Kerberos 5:

Some things I forgot.

> > My understanding is that you don't, really, and that the Kerberos code
> > that appears in X might have maybe done authentication but not

I suppose you mean that xdm supports authName MIT-KERBEROS-5 (which
would be passed to xauth).

> > encryption when built against a really ancient pre-release of MIT
> > krb5.  Around here, everyone uses ssh's X forwarding (with Kerberos
> This means that you actually have to login to your local machine
> first and then ssh to the application server where you can start your
> X clients. 
> This means that you do not have central user management anymore
> (unless there is a kerberised login program, which does not seem to be
> the case (Woody), to authenticate and then start the X server
> manually, which does not encrypt the X traffic (like you mentioned
> above).
> This also means that it would be more difficult for an end user to get
> a full screen remote X session (window manager, etc. all running on
> the application server), in the case where the X terminal is really an
> X terminal (i.e. only runs the OS and an X server, possibly even
> diskless [ignore NFS security problems for a while]).
> It seems that I only have 2 options to choose from:
> (1) Use Heimdal Kerberos 5 with kx and kxd
>     + : in Woody and probably fairly easy to setup
>     - : uncertain about stability, compatibility, ...

      + : X traffic encrypted

> (2) Setup X terminals to authenticate via SSL/TLS to an LDAP server,
>     which in turn gets the passwd information from a Kerberos server.
>     + : more generic i.e. also non-{x,g,k}dm logins can authenticate
>         like this
>     - : libldap2-tls is not part of Woody, but is already in testing
>         so should be ok (didn't check dependencies on other testing
>         stuff yet)
>     - : long chain with conversions: PAM/LDAP, SSL/TLS, SASL

      - : X traffic _not_ encrypted (only authentication towards the
          LDAP server, ...)

As a sidenote, I was just thinking that it might be easier to separate
the encryption part from the authentication part i.e.:

- setup an encrypted tunnel from the client to the application server
  (point-to-point) e.g. CIPE, IPSec to carry all application specific

- use Kerberos only to authenticate centrally


Those who do not understand Unix are condemned to reinvent it, poorly."
-- Henry Spencer

Attachment: pgpanbviOb_Z8.pgp
Description: PGP signature

Reply to: