Kerberos Authentication Protocol

1
Kerberos Authentication Protocol

• An Overview of the Kerberos Authentication
  Protocol
• by Pam Todaro (SANS)

2

• Authentication is fundamental in securing a
  network environment.
• Both client and server provide identity to each
  other.
• Definitions
• User an individual who uses a program or
  service.
• Client a person or program requesting
  remote services. Often a client contacts
  server on behalf of user.

3

• Once all network clients are using Kerberos, the
  authentication protocol should be switched from
  Windows NT LAN Manager to Kerberos.
• Benefits of Kerberos
• 1. Faster connections client is responsible
  for storing credentials for each server it needs
  to access. Reusing locally stored credentials
  speeds up the logon.

4

• Mutual authentication both ends of a
  communication must be verified.
• 3. Simplified trust management domains in a
  large network can be organized so that
  credentials issued by the security authority for
  any domain are accepted everywhere in a tree of
  mutual trust.

5

• Potential problems with network communications
• 1. Clients cannot be certain their initial
• transactions will not be monitored or
• modified by an unauthorized person.
• 2. An attacker can pose as a legitimate server
• or can tamper with communications
• between an authorized client and a
  legitimate server.

6

• For these reasons, Kerberos authentication
  protocol always assumes an unsecure network and
  provides for mutual authentication between
  partners before a network connection is even
  opened.

7

• Kerberos uses a cryptographic key that is shared
  by the partners and used to verify one anothers
  identity.
• Shared key is symmetric and used for both
  encryption and decryption.
• Each party establishes proof of knowledge of this
  key by either decrypting or encrypting a piece of
  information.

8

• Kerberos protocol consists of a client, server,
  and trusted third party.
• The Key Distribution Center is the trusted
  intermediary and implemented as a domain service.
• Key Distribution Center runs on every domain
  controller and uses Active Directory as its
  account database.

9

• Allowing each domain to have several domain
  controllers to accept requests to Key
  Distribution Center insures availability of the
  services.

10

• More on the Key Distribution Center
• Service functions
• 1. Authentication Service at login time, name
  and password are presented to the Authentication
  Service portion of the Key Distribution Center.
  Also responsible for issuing Ticket Granting
  Tickets for admission to Ticket-Granting Service.

11

• 2. Ticket-Granting Service client
• must present a request for a session
• ticket and a Ticket Granting Ticket.

12

• Long-Term Key
• Key Distribution Center (KDC) has information
  on each user, computer, or service (security
  principal). KDC also has access to a
  cryptographic key known only to the KDC and the
  security principal. This key called long-term
  keyused in exchanges between the KDC and the
  security principal.

13

• Clients copy of long-term key is usually created
  when a user logs onto the network and the
  Kerberos client, on the workstation, converts the
  users password to an encryption key by entering
  the password into a hashing function. Kerberos
  client saves the long-term key in its credentials
  cash (in volatile memory).

14

• Once the client has a long-term key, it sends a
  message to the KDCs Authentication Service
• Message has two parts
• 1. Identifies user and requests access
  to Ticket-Granting Service.
• 2. Timestamp encrypted with the users
  copy of the long-term key.

15

• KDC obtains its copy of the long-term key from
  the domains Active Directory.
• KDC uses its copy of the long-term key to decrypt
  the message and validate the timestamp.
• Timestamp check must be processed within a
  certain time frame or login is rejected.
• Login will also be rejected if time in the
  timestamp is earlier than a time already
  requested by same login id.

16

• Note It is critical that times are synchronized
  across the network.
• Requesting a Ticket Granting Ticket
• When KDCs Authentication Service receives a
  request for a Ticket Granting Ticket, it checks
  Active Directory in users account domain.
• After verifying the client, replies to client in
  two ways

17

• KDC develops a logon session key and encrypts a
  copy of it using the clients long-term key.
• KDC creates a Ticket Granting Ticket with another
  copy of the logon session key.
• The completed ticket is encrypted with the KDCs
  long-term key.

18

• When client receives the ticket, it uses its
  cached copy of the users long-term key to
  decrypt its copy of the logon session key.
• Logon session key is temporary and valid only
  until the Ticket Granting Ticket expires or the
  user logs off.
• Once client has the logon session key, it can
  discard the long-term key because it will use the
  logon session key for any future communications.

19

• About Session Tickets and Keys
• When a client needs access to a service, it first
  checks its credentials cache for a session ticket
  to that service.
• If no ticket is found, it checks the cache again
  for a Ticket Granting Ticket. If client has a
  Ticket Granting Ticket in its credentials cache,
  it retrieves corresponding logon session key from
  cache.

20

• Client uses the logon session key to prepare an
  authenticator.
• The authenticator and the Ticket Granting Ticket
  are sent to the KDC with a request for a session
  ticket to the service.
• If the Ticket-Granting Service approves the
  clients request, it generates a temporary
  private key called a session key for both
  client and server.

21

• Ticket-Granting Service also creates a session
  ticket containing the servers copy of the
  session key. KDC uses the key it shares with the
  server to encrypt the session ticket. It then
  sends a reply back to the client that includes
  the session ticket and the clients copy of the
  session key.

22

• Client extracts the session ticket and the
  clients copy of the session key and stores both
  in its credentials cache.
• IT IS THE RESPONSIBILITY OF THE CLIENT TO PRESENT
  THE SESSION TICKET TO THE SERVER EACH TIME IT
  WANTS ACCESS TO THE SERVER.

23

• Session ticket can be used any number of times
  when accessing same server.
• When requesting admission to a server, client
  must send server a message with both session
  ticket and authenticator. Server decrypts
  session ticket with its secret key and extracts
  session key.
• Uses session key to decrypt clients
  authenticator.
• If server is able to decrypt clients
  authenticator, it knows the KDC issued the
  clients credentials.

24

• Client can request server authenticate itself to
  the client. Server uses its copy of the session
  key to encrypt the timestamp from the clients
  authenticator and returns the result to the
  client as its authenticator.
• Client decrypts servers authenticator and
  compares the timestamp with that of its original
  authenticator. If timestamp checks out, client
  knows server is legitimate.
• Now both server and client have been
  authenticated to each other.

25

• When the user logs off, the credentials cache is
  flushed and all session tickets and all keys are
  destroyed.

26

• Defending Against Attacks
• An administrator can
• 1. Have tickets renewed at relatively short
  
• intervals. Renewing a ticket causes a
  new
• session key to be issued.
• 2. Kerberos policy can be set to allow
• renewable tickets. Session keys, in a
  renewable
• ticket, can be refreshed periodically
  without issuing a
• completely new ticket.