Kerberos

1
Kerberos

• Mark Sidnam

2
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

3
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

4
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)

5
how does it do it?

• the ticket system
• user requests an initial ticket from KDC
• used as basis for all remote access requests

6
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

7
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

8
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

9
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

10
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 cross-realm authentication paths.
• transitive cross realm authentication
• you can define a path of realms connected via
  cross-realm secrets and use this path to "hop"
  between realms until you get credentials in the
  desired realm

11
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

12
more then just one type of ticket

• Initial Tickets
• tickets received from the AS proving a password
  has been entered to gain access to it
• Pre-Authenticated Tickets
• proves the occurrence of some form of
  authentication prior to step 1 in the ticket
  steps
• Invalid Tickets
• 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)

13
more tickets

• Renewable 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
• Proxy Tickets
• 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

14
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)

15
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-to-user
  protocol

16
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

17
.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

18
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

19
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.ht
  ml
• http//www.cmf.nrl.navy.mil/CCS/people/kenh/kerber
  os-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/plan
  ning/security/kerbsteps.asp
• http//web.mit.edu/kerberos/www/