Kerberos is a network authentication protocol that provides secure authentication for client/server applications. It uses secret-key cryptography and relies on a trusted third party called the Key Distribution Center (KDC) which is aware of all systems on the network. Kerberos introduces tickets that allow a client access to a server after initial authentication with the KDC. The authentication process involves the client receiving a ticket-granting ticket from the KDC and then exchanging messages with the ticket-granting service and target server to gain access.

1. Name :- Mayuri K. Patil
Subject :- CSSL
Class :- BE-CSE-II (‘B’ Batch) Roll no. :- 406223
Kerberos: An Authentication Service for Open Network Systems
8.1 Introduction to Kerberos Authentication
Kerberos is a network authentication protocol. It is designed to provide strong
authentication for client/server applications by using secret-key cryptography. It has the
following characteristics:
• It is secure: it never sends a password unless it is encrypted.
• Only a single login is required per session. Credentials defined at login are then passed
between resources without the need for additional logins.
• The concept depends on a trusted third party – a Key Distribution Center (KDC). The KDC is
aware of all systems in the network and is trusted by all of them.
• It performs mutual authentication, where a client proves its identity to a server and a server
proves its identity to the client.
Kerberos introduces the concept of a Ticket-Granting Server (TGS). A client that wishes
to use a service has to receive a ticket – a time-limited cryptographic message – giving it access
to the server. Kerberos also requires an Authentication Server (AS) to verify clients. The two
servers combined make up a KDC. Active Directory performs the functions of the KDC. The
following figure shows the sequence of events required for a client to gain access to a service
using Kerberos authentication. Each step is shown with the Kerberos message associated with it,
as defined in RFC 4120 “The Kerberos Network Authorization Service (V5)”.
Technologies Related to Kerberos Authentication
The following diagram shows how Kerberos authentication fits with other technologies in
Windows Server 2003. Depending on whether the client or server applications are user-mode or
kernel-mode applications, they use either Secur32.dll or Ksecdd.sys, respectively, by means of
SSPI calls to communicate with the Local Security Authority Subsystem (LSASS).
Kerberos Architecture

2. How it Works ?
• Step 1: The user logs on to the workstation and requests service on the host. The workstation
sends a message to the Authorization Server requesting a ticket granting ticket (TGT).
• Step 2: The Authorization Server verifies the user’s access rights in the user database and
creates a TGT and session key. The Authorization Sever encrypts the results using a key derived
from the user’s password and sends a message back to the user workstation.
The workstation prompts the user for a password and uses the password to decrypt the
incoming message. When decryption succeeds, the user will be able to use the TGT to request a
service ticket.
• Step 3: When the user wants access to a service, the workstation client application sends a
request to the Ticket Granting Service containing the client name, realm name and a timestamp.
The user proves his identity by sending an authenticator encrypted with the session key received
in Step 2.
• Step 4: The TGS decrypts the ticket and authenticator, verifies the request, and creates a ticket
for the requested server. The ticket contains the client name and optionally the client IP address.
It also contains the realm name and ticket lifespan. The TGS returns the ticket to the user

3. workstation. The returned message contains two copies of a server session key – one encrypted
with the client password, and one encrypted by the service password.
• Step 5: The client application now sends a service request to the server containing the ticket
received in Step 4 and an authenticator. The service authenticates the request by decrypting the
session key. The server verifies that the ticket and authenticator match, and then grants access to
the service. This step as described does not include the authorization performed by the Intel
AMT device, as described later.
• Step 6: If mutual authentication is required, then the server will reply with a server
authentication message.
The Kerberos server knows "secrets" (encrypted passwords) for all clients and servers
under its control, or it is in contact with other secure servers that have this information. These
"secrets" are used to encrypt all of the messages shown in the figure above.
To prevent "replay attacks," Kerberos uses timestamps as part of its protocol definition.
For timestamps to work properly, the clocks of the client and the server need to be in synch as
much as possible. In other words, both computers need to be set to the same time and date. Since
the clocks of two computers are often out of synch, administrators can establish a policy to
establish the maximum acceptable difference to Kerberos between a client's clock and server's
clock. If the difference between a client's clock and the server's clock is less than the maximum
time difference specified in this policy, any timestamp used in a session between the two
computers will be considered authentic. The maximum difference is usually set to five minutes.
Note that if a client application wishes to use a service that is "Kerberized" (the service is
configured to perform Kerberos authentication), the client must also be Kerberized so that it
expects to support the necessary message responses.
8.2 Kerberos component in Windows 2000
Windows 2000 uses the domain’s Active Directory to implement in the KDC the action
of getting some information about users from the Global Catalogue. The KDC is located on
every domain controller, as is the Active Directory service. Both services are started
automatically by the Local Security Authority (LSA) of the domain controller and they run in the
process space of the LSA. It’s supposed that neither service can be stopped.
Windows 2000 ensures availability of these services by allowing each domain to have
several domain controllers, all peers. Any domain controller can accept authentication requests
and ticket-granting requests addressed to the domain's KDC.
8.3 Kerberos Policy

