14 577

1
A seminar report on
KERBEROS
BY
K.RAJA GANGADHAR
14A81A0577
(Under the guidance of MR.J.VIJITHANAND, M.TECH)
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SRI VASAVI ENGINEERING COLLEGE
Pedatadepalli, Tadepalligudem-534101,
W.G.Dist, AndhraPradesh,
2016 - 17

2
ABSTRACT
The Kerberos Authentication Service, developed by the Massachusetts Institute of
Technology (MIT). It was developed to enable network applications to securely identify their
peers across an insecure network and to protect the privacy and integrity of communication
with those services. Based on Needham-Schroeder-Protocol versions 1-3 of Kerberos were
only internal releases and never made public. While version 4 was a step up from traditional
security in networked systems, although v4 has its security flaws and extensions were needed
to allow its wide applications in environments with different characteristics than that at MIT.
This paper will show our more detailed specifications taking into account encryption types,
flags and options, error messages and a few timestamps analyzing Kerberos 5(1.10.3) which
is the latest release.

3
INDEX
Contents Page No.
1. Introduction 1
1.1 What is Kerberos? 1
1.2 What are the Goals? 2
1.3 Evolution 2
2. Pieces of Puzzles 5
2.1 Privacy and integrity 6
2.2 Kerberos Terminology and Concepts 6
3. Protocols 9
3.1 Kerberos 4 9
3.2 Kerberos 5 10
3.3 Kerberos 5-to-4 Ticket Translation 12
4. Troubleshooting 14
4.1 Error and Solutions 14
5. Security 15
5.1Kerberos Attacks 15
5.2 Other Attacks 16
5.3 Protocol Security Issues 17
5.4 Security Solutions 19
6. Applications 20
6.1 Services and Keytabs 20
6.2 Transparent Kerberos Login with PAM 20
6.3 Mac OS X and the login Window 21
7. Advance Topic 22
7.1 Using Kerberos 4 Services with Kerberos 5 22
8. Kerberos Future 23
8.1Smart Cards 23
8.2 Better Encryption 23
8.3Kerberos Referrals 24
8.4Web Services 25
9. References 27

4
LIST OF FIGURES
Figure Name Page No.
Figure 1: AS_REQ and AS_REP exchange 9
Figure 2: Encryption types in a typical TGS reply 11
Figure 3: Kerberos replay attack 18

5
1. INTRODUCTION
1.1 What is Kerberos? :
Kerberos is a secure method for authenticating a request for a service in a computer
network. Kerberos was developed in the Athena Project at the Massachusetts Institute of
Technology (MIT). The name is taken from Greek mythology; Kerberos was a three-headed
dog who guarded the gates of Hades. Kerberos lets a user request an encrypted "ticket" from
an authentication process that can then be used to request a particular service from a server.
The user's password does not have to pass through the network. A version of Kerberos (client
and server) can be downloaded from MIT or you can buy a commercial version.
1.1.1 Advantages of Kerberos:
Most conventional network services use password-based authentication schemes.
Such schemes require a user to authenticate to a given network server by supplying their
username and password. Unfortunately, the transmission of authentication information for
many services is unencrypted. For such a scheme to be secure, the network has to be
inaccessible to outsiders, and all computers and users on the network must be trusted and
trustworthy.
Even if this is the case, a network that is connected to the Internet can no longer be
assumed to be secure. Any attacker who gains access to the network can use a simple packet
analyzer, also known as a packet sniffer, to intercept usernames and passwords,
compromising user accounts and the integrity of the entire security infrastructure.
1.1.2 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. Refer to Question 2.23 in the online Kerberos.

6
Kerberos has only partial compatibility with the Pluggable Authentication Modules (PAM)
system used by most Red Hat Enterprise Linux servers. Refer to Section 42.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, 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.
1.2 What are the Goals? :
The primary design goal of Kerberos is to eliminate the transmission of unencrypted
passwords across the network. If used properly, Kerberos effectively eliminates the threat that
packet sniffers would otherwise pose on a network.
1.3 Evolution of Kerberos:
1.3.1 Early Kerberos (v1, v2, v3):
The early versions of Kerberos (pre-Version 4) were created and used internally at
MIT for testing purposes. These implementations contained significant limitations and were

