Kerberos
Mark Sidnam
What does it do?





Kerberos is a network authentication protocol. It
is designed to provide strong authentication for
client/server applications by using secret-key
cryptography.
Kerberos acts as an extra layer of security for
any application which utilizes Kerberos
Contains its own database of users and
passwords
Transparently authenticates its users to save
time from redundant password entries
Limits accessibility to ‘kerberised’ programs
what can it do?

Kerberos is mostly used in application-level protocols such as
TELNET or FTP, to provide user to host security. It is also used,
though less frequently, as the implicit authentication system of
data stream (such as SOCK_STREAM) or RPC mechanisms. It
could also be used at a lower level for host to host security, in
protocols like IP, UDP, or TCP (ISO model levels 3 and 4),
although such implementations are currently rare, if they exist
at all.

contains utility to recompile programs to run utilizing the
kerberos authentication scheme effectively kerberizing them.

comes with programs with already built in kerberization

ksu, ksh, telnet, etc…
Why does it do it?

Typically a firewall is put in place to prevent malicious
actions wrought against a network, this though,
disregards the threats from within a network

Protects programs that send unencrypted passwords
over a network

Reduces the risk from servers that expect clients to be
‘honest’ about their identity

proves the identity of both the client and the server

prevents replay attacks by utilizing clock
synchronization(not foolproof)
how does it do it?

the ticket system


user requests an initial ticket from KDC
used as basis for all remote access requests
the ticket system

A ticket is a sequence of a few hundred bytes. These
tickets can then be embedded in virtually any other
network protocol, thereby allowing the processes
implementing that protocol to be sure about the identity of
the principals involved.

has a Key Distribution Center (KDC), containing a
database of:



principles (customers and services)
encryption keys
based off the key distribution method by Needham and
Schroeder
steps in the ticket system

1.user sends request to the authentication server to use a
particular program

2. the server generates a session key and proceeds to send to
the user two encrypted replies


the first is encrypted with the users key and contains the
session key

the second(ticket) is encrypted with the service's key and
contains the same session key and the users information
3. the user extracts the session key from the first reply and
sends two messages to the service

the ticket obtained from the server(which the user is unable
to unencrypt)

and the authenticator encrypted with the session key and
containing a time-stamp
the TGT

if that sounded in any way insecure there is an extra step
of security involved which Needham and Schroeder called
the KDC

in the first step rather then obtaining the ticket from the
authentication server, the user obtains a ticket granting
ticket(TGT)

the ticket granting server and authentication server are
collectively referred to as the KDC

steps involved:

user rather then using his secret key to decrypt the first
reply from the AS for each ticket, he/she does so once
for the TGT. After this, whenever a user wishes to use a
service, he/she requests a new ticket with the TGT now
encrypted with the session key
The importance of time
synchronization

To prevent replay attacks, Kerberos utilizes timestamp
policies

all machines desiring to be a part of the kerberos network
must be synced by within five minutes of each other

any time stamp differing from the clock on the
computer by more then 5 minutes causes the service to
disregard the ticket as false

in step 3 of the ticket process a time stamp was created,
this was to block others from using this ticket at another
time

the TGT only lasts for a time set in one of the kerberos
config files
Extra things to do

Cross realm authentication

a principal belonging to one realm(can be referred to as the
domain name) may be authenticated within a different
realm,

kerberos can do this one of two well known ways
 cross realm secret key
 thus in N realms, 2 * ((N - 1) ** 2) secrets will need to
be exchanged in order to cover all possible crossrealm authentication paths.
 transitive cross realm authentication
 you can define a path of realms connected via crossrealm secrets and use this path to "hop" between
realms until you get credentials in the desired realm
more extra things

it is possible to completely kerberize your entire system

adding kinit(command to gain a TGT) to all users login
procedures and kdestroy(command to destroy all cached
tickets) to all logout procedures assures that all users will
have a TGT for the duration of login(assuming that this
login period does not extend beyond the TGT lifetime)

logins can be kerberized as well