4. In Windows 2000, Kerberos policy is defined at the domain level and implemented by the
domain's KDC. Kerberos policy is stored in Active Directory as a subset of the attributes of
domain security policy. By default, policy options can be set only by members of the Domain
Administrators group.
Kerberos policy includes these settings:
• Maximum user ticket lifetime (default is ten hours).
• Maximum lifetime that a user ticket can be renewed (default is seven days).
• Maximum service ticket lifetime (default is ten hours).
• Maximum tolerance for synchronization of computer clocks (default is five minutes).
• Enforce user logon restrictions (default is enabled).
A dynamic-link library (SSP = security support provider) supplied with Windows 2000
implements the Kerberos authentication protocol. SSP, by default, is loaded by the LSA in the
system booting phase and it may be used either to authenticate network logons and client/server
connections. The choice depends on the capabilities of the computer on the other side of the
connection.
System services and transport-level applications access SSPs through the Microsoft
Security Support Provider Interface (SSPI). This interface is used to enumerate the providers
available on a system and selected one it tries to obtain an authenticated connection with it.
If the Kerberos SSP has been selected, this method generates a KRB_AP_REQ message
from the client. The application on the server's side of the connection responds with the SSPI
method AcceptSecurityContext, which generates a KRB_AP_REP message from the server.
Once the connection has been authenticated, the LSA on the server uses information from the
client's ticket to build an access token. The server then invokes the SSPI method
ImpersonateSecurityContext to attach the access token to an impersonation thread for the
service.
8.4 Limitations of Kerberos

5.  Biggest lose: assumption of secure time system, and resolution of synchronization
required. Could be fixed by challenge-response protocol during auth handshake.
 Password guessing: no authentication is required to request a ticket, hence attacker can
gather equivalent of /etc/passwd by requesting many tickets. Could be fixed by D-H key
exchange.
 Chosen plaintext: in CBC, prefix of an encryption is encryption of a prefix, so attacker
can disassemble messages and use just part of a message. (Is this true for PCBC?)
Doesn't work in Kerberos IV, since the data block begins with a length byte and a string,
destroying the prefix attack.
 Limitation: Not a host-to-host protocol. (Kerberos 5 is user-to-user; Kerberos 4 is only
user-to-server)
8.5 Disadvantages of Kerberos
Although Kerberos removes a common and severe security threat, it may be difficult to
implement for a variety of reasons:
 Migrating user passwords from a standard UNIX password database, such as /etc/passwd
or /etc/shadow, to a Kerberos password database can be tedious, as there is no automated
mechanism to perform this task.
 Kerberos has only partial compatibility with the Pluggable Authentication Modules
(PAM) system used by most Red Hat Enterprise Linux servers. Refer to Section 43.6.4,
“Kerberos and PAM” for more information about this issue.
 Kerberos assumes that each user is trusted but is using an untrusted host on an untrusted
network. Its primary goal is to prevent unencrypted passwords from being transmitted
across that network. However, if anyone other than the proper user has access to the one
host that issues tickets used for authentication — called the key distribution center (KDC)
— the entire Kerberos authentication system is at risk.
 For an application to use Kerberos, its source must be modified to make the appropriate
calls into the Kerberos libraries. Applications modified in this way are considered to be
Kerberos-aware, or kerberized. For some applications, this can be quite problematic due
to the size of the application or its design. For other incompatible applications, changes
must be made to the way in which the server and client communicate. Again, this may
require extensive programming. Closed-source applications that do not have Kerberos
support by default are often the most problematic.
 Kerberos is an all-or-nothing solution. If Kerberos is used on the network, any
unencrypted passwords transferred to a non-Kerberos aware service is at risk. Thus, the
network gains no benefit from the use of Kerberos. To secure a network with Kerberos,

6. one must either use Kerberos-aware versions of all client/server applications that transmit
passwords unencrypted, or not use any such client/server applications at all.
8.6 Conclusion
The authentication process implemented by Kerberos is highly effective, Kerberos IV is
widely distributed and security is becoming more important, so we need to evaluate its
limitations (lack of features) and weaknesses (attack vulnerabilities), given that it's being used in
some systems whose underlying assumptions differed from MIT Athena's. Some problems are
fixed in proposed Kerberos V, but not all, and others are introduced through new mechanisms
that have not been thoroughly analyzed for security.
Kerberos provides a means of verifying the identities of principals on an open
(unprotected) network. This is accomplished without relying on authentication by the host
operating system, without basing trust on host address, without requiring physical security of all
the hosts on the network, and under the assumption that packets travelling along the network can
be read, modified, and inserted at will.

7. one must either use Kerberos-aware versions of all client/server applications that transmit
passwords unencrypted, or not use any such client/server applications at all.
8.6 Conclusion
The authentication process implemented by Kerberos is highly effective, Kerberos IV is
widely distributed and security is becoming more important, so we need to evaluate its
limitations (lack of features) and weaknesses (attack vulnerabilities), given that it's being used in
some systems whose underlying assumptions differed from MIT Athena's. Some problems are
fixed in proposed Kerberos V, but not all, and others are introduced through new mechanisms
that have not been thoroughly analyzed for security.
Kerberos provides a means of verifying the identities of principals on an open
(unprotected) network. This is accomplished without relying on authentication by the host
operating system, without basing trust on host address, without requiring physical security of all
the hosts on the network, and under the assumption that packets travelling along the network can
be read, modified, and inserted at will.