7
only useful to examine new ideas and observe the practical issues that arose during
development and testing.
1.3.2 Kerberos 4:
The first version of Kerberos distributed outside of MIT was Kerberos 4. First
released to the public on January 24, 1989, Kerberos 4 was adopted by several vendors, who
included it in their operating systems. In addition, other, large distributed software projects
such as the Andrew File System adopted the concepts behind Kerberos 4 for their own
authentication mechanisms.The basics of what was to become the Kerberos 4 protocol are
documented in the Athena Technical Plan. Ultimately, the details of the protocol were
documented through the source code in the reference implementation published by MIT.
However, due to export control restrictions on encryption software imposed by the
U.S. government, Kerberos 4 could not be exported outside of the United States. Since
Kerberos 4 uses DES encryption, organizations outside of the U.S. could not legally
download the Kerberos 4 software as-is from MIT. In response, the MIT development team
stripped all of the encryption code from Kerberos 4 to create a specialized, exportable
version. Eric Young, at Bond University of Australia, took this stripped version of Kerberos 4
and added his own implementation of DES to create "eBones.” Since eBones contained
encryption software developed outside of the United States, it was unencumbered by the U.S.
encryption export controls, and could be legally used anywhere in the world.
Today, several implementations of Kerberos 4 still exist. The original MIT Kerberos 4
implementation is now in a maintenance mode and officially considered “dead.” The kth-krb
distribution, developed in Sweden, is still actively developed but it is highly recommended
that new installations use the superior Kerberos 5 instead. In this book, coverage of Kerberos
4 is restricted to a discussion of the protocol in Chapter 3. Most of the book covers the next
version of Kerberos, Kerberos 5.
1.3.3 Kerberos 5:
Kerberos 5 was developed to add features and security enhancements that were not
present in Version 4 of the protocol. Kerberos 5 is the latest version of the Kerberos protocol
and is documented in RFC 1510.

8
To correct the deficiencies in the Kerberos 4 protocol, several new features were added. They
include:
 A better wire protocol, based on ASN.1
 Credential forwarding and delegation
 Replay cache
 More flexible cross-realm authentication
 Extensible encryption types
 Pre-authentication

9
2. PIECES OF PUZZLES
2.1 Privacy and Integrity:
Authentication is the verification of the identity of a party who generated some data,
and of the integrity of the data. A principal is the party whose identity is verified. The verifier
is the party who demands assurance of the principal's identity. Data integrity is the assurance
that the data received is the same as generated. Authentication mechanisms differ in the
assurances they provide: some indicate that data was generated by the principal at some point
in the past, a few indicate that the principal was present when the data was sent, and others
indicate that the data received was freshly generated by the principal. Mechanisms also differ
in the number of verifiers: some support a single verifier per message, while others support
multiple verifiers. A third difference is whether the mechanism supports non-repudiation, the
ability of the verifier to prove to a third party that the message originated with the principal.
Because these differences affect performance, it is important to understand the
requirements of an application when choosing a method. For example, authentication for
electronic mail may require support for multiple recipients and non-repudiation, but can
tolerate greater latency. In contrast, poor performance would cause problems for
authentication to a server responding to frequent queries.
Other security services include confidentiality and authorization. Confidentiality is the
protection of information from disclosure to those not intended to receive it. Most strong
authentication methods optionally provide confidentiality. Authorization is the process by
which one determines whether a principal is allowed to perform an operation. Authorization
is usually performed after the principal has been authenticated, and may be based on
information local to the verifier, or based on authenticated statements by others.
The remainder of this article will concentrate on authentication for real-time,
interactive services that are offered on computer networks. We use the term real-time loosely
to mean that a client process is waiting for a response to a query or command so that it can
display the results to the user, or otherwise continue performing its intended function. This
class of services includes remote login, file system reads and writes, and information retrieval
for applications like Mosaic.

10
2.1 Why Kerberos:
The introduction discussed the problems associated with password based
authentication and, in particular, how passwords can be collected by eavesdropping. In
addition to the security concern, password based authentication is inconvenient; users do not
want to enter a password each time they access a network service. This has led to the use of
even weaker authentication on computer networks: authentication by assertion.
While more convenient for the user, authentication by assertion hardly qualifies as
authentication at all. Examples include the Berkeley R-command suite and the IDENT
protocol. With authentication by assertion, applications assert the identity of the user and the
server believes it. Such authentication is easily thwarted by modifying the application. This
may require privileged access to the system, which is easily obtained on PCs and personal
workstations. While most uses of authentication by assertion require that a connection
originate from a ``trusted'' network address, on many networks, addresses are themselves
simply assertions.
Stronger authentication methods base on cryptography are required. When using
authentication based on cryptography, an attacker listening to the network gains no
information that would enable it to falsely claim another's identity. Kerberos is the most
commonly used example of this type of authentication technology. Unfortunately, strong
authentication technologies are not used as often as they should be, although the situation is
gradually improving.
2.2 Kerberos Terminology and Concepts:
2.2.1 Kerberos-Specific Terminology:
You need to understand the terms in this section in order to administer KDCs. The
Key Distribution Center or KDC is the component of Kerberos that is responsible for issuing
credentials. These credentials are created by using information that is stored in the KDC
database. Each realm needs at least two KDCs, a master and at least one slave. All KDCs
generate credentials, but only the master KDC handles any changes to the KDC database.