rather then the usual login command a kerberos login
can be replaced and as the user logs in he does so
using his kerberos password and gains his TGT for any
services he wishes to use on his machine
more then just one type of ticket

Initial Tickets


Pre-Authenticated Tickets


proves the occurrence of some form of authentication prior
to step 1 in the ticket steps
Invalid Tickets


tickets received from the AS proving a password has been
entered to gain access to it
a ticket with a use date not yet reached. useful for batch
jobs that the administrator wishes to occur without his
presence
(Potentially) Postdated Tickets

allows for requests for postdated tickets(only tickets, no
postdated TGT may be issued this way)
more tickets

Renewable Tickets


Proxy Tickets


rather then have long ticket lifespans(allows higher
opportunity to attacks) or the constant requests for more
TGTs(which also create more opportunity due to constant
password entry) RT request a new TGT depending on an
extra field that tells how much longer the ticket can be
renewed for
when you trust a privileged service to act on your behalf the
service requests a proxy ticket(TGT) which allows the
service to act on another service in the name of the user
Forwarded Tickets

Forwarded tickets are just like proxy tickets, except that they
can authorize issuance of TGTs
Security issues and info


Kerberos assumes trusted hosts and an untrusted network

a compromised host is compromised as far as kerberos is

if an attacker obtains the tickets in transit, he now has to
contend with many other hurtles, one of which is the replay
cache which keeps track of the authenticators used and
blocks its reuse.

so if the KDC is compromised, then the whole of the realm
is compromised
the 'key salt'

when you enter your pass in for the TGT rather then enter
the 56-bit DES key, a program called string2key() hashes
your pass with your principal name to create unique keys for
the same password(improvement over ver4)
more security info

the ip address of the machine granted the ticket is contained
within the ticket adding protection from stolen tickets

user to user authentication

for users hosting services on their workstations such as nfs
and ftp

in the user-to-user protocol, one user acts as a server, and
the other user acts as a client. at the client-user's request,
the server-user sends his TGT (but not his session key) to
the client-user, who then gets credentials from the KDC,
encrypted with the session keys of both TGTs. Both users
can decrypt the new session-key and use it to verify each
other's identity

Kerberos 5 does not offer an API that hides the difference
between desktop servers and physically-secure servers. For
this reason, very few services currently support the user-touser protocol
guess what, more security info

Kerberos vs SSL


If a Verisign certificate issued to a user is compromised
and must be revoked all servers who that user interacts
with must now either have that revocation certificate
cached to compare to, or compare to a third party
'revocation server'
the certificate sits on the hard disk allowing for ample
opportunity for cracking as opposed to the password
system in Kerberos

Kerberos is free

open source, open standards allows room for growth
and evolution
.conf files


krb5.conf

designates realm name and
mapping information if it
differs from your domain
name

logging information

basic ticket information
kdc.conf

very similar in nature to
krb.conf file

contains base realm
information

list of all key/salt
combinations
other information

windows has (in many opinions faulted) implementation of
kerberos on server2000 that can work with GNU/linux clients

an MIT creation(isn't everything...?)

uses Data Encryption Standard(DES)

.conf file stuff

kdc.conf can contain an option to block certain passwords
from a particular dict_file from being used

can block/allow hosts in the hosts config file for added
protection

the kerberos database stores keys, not passwords

most services only check for ticket status upon initializing, not
afterwards. AFS(similar to NFS) on the other hand will block all
access to files when the ticket runs out
sources

http://www.faqs.org/faqs/kerberos-faq/user/

http://cryptnet.net/fdp/admin/kerby-infra/en/kerby-infra.html

http://www.isi.edu/gost/brian/security/kerberos.html

http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html

http://docs.hp.com/en/T1417-90001/ch05s04.html

http://www.itl.nist.gov/fipspubs/fip46-2.htm

http://web.mit.edu/kerberos/www/dialogue.html

http://www.microsoft.com/windows2000/techinfo/planning/security/k
erbsteps.asp

http://web.mit.edu/kerberos/www/