On Thu, Jun 24, 1999 at 02:17:10PM +0100, Matt Kern wrote:
> > Kerberos tickets expire after a time limit, and while anyone who uses it
> > within that time limit could still do as much damage (eg rm -rf $HOME),
> > I think it is less risky.
>
> Unless the system you are sat at is insecure, having the ticket fall into
> someone elses hands does not pose a security problem since they will be
> unable to extract the session key. Kerberos V is even more secure;
> servers have replay-caches to stop authenticators being replayed.
>
> I advise anyone interested in Kerberos to read:
>
> http://web.mit.edu/Kerberos/www/dialogue.html
Thanks - I think I understand now. I thought the users password was
somehow sent to the KDC server, but I guess I was... WRONG!
It is really interesting the techniques that are use to get this level
of security from a private key system.
I have a couple of questions though, which that web page doesn't answer:
- where is the session key stored on the clients? Is it stored in with
the same file with the ticket? I am guessing it would be a really
bad idea to store this file on an NFS partition (eg on diskless boot
systems). Is there any alternative to using a file? ie could I somehow
replace the ticket file with a named pipe that stores the result in
memory, so that it isn't NFS accessible?
- do inaccurate clocks on computers introduce any security risks? eg,
assume the clock on the clients computer is 24 hours ahead of the other
computers, and the client sends a {ticket,authenicator} request to the
server. I assume the server would instantly discard such a request,
because the time is invalid. What would happen though, if an intruder
realized the clock on the client computer was exactly 24 hours out, and
'replayed' the key when it become valid?
I am guessing that it is really critical the time on all computers is
really accurate, not only for useability of the protocol, but security
as well.
- what is the difference between kinit and kauth???? Why is kauth and
kauthd required???
- kerberos seems to check network addresses a lot - does this actually
help security?
- how does cross realm security work? I am guessing that the local
kerberos server acts as a `proxy server' for ticket request, ie it sends
requests as though it wants the ticket, and re-encrypts ticket so that
the actual user can see it (if that makes sense to you).
> This is a well written page that manages to get across the mechanics
> without giving the reader suicidal urges.
Too late... Arrrgghhh!!!! ;-)
> > Sure, there are problems with Kerberos, like what if the security of the
> > kerberos server gets comprimised, but IMHO this is a non-issue. If the
> > server at one organisation gets comprimised, the worst it could mean is
> > that all my accounts at that site get comprimised (at least that is my
> > opinion). NFS already makes the same thing possible without resorting to
> > breaking into kerberos servers ;-)
>
> The KDCs are usually ultra-secure machines which provide few if any other
> services. Having any individual server compromised can only then
I currently have a KDC server on my home computer - if anyone were to
break into that, there would be no point in worrying about kerberos, as
you would already have access to everything anyway ;-).
Then again - whats the point? Well, I am still to answer that question!
> give-away the ticket-granting tickets stored on the machine; revoking
> them promptly is a good effort towards damage limitation.
> > If I were to change to using Kerberos, I would most likely use the
> > following applications: postgresql, cvs, xdm, openldap, pop with
> > Maildir support(???? does something like this exist???). I have yet
> > to check what Mail clients I use actually have kpop support. :-). If
> > xdm cannot be ported, what about wdm and/or kdm???
>
> There was quite a bit of talk about kerberised clients on this list a
> while back. The concensus was that a PAM module would prolly be a good
> way to go. Guess what I am working on.
How does the PAM module work? Does it support kerberos tickets, or
does it rely on password authentication?
I have read in "http://www.ornl.gov/~jar/HowToKerb.html"; that ssh1
supports kerberos tickets... Interesting. I wonder if ssh2 does...
Not that I am really sure why you would want to use ssh with kerberos.
BTW - I have read a number of articles that say that kerberos doesn't
support secure X sessions, however my version of kerberos 4, has
programs kx, kxd, ktenletxr, krxterm, and krxtelnet. kx is a little
bit broken is some respects (I think it gets confused with parsing
the DISPLAY environment variable if it contains a hostname). Do these
programs still exist in V5 of kerberos?
On the topic of applications - it looks like one of kerberos goals as
that you should only have to enter your password once. Now, maybe I am
dreaming, but it would be nice if you could somehow integrate PGP/GPG
into all of this... ie so you don't have to enter your PGP/GPG message
to sign/decrypt messages, but rather use your kerberos ticket... I have
an idea how this could be implemented, however, I would be curious as to
what others think first...
What time frame are you looking at having the kerberos debian package
ready? Not that I want to rush you, however I am wondering if I should
try to hack out my own temp installation, or if I should wait for you...
> > My main concern for kerberos, at least with version 4, is that
> > when running kinit or kauth to "login" there doesn't seem to be anyway
> > of verifying that the kerberos server is the real server. Does
> > version 5 do anything to help this?
>
> Both Kerberos IV and V have mutual authentication. I really recommend
> you read the url above; it is quite comprehensive :)
Thanks. It is a bit strange - Kerberos designed in several days??? I wish
all development was that fast ;-) - but it is good at illustrating the
main points.
BTW: The main problems I see with kerberos at the moment, as that
a) it requires the cooperation of the system administrators at an
organisation, and they may be reluctant to install it as it replaces
telnetd and ftpd (this is both good and bad), not to mention the secure
KDC server (as cheap as this might be). The administrators might just
say, use ssh.
b) It is not really highly suitable for communication between a number
of different organisations at once, unless you can convince the system
admistrators to setup cross-realm authentication. Not that it can't be
done, it just doesn't seem very convenient.
--
Brian May <bam@snoopy.apana.org.au>
Attachment:
pgpCpAa1QKvnV.pgp
Description: PGP signature