11
A stash file contains the master key for the KDC. This key is used when a server is
rebooted to automatically authenticate the KDC before starting the Kadin and krb5kdc
commands. Because this file includes the master key, the file and any backups of the file
should be kept secure. The file is created with read-only permissions for root. To keep the file
secure, do not change the permissions. If the file is compromised, then the key could be used
to access or modify the KDC database.
2.2.2. Authentication-Specific Terminology:
You need to know the terms in this section to understand the authentication process.
Programmers and system administrators should be familiar with these terms.A client is the
software that runs on a user's workstation. The Kerberos software that runs on the client
makes many requests during this process. So, differentiating the actions of this software from
the user is important.
The terms server and service are often used interchangeably. To clarify, the term
server is used to define the physical system that Kerberos software is running on. The term
service corresponds to a particular function that is being supported on a server (for example,
ftp or n’s). Documentation often mentions servers as part of a service, but this definition
clouds the meaning of the terms. Therefore, the term server refers to the physical system. The
term service refers to the software.
The Kerberos product uses two types of keys. One type of key is a password derived
key. The password derived key is given to each user principal and is known only to the user
and to the KDC. The other type of key used by the Kerberos product is a random key that is
not associated with a password and so is not suitable for use by user principals. Random keys
are typically used for service principals that have entries in a keytab and session keys
generated by the KDC. Service principals can use random keys since the service can access
the key in the keytab which allows it to run non-interactively. Session keys are generated by
the KDC (and shared between the client and service) to provide secure transactions between a
client and a service.

12
A ticket is an information packet that is used to securely pass the identity of a user to
a server or service. A ticket is valid for only a single client and a particular service on a
specific server. A ticket contains:
 Principal name of the service
 Principal name of the user
 IP address of the user's host
 Timestamp
 Value which defines the lifetime of the ticket
 Copy of the session key
All of this data is encrypted in the server's service key. Note, the KDC issues the ticket
embedded in a credential described below. After a ticket has been issued, it can be reused
until the ticket expires.A credential is a packet of information that includes a ticket and a
matching session key. The credential is encrypted with the requesting principal's key.
Typically, the KDC generates a credential in response to a ticket request from a client.
An authenticator is information used by the server to authenticate the client user principal.
An authenticator includes the principal name of the user, a timestamp, and other data. Unlike
a ticket, an authenticator can be used once only, usually when access to a service is requested.
An authenticator is encrypted by using the session key shared by the client and server.
Typically, the client creates the authenticator and sends it with the server's or service's ticket
in order to authenticate to the server or service.

13
3. PROTOCOLS
3.1 Kerberos 4:
The base of Kerberos protocol is Needham-Schroeder protocol. There are only two
differences between the two protocols. These two differences are shown below
1. The hosts present in the Kerberos 4 protocol do exchange of mapping directly that is
present in the Needham-Schroeder protocol.
2. The authentication client is a Kerberos 4 user workstation, and the authentication
server maps to a Kerberos 4 Key Distribution Center.
The following figure shows the AS_REQ and AS_REP of the protocols
Figure 1: AS_REQ and AS_REP exchange

14
3.2 Kerberos 5:
Kerberos 5 is evolved from Kerberos 4. It has all the functions that Kerberos 4 has in
its functionality. But also there are few differences and extensions. The Kerberos 4 protocol
had some drawbacks in its structure that it has may be an obtuse structure and it was not
capable of expanding as many of the fields have fixed and defined sizes. These limitations
create some problems most notably the dependence on single-DES encryption keys. When
Kerberos was invented there was a brute-force attack was made on DES that was
prohibitively expensive in terms of both resources and time. So it is necessary for the
presence of such brute force as the speed of computer during its function. Hence it is needed
to have a larger encrypted algorithm with larger encryption key. It is unfortunately not
possible to increment the size of Kerberos 4 so there is no way for retrofit.
Although in Kerberos 5 protocol is still under development process. Its main features
are given below
3.2.1 New Encryption Options:
This option indicates that for a single protocol transaction there could be either one or
type of encryptions present. Even in the following messages separate encryptions can be
used.
Ticket:
The encryption associated with is used to encrypt the ticket in the TGS or AS reply.
Since the ticket can only be decrypted by the service, as it is encrypted with the service’s
encryption key, the type of encryption made on the ticket is determined by the highest
encryption that is supported by the service for particular ticket.
Reply:
The encryption type of the reply from the KDC to the client refers to the part of the
reply encrypted with the user’s encryption key. Since the ticket can only be decrypted by the
client support, as it is encrypted with the client support encryption key, the type of encryption
made on the ticket is determined by the highest encryption that is supported by the client
support for particular ticket.

