Corrections re: Kerberos misconceptions (none / 0) (#29)
by johan on Fri Jun 23, 2000 at 04:32:34 AM EST
First, let me answer your question.
If you're looking for a secure communications protocol that you
can (attempt to) coerce vendors into using, i'd said go with something
like HTTPS, SSH, SSL or SRP.
There are some weaknesses inherent in the SSH v1 protocol, which must be
considered by a careful developer who plans to use the protocol. In
particular SSH v1 is more vulnerable to man-in-the-middle attacks than SSH
v2 or Kerberos v5.
I don't recommend Kerberos for your goal because a Kerberized-service
(E.g. telnetd running on your network device) must have access to it's own
service key in order to function. (A service key is more-or-less the
server's secret.) To be truly secure, this service key should be
transferred in a secure manner from the KDC to the application server. How
would one do this? Typically, one first sets up the machine hosting the
Kerberized application server as a Kerberos client, so that it can use a
Kerberized ftp or rcp, and then pull the service-key file over using
a secure (encrypted) session. (It could also be done using a floppy and
This requires more work than SSH, HTTPS or SRP, and means
you aren't going to be able to just turn on a piece of network hardware
and have it start working. (Though a piece of network hardware would need
to be able to generate a SSH host key, which might be troublesome if the
remote machine does not support the same (patented) encryption scheme used
for the host key.)
That said, let me make a few comments to correct some common misconceptions
about Kerberos. I have setup and run a number of Kerberos systems over the
past few years, and am often quite surprised at the mistaken assertions
people make regarding Kerberos.
Kerberos is an authentication protocol (system) requiring (at minimum) three
different types of members (though all three of these could be running on
- The Client
Typically a human sitting in front of a PC or
workstation who wants to be able to do something like securely connect
from their machine to a service on a remote machine. For example, me
sitting in front of a Mac, wanting to securely telnet to a Sun running a
"Kerberized" telnet daemon.
- The Application Server
In the above example, it's the
"Kerberized" telnetd running on a UNIX machine. It could also be a
Kerberized ftpd, Oracle SQL server, rlogind, etc. The key is that it's
a service made available to a (relatively) public network that
understands the Kerberos authentication protocol.
- The KDC or "Key Distribution Server"
This is the server that
hands out keys (AKA "credentials" or "tickets"). There can be more than
one "readable" server, but so far, only one "writable" server. If you
understand how DNS servers work, it's very similar. There's a
"primary" (AKA "master") for a particular "realm" (very similar to a DNS
domain) which can replicate read-only copies of the principal database
to multiple secondary (AKA "slave") servers. Users (AKA "principals")
and their secrets ("password") can be changed (or added) on the master
but no changes can be made on a slave. As with DNS, servers are
typically queried (credentials requested) via UDP packets. If server #1
does not respond before the timeout, a packet is sent to server #2 or
#3. The order is determined by the client's configuration file.
Kerberos has a number of strengths:
- Secrets (passwords) are never sent over the network in the clear.
- Secrets can be long (typically up to 255 chars.)
- Protocol protection against reply attacks.
- After the initial authentication, a user should not need to
re-enter their secret for some realm-wide time limit. (Typically 8-12
hours.) In other words, you authenticate just once once, and then you can
telnet, ftp, pop, rsh, rlogin, isql (or whatever) to as many machines in
your realm as you want, as long as they can accept your Kerberos
- The KDC provides a shared unique session key that the client and
application server (like telnet-telnetd or ftp-ftpd) can then use to
encrypt their communications. The encryption is typically strong: 3DES.
- What's stored on disk for the user is a "TGT"
(ticket-granting-ticket) that expires after some preset time. (typically
8-12 hours) So even if the account is compromised, the TGT can only be
used for a limited time.
- Free and open-sourced, unless you are using a vendor's binary
distribution. (Microsoft, Sun, CyberSafe, etc.)
- Inter-operable across multiple architectures (PC, Mac, UNIX) unless
you are using Microsoft's KDCs (servers), which are not 100% compatible
with other servers. Apple has stated they will support an MIT-compatible
Kerberos in MacOS X.
- Free telnet clients for Windoze, Macintosh or UNIX. (There is not
a free SSH telent for Macs in the U.S. because of RSA patent issues.)
- Non-trivial to setup. As with DNS, there must be a server that
stores and serves data to "the public." However, SSH requires host key
management, which is also a non-trivial (but smaller) amount of work.
- All the secrets are encrypted and stored in the DB on the KDCs. So
if a KDC is compromised, the data in the DB can (with a significant
amount of work) be decrypted and every principal's secret known. Note
that it's not necessary to store the master key (which is used to
encrypt all the secrets in the DB) in a stash file on a KDC. If a stash
file is not used, the realm is less vulnerable, but it means the daemons
that serve tickets and handle admin requests cannot startup without
- No (V5) Kerberized FTP for Macintosh. (There is a V4 Kerberized version of
- Until recently, Kerberos-development and support in other apps was
greatly hampered by U.S. export regulations. (Unlike SSH, which was
developed in Finland.)
- Several serious bugs were just patched in the latest MIT
distributions. They're might be more. Then again, maybe the increased
attention to the source means that the serious bugs have now been
- SSH v2 is somewhat commercial.
Misconceptions i have heard or seen at various times (not necessarily
- Kerberos transmits passwords over the network in the clear.
This is completely false. As a protocol, Kerberos never does this.
When a user first authenticates, the client-side program (on a UNIX
machine, it's called "kinit") sends a request to the KDC for a TGT for
the user. The KDC generates the TGT from a bunch of stuff (current
UNIX time, requesting host IP address, plus more) and encrypts it with
the user's secret, and then sends the encrypted TGT to the requesting
program (kinit). If the user does not know the password, they cannot
decrypt the TGT.
- Kerberos is vulnerable to dictionary attacks
This is true of V4 Kerberos, but not necessarily true for V5. V5
supports the option of "Pre-Authentication" which essentially
requires the client to demonstrate that it knows the secret before the
KDC will respond to the request for the TGT.
- Kerberos has a single-point of failure.
This is mostly-false. Just like DNS, the system is designed to be
setup with multiple servers (KDCs), any of which can answer any and all
requests for authentication. Changes to the principal DB must be made
to the sole primary server, so this is a single point of failure, just
like with DNS. Worst case, this would typically mean that some users with expired passwords
would be unable to authenticate (and login) until the primary KDC
was repaired, or a secondary was reconfigured to take its role. (Not
difficult, if you've planned ahead) I believe there are plans to
eliminate this weakness.