15
Session key:
This key is a sharing between the client and the server so here needed to have that
type of encryption key that is supported by both client support and service.
For example, if the client supports single and triple DES but the service only supports
single DES, then the KDC will issue single DES session keys for this service.
A diagram showing where each encryption key comes into play in a typical TGS
reply is shown in below.
Figure 2: Encryption types in a typical TGS reply
A fine gained control is enabled if all the three parties have at least one type of
encryption in common. When KDC is used to create a, it normally make a storage of its
encryption key using all of the different encryption types that it supports. Therefore, the most
secure encryption type that is supported by all the three parties is given out by KDC.

16
3.2.2 Ticket Options:
Kerberos 5 includes advanced features that allow users more control over their
Kerberos tickets.
The following flags have been added to Kerberos 5:
Forward able tickets:
A user can request a forward able ticket. A forward able ticket can be given to another
host later. After that the ticket and the ticket name are used by the new host. A common
special case is the forward able Ticket Granting Ticket.
Proxiable tickets:
It is also possible to set the proxiable flag on a ticket.like forward able tickets they can
also be transferred to other host. However, a proxiable TGT can only be used to acquire
further service tickets; it cannot be used to acquire a new TGT on the target host.
Renewable tickets:
Kerberos 5 introduces a two-tiered life time scheme. The scheme gets the benefits of
longer lifetimes with the security of shorter lifetimes.
For example, if a user needs a renewable ticket he is issued by a ticket having a
standard lifetime and a renewable lifetime. The ticket is valid only for the duration of the
standard lifetime, but can be submitted back to the KDC for renewal any time before the
ticket expires (at the end of the standard lifetime). The KDC can refuse to validate the ticket.
Postdated tickets:
It is a special type of ticket which is not valid until some specified date in the future.
It will be refused if a postdated ticket is presented for validation before the start date
embedded in the ticket
3.3 Kerberos 5-to-4 Ticket Translation:
To show some similarity with older Kerberos 4 services, Kerberos 5 provides with a
service, knows as Kerberos 5-to-4 ticket translation service. This service is also called

17
krb524. It gives you an opportunity that the clients of Kerberos version 5 can interact with the
previous Kerberos version 4 services, but it does not provide the clients of Kerberos version 4
a way to interact with Kerberos 5 services or KDCs.
When a Kerberos 5 client wants to develop a connection to service that is only
understandable by Kerberos 4 tickets, then the Kerberos protocol libraries contact a machine
that is running the krb524 daemon in order to such credentials to the present service
compatible with Kerberos 4. When the krb524 daemon receives a request from a client, it
performs following functions
1. Decryption of the service ticket with the service’s key
2. Extraction of the session key contained inside
3. Creation of a new Kerberos 4 ticket for the same service and client
4. Pasting in the session key from the original Kerberos 5 ticket.
It is important to note that during this process, the session key present inside the original
ticket of Kerberos 5 should be a single DES key. The krb524 daemon will not produce a new
session key but instead it only copies the session key from the present ticket to a new ticket of
Kerberos 4. Given that the Kerberos 4 can only manage the single types of DES key, this
session key should be a single DES key.

18
4. TROUBLESHOOTING
4.1 Errors and Solutions:
Here, we’ll run through a few problem cases, starting from the initial indications of a
problem to its solution.
Errors Obtaining an Initial Ticket:
Different errors can take place while trying to achieve an initial “Ticket Granting
Ticket” (TGT) from a KDC of Kerberos. But still there are a lot of ways to obtain a TGT, for
example through integrated login with a “PAM Kerberos” module, the most best and easy
way to solve these problems is by manually implementing the UNIX knit program.
Unsynchronized Clocks:
Commonly, the error message generated when there is a mismatch in the clock which
is self-explanatory. The Network Time Protocol (NTP) fits this un-synchronization properly.
Suppose you are facing a trouble with your Kerberos installation. The very first step to solve
this issue, like solving any other problem, is to finish the main cause that is creating the
trouble. Here, we will determine as if our issue belongs to one of the three different sections
or areas, and will continue our troubleshooting from that point.
A convenient way to categorize an issue including Kerberos authentication is via what
tickets the client can achieve for a better service. It could be one of the three major categories
given below:
 Client is unable to get an initial “Ticket Granting Ticket”.
 Client possesses a valid TGT but faces some error prior to the achievement of a
service ticket.
 Client possesses a valid TGT and has acquired service ticket, but faces error upon
connection to the Kerberized service.
All of an often, especially with some of the more obscure errors that Kerberos can
generate, administrators experience an error per day, solve the problem, then face the same
error after one week, and have to find out the root cause again, only to search out that the
solution is slightly known.

19
5. SECURITY
Kerberos is the most popular cross-platform, network-wide authentication system
available, it by no means has a perfect security record. It is true that a lot of thought was put
into making Kerberos as secure as possible; however, there are still security issues that
require much more attention.
It is important that implementing Kerberos on your network does not guarantee
perfect security. While Kerberos is extremely secure in a theoretical sense, there are many
practical security issues to be considered. In addition, it is important to that Kerberos
provides only authentication service; it does not prevent compromises caused by buggy
server software, administrators granting permissions to unauthorized users, or poorly chosen
passwords.
5.1 Kerberos Attacks:
There are some electronic attacks that can compromise the security of your Kerberos system.
1. Root compromise of a Kerberos KDC machine. A root-level compromise of a KDC
machine gives the attacker full control over the entire Kerberos authentication system.
Anyhow the Kerberos database is encrypted on disk with the Kerberos master key, the
master key is also kept on the KDC’s disk so no manual intervention is required (to
enter in the master password) when the KDC service is started.
2. Compromise of a Kerberos administrator’s credentials. If an attacker obtains the
password of a Kerberos administrative principal, then the attacker can get complete
access to the entire Kerberos database. Mostly the KDC implementations allow
administrators to remotely dump the contents of the database for backup purposes,
and an attacker can use this to make a complete copy of your authentication database.
The attacker can also create and modify any Kerberos principal with full access to the
database.
3. Root compromise of a server machine. Some services, such as the AFS distributed file
system, share a single service principal across all servers. In this case, root access to
an AFS file server machine could compromise all file and database servers in the AFS
cell. Once an attacker has access to a service principal’s credentials, the attacker can
impersonate this service and also decrypt the encrypted traffic sent between clients

20
and the compromised service. The security of Kerberized services running on a server
depends on the security of this individual server; for this all servers should be secured
in proportion to the value of the resources stored on that server.
4. Compromise of user credentials. There are two possible scenario: either the user’s
credential (ticket) cache is exposed, or a user’s password is compromised. If an
attacker get the user’s unencrypted credential cache, the tickets contained in that
cache are only valid for the time period specified in the tickets. Also if an attacker
acquires the user’s password, the attacker can impersonate that user until the user
changes his password.
5.2 Other Attacks:
1. Denial of service:
A denial of service attack can be against your organization’s KDCs by flooding them
with authentication requests. The large numbers of requests arriving can slow down response
times to legitimate requests, most of time in extreme cases, crashes the machines in which
KDCs reside. Kerberos cannot protect against denial of service attacks and it is recommended
that your network, including your Kerberos KDCs, be firewalled from the Internet to prevent
this type of attack. Adding additional KDCs to your network for redundancy can overcome
the effects of a DoS attack.
2. The “insider”:
Kerberos does not protect against an internal authorized user who decides to misuse
their privileges. For example, a rogue Kerberos administrator can modify or remove
information from the Kerberos database.
3. Social engineering and password exposure:
Similarly, Kerberos does not protect against individual users who divulge their
passwords to attackers, either inadvertently or as a result of a social engineering attack.
Similarly, Kerberos does not prevent users from reusing their passwords at less secure sites
that may handle passwords in the clear. Hackers who successfully attack a less secure site
where a user has recycled their Kerberos password will obtain a valid username and password
for your Kerberos realm.

21
4. Security holes in the Kerberos software itself:
Unfortunately, with the current state of the art in software engineering, it is very
difficult to write secure code. Just like all other software packages available, every Kerberos
implementation has security issues at some point or another, and these issues can sometimes
lead to a compromise of your KDCs. Therefore, it is important to keep informed of your
Kerberos vendor’s patches, and apply them as soon as they become available.
5.3 Protocol Security Issues:
Kerberos was designed to protect authentication data from passing over a network in
the clear. Kerberos encrypts all authentication exchanges that occur over the network.
Encryption is the only part of the solution, however the designers of Kerberos has put much
thought into ensuring as secure a system as possible.
5.3.1 Dictionary and Brute-Force Attacks:
TGT is encrypted with the user’s secret key (derived from her password). The security
of the whole system is dependent on not being able to decrypt this message, since if an
attacker is able to retrieve the key used to encrypt the message, he can have the user’s
password and can impersonate that user at will. Therefore, if an attacker wishes to obtain a
user’s password, he will ask the KDC for a valid TGT for the victim’s username. While there
are no ways to break the encryption methods used in Kerberos tickets directly, the attacker
can continue to brute-force the decryption of the TGT by launching an offline dictionary
attack.
During a dictionary attack, an attacker use a list of commonly used passwords, or a
dictionary, to a cracking program. For each entry in the dictionary, a program attempts to
decrypt the message using the password. If a hit is made, the program reports back to the
attacker, the user’s password.
5.3.2 Replay Attacks:
All protocol exchanges are simply electronic messages that are sent over a computer
network, an attacker can listen to the network messages involved in a successful
authentication exchange, make a copy of the messages, and replay them at a later time. The
attacker no need to guess the users password or decrypt any messages in this scenario. Since

22
the replay attack requires access to listen to all network messages as well as the ability to
send fake messages, a replay attack is an active attack. A theoretical replay attack is pictured
in figure.
Figure 3: Kerberos replay attack
In this figure, we see that Alice successfully obtains tickets to authenticate to her mail
server. Bob is surreptitiously listening to all network traffic between Alice, the mail server,
and the Kerberos KDC. Bob will not directly use the TGT that Alice requests in the first step,
since the TGT must be decrypted with Alice’s password, which Bob does not know (although
he can try to brute-force the password). However, when Alice sends her encrypted ticket and
authenticator, Bob can intercept that message and replay it to impersonate Alice to the mail
server.
5.3.3 Man-in-the-Middle Attacks:
A man-in-the-middle attack affects most any protocol that attempts to verify the
identity of connection endpoints. A man-in-the-middle attack is an active attack, meaning that
the attacker must be able to read all messages on the network as well as send out arbitrary
messages of his own desire .The goal of in this is to impersonate the server, resulting in the
user thinking that he connected to the desired server, which in fact he is talking to the
attacker. Once the attacker has control of the session, it can act as a simple pass-through
(passing messages between the user and the server, without modification), or can actively
inject, modify, or delete messages between the user and the server. The attacker now is part
of the conversation between the user and the server, and can modify any messages that pass
through him.

23
Kerberos protocol has built-in protection against man-in-the-middle attacks. Since Kerberos
performs mutual authentication, by confirming not only the end user’s identity but also the
server’s identity, man-in-the-middle attacks are thwarted.
5.4 Security Solutions:
5.4.1 Requiring Pre-Authentication:
The Microsoft Windows KDC is the only implementation that requires clients to pre-
authenticate by default. In some implementations, a command-line option or flag can be used
to require all clients to use pre authentication. Other implementations require the
administrator to explicitly specify which principals need to pre-authenticate before granting
TGT.
5.4.2 Enforcing Secure Passwords:
The security of your entire network depends on your users choosing passwords.
However, experience shows that most users choose poor passwords. In one realm that already
has password strength-checking in place, over 2,000 passwords in a Kerberos realm
consisting of 25,000 principals were successfully brute force during a 2-week period. This
experiment was performed with a spare CPU cycles available on systems readily available in
1998
5.4.3 Enforcing Password Lifetimes and History:
Policies on password strength, many organizations also specify a maximum lifetime
for user passwords after which the user must change to a new password. Most Kerberos KDC
implementations has enforce a maximum and minimum lifetime for user passwords, as well
as a password history which ensure that users do not simply reuse previous passwords to
evade the mandatory password change.

24
6. APPLICATION
Establishing a Kerberos and creating KDCs is only the beginning of creating a
Kerberos-based authentication infrastructure. To get the benefits of Kerberos, we have to
install Kerberos-enabled services and client software. Following are the some applications of
Kerberos:
6.1 Services and Keytabs:
Kerberos provides a service that verifies the identity of two connection endpoints,
which have been identified by unique names, or principals. It is obvious that each user is
associated with a principal name that is stored in the Kerberos database, so all authentication
schemes by their very nature require that all users be uniquely identified with an associated
secret. However, the concept that all services that user contact through Kerberos require a
principal and secret key.
In Windows hosts, service keys are automatically created as needed when Kerberized
services are installed. Unix-based Kerberos systems require a bit more manual configuration.
A service principal has three major components: the service name, the hostname of the
machine that provides the service, and the Kerberos to which the machine belongs A Keytab
files contain highly sensitive information, encryption keys, so it is imperative to ensure
proper access controls to these files. Each Kerberized service should run as a different,
unique username, and the keytab file for that service it should be readable only by that
username. The compromise of a service’s key allows an attacker to masquerade any
authorized principal when communicating to that service, and also allows an attacker to read
any conversation between clients and compromised service.
6.2 Transparent Kerberos Login with PAM:
When a user logs into his workstation, then the user to acquire a Kerberos Ticket
Granting Ticket when he enters his credentials. It is called as transparent Kerberos login. In
Windows 2000, XP, and 2003 automatically acquire tickets for login when the user is part of
a Windows domain. For other systems, we have to configure this step manually. In UNIX,
the simplest and most portable way to get initial credentials for a user upon login is that
through the Pluggable Authentication Modules (PAM), which is available on most operating
systems. Using PAM, you can acquire Kerberos tickets upon logins that occur on the

25
system’s console (and any other network based protocol, but we want to avoid sending
passwords over the network).
If the operating system comes without source, we will not be able to replace the
program with one that performs the necessary authentication method. PAM solves this
problem by providing a standard plug-in interface that both application developers and
authentication method developers can used this to.
6.3 Mac OS X and the Login Window:
The initial console login window presented to Mac OS X users is appropriately
enough, the login window. Unfortunately, login window’s PAM support is incomplete. Apple
has provided special support in the login window for Kerberos 5 users, contained in Mac OS
X 10.2 and above to provide users with Kerberos tickets when logging into their OS X
system.
The Mac OS X Security and Authorization Services use the /etc/ authorization file,
and this is the file which we will use to enable Kerberos authentication in login window.

26
7. ADVANCE TOPIC
7.1 Using Kerberos 4 Services with Kerberos 5:
Those who have Kerberos 4 services that need to be integrated into a Kerberos 5
realm need to implement the Kerberos 5-to-4 ticket translator daemon. Both MIT and
Heimdal include support for this protocol, the krb524 protocol, the only limit on where the
krb524 daemon can run is that the daemon must have access to the service keys for the
Kerberos 4-based services for which it translates tickets.The MIT Kerberos 5 distribution
includes a separate krb524 daemon, krb524d. There are two different modes of operation that
krb524d supports master and keytab. The master mode is meant to be run on a KDC in the
Kerberos realm, and reads the necessary service keys directly from the Kerberos database.
If it is not possible to run the krb524d directly on the KDC, then the second mode of
operation can be used keytab.Keytab mode requires that a Kerberos keytab be installed on the
machine running krb524d that includes the service keys for all of the Kerberos 4 services in
the realm.

27
8. KERBEROS FUTURE
8.1 Smart Card:
A smart card is a small, tamperproof computer. The smart card itself contains a CPU
and some non-volatile storage. This capability makes it possible for the card to keep some
secrets, such as the private keys associated with any certificates it holds.
 Contact cards require a reader to facilitate the bidirectional connection. The card must
be inserted into a device that touches the contact points on the card, which facilitate
communication with the card’s chip. Contact card readers are commonly built into
company or vendor-owned buildings and assets, cellular phones, handheld devices,
stand-alone devices that connect to a computer desktop’s serial or Universal Serial
Bus (USB) port, laptop card slots, and keyboards.
 Contactless cards use proximity couplers to get information to and from the card’s
chip. An antenna is wound around the circumference of the card and activated when
the card is radiated in a specific distance from the coupler.
8.1.1 Why Smart Cards:
Smart cards are a key component of the public key infrastructure (PKI) that Microsoft
is integrating into the Windows platform because smart cards enhance software-only
solutions, such as client authentication, logon, and secure email. Smart cards are a point of
convergence for public key certificates and associated keys because they:
 Provide storage for protecting private keys and other forms of personal information
 Isolate security-critical computations, involving authentication, digital signatures, and
key exchange from other parts of the system that don’t have a need to know.
8.2 Better Encryption:
The art and algorithms of cryptography are always driven by the growth in computer
power and cryptographic theory. Increasing computer power provides a dual driving force for
emerging cryptographic algorithms: first, it solved older algorithms and short key lengths as
they fall to practical brute-force attacks.

28
A 56-bit single DES key can be brute forced by a network of commodity computers in
less than a week, and that time is decreasing rapidly. Conversely, the increase in computing
power makes possible the complex calculations of even more sophisticated algorithms and
longer key lengths necessary to secure information.
 Because Kerberos is a system that depends heavily on cryptography, it is crucial that
these new encryption methods are implemented in the Kerberos protocol. The
Kerberos 5 protocol was designed to be extendable and support multiple encryption
type’s implementations is single DES. Thankfully, the upcoming release of MIT
Kerberos 1.3 will provide wider support for the RC4-HMAC encryption type first
introduced by Microsoft for use in Windows 2000’s Kerberos service.
 For further growth, there are proposed Internet Drafts that specify more, stronger
encryption options for future implementations.
8.3 Referrals:
Current implementations of the Kerberos Authentication Service (AS) and ticket-
Granting Service (TGS) protocols use names constructed from a known user or service name.
A service name is typically constructed from a name of the service and the DNS host name of
the computer that is providing the service. Many existing employments of Kerberos use a
single Kerberos realm where all users and services would be using the same realm. However,
in an environment where here are multiple Kerberos realms, the client needs to be able to
determine what realm a particular user or service is in before making an AS or TGS request.
Traditionally, this requires client configuration to make this possible. However, in many
cases, the user would like to use a more familiar name that is not directly related to the realm
of their Kerberos principal name. In practice, this would be the name that the user specifies
to obtain a TGT from a Kerberos KDC.
Once a TGT has been obtained, the user would like to be able to access services in
any Kerberos realm for which there is an authentication path from the realm of their
principal. To do this requires that the client be able to determine what realm the target
service principal is in before making the TGS request. Current implementations of Kerberos
typically have a table that maps DNS host names to corresponding Kerberos realms. This
mechanism requires that each client have very detailed configuration information about the
hosts that are providing services and their corresponding realms.

29
A solution for these problems and simplifies administration by minimizing the
configuration information needed on each computer using Kerberos.
Two kinds of KDC referrals are introduced:
1. Client referrals, in which the client doesn't know which realm contains a user account.
2. Server referrals, in which the client doesn't know which realm contains a server
account.
8.4 Web Services:
Web services security encompasses a number of requirements, such as authentication,
authorization, and message protection.
Because of its nature and its use of open access SOA implemented by Web services
adds a new set of requirements to the security landscape:
Authentication— verifying that the user is who she claims to be. A user's identity is verified
based on the credentials presented by that user, such as:
Authorization (or Access Control) — Granting access to specific resources based on an
authenticated user's entitlements.
Confidentiality, privacy— keeping information secret. Accesses a message, for example a
Web service request or an email, as well as the identity of the sending and receiving parties in
a confidential manner. Confidentiality and privacy can be achieved by encrypting the content
of a message.
Integrity, non-repudiation— making sure that a message remains unaltered during transit by
having the sender digitally sign the message.
8.4.1 Web Service Security Requirements:
 Use transport security to protect the communication channel between the web service
consumer and web service provider.
 Use message-level security to ensure confidentiality by digitally encrypting message
parts; integrity using digital signatures; and authentication by requiring username,
X.509, or SAML tokens.

30
8.4.2 Web Service Security Using Kerberos:
Standards for Web services security are required to ensure interoperability in
heterogeneous environments. The WS Security Standard and its dependents such as a WS-
Trust and WS-Security Policy are important standards in this area. WS-Security is security
token agnostic, allowing the use of a variety of security token types. One security token type
that is popular in Intranet scenarios is the Kerberos token. This is largely because Kerberos is
an integral part of the security system in Microsoft Active Directory server.
It is reasonable to expect that Web services' security interoperability should be
achievable using these standards.

31
9. REFERENCES
1. http://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-
kerberos.html
2. https://en.wikipedia.org/wiki/Kerberos_%28protocol%29
3. Research report on “The Evolution of the Kerberos Authentication Service” by John.T
and B.Clifford
4. Research report on “Verifying Confidentiality and Authentication in Kerberos 5” by
Fredrick Butler,IlianoCorvesato and Andre Scedrov.
5. https://www.drupal.org/project/kerberos_authentication
6. http://www.kerberos.org/software/tutorial.html
7. https://www.safaribooksonline.com/library/view/kerberos-the-
definitive/0596004036/ch06s06.html
8. https://tools.ietf.org/html/rfc1510

14 577

More Related Content

What's hot

Similar to 14 577

More from Chaitanya Ram

Recently uploaded

14 577