report on kerberos

7/29/2019 Report on Kerberos

1/28

1

ABSTRACT

In an open network computing environment, a workstation cannot be trusted to identify its

users correctly to network services. Kerberos provides an alternative approach whereby atrusted third-party authentication service is used to verify users identities. This paper gives

an overview of the Kerberos authentication model as implemented for MITs Project Athena.

It describes the protocols used by clients, servers, and Kerberos to achieve authentication. It

also describes the management and replication of database required. Kerberos is a computer

network authentication protocol, which allows nodes communicating over a non-secure

network to provide their identity to one another in a secure manner. Its designers aimed

primarily at a client-server model, and it provides mutual authenticationboth the user and

the server verify each others identity. Kerberos protocol messages are protected against

eavesdropping and replay attacks. It is designed to provide strong authentication for client-

server applications by using secret-key cryptography. In summary, Kerberos is a solution

to the network security problems; it provides the tools of authentication and strongcryptography over the network to help user secure his information systems across the entire

enterprise.


2/28

2

1. INTRODUCTIONComputer security has been a problem since the very beginning. Proper authentication and

protection using cryptographic methods is a must in todays electronic communication.

Kerberos provides an infrastructure to achieve this using symmetric cryptography.

A. History

Kerberos was developed at the Massachusetts Institute of Technology (MIT) during a project

intended to integrate computers into the universitys undergraduate curriculum. The project,

called Athena, started in 1983 with UNIX timesharing computers, having several terminals

connected to each one, but without a network connection. If a student or staff member

wanted to use any of the computers, he or she sat down at one of these terminals. As soon as

the terminals and old computers were substituted by newer workstations with network

connection, the projects goal was to allow any user to sit down at the workstation of his

or her choice accessing his data over the network (which is a very common scenario for

every network today). The problem of network eavesdropping became apparent. Since the

network has been accessible from all over the campus, nothing prevented students from

running network monitoring tools and learning other users and root passwords. Another big

problem was some PC/ATs which were lacking even fundamental internal security. To

protect the users data in the network environment as it had been protected in the timesharing

environment Kerberos was invented. Kerberos is an authentication system that uses

symmetric key cryptography to protect sensitive information on an open network. It is a

ticket based system that issues a ticket encrypted with the users password when he or she

logs in. The user decrypts the ticket and uses it to obtain tickets for other network services he

or she wants to use. Because all information in tickets is encrypted, it is not susceptible toeavesdropping or misappropriation.

MIT developed Kerberos to protect network services provided by Project Athena. The

protocol was named after the Greek mythological character Kerberos (or Cerberus), known

in Greek mythology as being the monstrous three-headed guard dog of Hades.

B. Motivation

In a network of users requiring services from many separate computers, there are three

approaches one can take to access control: One can do nothing, relying on the machine to

which the user is logged in to prevent unauthorized access; one can require the host toprove its identity, but trust the hosts word as to who the user is; or one can require the

user to prove her/his identity for each required service.

In a closed environment where all the machines are under strict control, one can use the first

approach. When the organization controls all the hosts communicating over the network,

this is a reasonable approach.

In a more open environment, one might selectively trust only those hosts under

organizational control. In this case, each host must be required to prove its identity. In

those protocols, authentication is done by checking the Internet address from which a

connection has been established.


3/28

3

In the Athena environment, we must be able to honor requests from hosts that are not under

organizational control. Users have complete control of their workstations: they can reboot

them, bring them up standalone, or even boot off their own tapes. As such, the third approach

must be taken; the user must prove her/his identity for each desired service. The server must

also prove its identity. It is not sufficient to physically secure the host running a network

server; someone elsewhere on the network may be masquerading as the given server.

The environment places several requirements on an identification mechanism. First, it must

be secure. Circumventing it must be difficult enough that a potential attacker does not find

the authentication mechanism to be the weak link. Someone watching the network should

not be able to obtain the information necessary to impersonate another user. Second, it must

be reliable. Access to the many services will depend on the authentication service. If it is not

reliable, the system of services as a whole will not be. Third, it should be transparent. Ideally,

the user should not be aware of authentication taking place. Finally, it should be scalable.

Many systems can communicate with Athena hosts. Not all of these will support the

mechanism, but software should not break if they did.

Kerberos is the result of our work to satisfy the above requirements. When a user walks up to

a workstation she/he logs in. As far as the user can tell, this initial identification is

sufficient to prove her/his identity to all the required network servers for the duration

of the login session. The security of Kerberos relies on the security of several

authentication servers, but not on the system from which users log in, or on the security of

the end servers that will be used. The authentication server provides a properly authenticated

user with a way to prove her/his identity to servers scattered across the network.


4/28

4

2. KERBEROSKerberos is a computer network authentication protocol, which allows nodes communicating

over a non-secure network to prove their identity to one another in a secure manner. The

Kerberos protocol is designed to provide reliable authentication over open and insecure

networks where communications between the hosts belonging to it may be intercepted.However, one should be aware that Kerberos does not provide any guarantees if the

computers are being used are vulnerable: the authentication servers, application servers and

clients must be kept constantly updated so that the authenticity of the requesting users and

service providers can be guaranteed. Thus we can say that: "Kerberos is an authentication

protocol for trusted hosts on untrusted networks".

Kerberos is a trusted third-party authentication service based on the model presented by

Needham and Schroeder. It is trusted in the sense that each of its clients believes Kerberos

judgment as to the identity of each of its other clients to be accurate. Timestamps (large

numbers representing the current date and time) have been added to the original model to aid

in the detection of replay. Replay occurs when a message is stolen off the network and resent

later.

A. Protocol

Kerberos uses as its basis the symmetric Needham- Schroeder protocol.

1) Needham-Schroeder Authentication

An approach to secure authentication is the Needham- Schroeder protocol. It defines a

three-party authentication service and five step message chain. In the very first step theclient requests a session key for communication with a certain service. The requested

session key and a message encrypted for the service is send back to the client encrypted

with the clients key to protect it in an open network. The client forwards the part for the

service (which is encrypted with the service key) to the desired service. After that the

service generates a random message which is sent back to the client encrypted with the

session key. This random message is transformed in a predefined way and sent back to the

server encrypted with the session key as well to prove that A was the sender of message

number three. After performing these five steps the service can be sure that the client has

authenticated itself correctly, because only the client knows the key to decrypt message

two.

This protocol is no longer considered secure as B does not know if the key is fresh. If an

attacker obtains an old key he or she can perform a replay attack and convince B that the

key they hold is the current key of A.

2) Needham-Schroeder in Kerberos

Kerberos uses a variant of Needham-Schroeder, which uses timestamps on every message

to avoid the problem mentioned above. Due to the fact that it is a problem to keep all clocks

returning exact the same time in a network environment, every message is valid in a time

window from five minutes in the past to five minutes in the future.


5/28

5

In a short time slot of ten minutes length replay attacks are impeded by a replay cache held

by every service.Messages are cached as long as they are valid and authentication attempts

using messages which are already held in cache can be refused.


6/28

6

3. TERMINOLOGYThis section provides the definition of the objects and terms, knowledge of which is essential

for the subsequent description of the Kerberos protocol.

A. Realm

The term realm indicates an authentication administrative domain. Its intention is to establish

the boundaries within which an authentication server has the authority to authenticate a user,

host or service. This does not mean that the authentication between a user and a service that

they must belong to the same realm: if the two objects are part of different realms and there is

a trust relationship between them, then the authentication can take place. This characteristic is

known as Cross-Authentication.

Basically, a user/service belongs to a realm if and only if he/it shares a secret (password/key)

with the authentication server of that realm.

The name of a realm is case sensitive, i.e. there is a difference between upper and lower case

letters, but normally realms always appear in upper case letters. It is also good practice, in an

organization, to make the realm name the same as the DNS domain (in upper case letters

though). Following these tips when selecting the realm name significantly simplifies the

configuration of Kerberos clients, above all when it is desired to establish trust relationships

with sub domains. By way of example, if an organization belongs to the DNS domain

example.com, it is appropriate that the related Kerberos realm is EXAMPLE.COM.

B.Principal

A principal is the name used to refer to the entries in the authentication server database. A

principal is associated with each user, host or service of a given realm. A principal in

Kerberos 5 is of the following type:

component1/component2/.../componentN@REALM

However, in practice a maximum of two components are used. For an entry referring to a

user the principal is the followingtype:

Name[/Instance]@REALM

The instance is optional and is normally used to better qualify the type of user. For example

administrator users normally have the admin instance. The following are examples of

principals referred to users:

[email protected]

admin/[email protected]

pluto/[email protected]
mailto:componentN@REALMmailto:@REALMmailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:@REALMmailto:componentN@REALM


7/28

7

If, instead, the entries refer to services, the principals assume the following form:

Service/Hostname@REALM

C. Ticket

A ticket is something a client presents to an application server to demonstrate the

authenticity of its identity. Tickets are issued by the authentication server and are encrypted

using the secret key of the service they are intended for. Since this key is a secret shared only

between the authentication server and the server providing the service, not even the client

which requested the ticket can know it or change its contents. The main information

contained in a ticket includes:

1. The requesting user's principal (generally the username).2. The principal of the service it is intended for;3. The IP address of the client machine from which the ticket can be used. In Kerberos 5

this field is optional and may also be multiple in order to be able to run clients under

NAT or multi-homed.

4. The date and time (in timestamp format) when the tickets validity commences;5. The ticket's maximum lifetime6. The session key (this has a fundamental role which is described below);

Each ticket has expiration (generally 10 hours). This is essential since the authentication

server no longer has any control over an already issued ticket. Even though the realm

administrator can prevent the issuing of new tickets for a certain user at any time, it cannot

prevent users from using the tickets they already possess. This is the reason for limiting the

lifetime of the tickets in order to limit any abuse over time.

D. Encryption

Kerberos often needs to encrypt and decrypt the messages (tickets and authenticators)

passing between the various participants in the authentication. It is important to note that

Kerberos uses only symmetrical key encryption (in other words the same key is used to

encrypt and decrypt).

1) Encryption type

Kerberos 4 implements a single type of encryption which is DES at 56 bits. The weakness

of this encryption plus other protocol vulnerabilities has made Kerberos 4 obsolete.

Version 5 of Kerberos, however, does not predetermine the number or type of encryption

methodologies supported. It is the task of each specific implementation to support and best

negotiate the various types of encryption. However, this flexibility and expandability of the

protocol has accentuated interoperability problems between the various implementations of

Kerberos 5. In order for clients and application and authentication servers using different

implementations to interoperate, they must have at least one encryption type in common.

The difficulty related to the interoperability between UNIX implementations of Kerberos

5 and the one present in the Active Directory of Windows is a classic example of this.

Indeed, Windows Active Directory supports a limited number of encryptions and only hadDES at 56 bits in common with UNIX. This required keeping the latter enabled, despite
mailto:Hostname@REALMmailto:Hostname@REALMmailto:Hostname@REALM


8/28

8

the risks being well known, if interoperability had to be guaranteed.The problem was

subsequently solved with version 1.3 of MIT Kerberos 5. This version introduced RC4-

HMAC support, which is also present in Windows and is more secure than DES. Among

the supported encryptions (but not by Windows) the triple DES (3DES) and newer AES128

and AES256 are worth mentioning.

2) Encryption key

As stated above, one of the aims of the Kerberos protocol is to prevent the user's password

from being stored in its unencrypted form, even in the authentication server database.

Considering that each encryption algorithm uses its own key length, it is clear that, if the

user is not to be forced to use a different password of a fixed size for each encryption

method supported, the encryption keys cannot be the passwords. For these reasons the

string2key function has been introduced, which transforms an unencrypted password into an

encryption key suitable for the type of encryption to be used. This function is called each

time a user changes password or enters it for authentication. The string2key is called a hash

function, meaning that it is irreversible: given that an encryption key cannot determine thepassword which generated it (unless by brute force). Famous hashing algorithms are MD5

and CRC32.

3) Salt

In Kerberos 5, unlike version 4, the concept of password salt has been introduced. This is a

string to be concatenated to the unencrypted password before applying the string2key

function to obtain the key. Kerberos 5 uses the same principal of the user as salt:

Kmark= string2key (Pmark+ "[email protected]")

Kmarkis the encryption key of the user mark and Pmarkis the unencrypted password of

the user.

This type of salt has the following advantages:

Two principals belonging to the same realm and having the same unencrypted password,

still have different keys. For example, imagine an administrator having a principal for a

principal for everyday work an everyday work ([email protected]) and one for

administrative work(mark/[email protected]). It is very likely that this user has set

the same password for both principals for reasons of convenience. The presence of the salt,

guarantees that the related keys are different.

If a user has two accounts in different realms, it is fairly frequent that the unencrypted

password is the same for both realms: thanks to the presence of the salt, a possible

compromise of an account in one realm will not automatically cause the other to be

compromised.

A null salt can be configured for compatibility with Kerberos4. Vice versa, for

compatibility with AFS, it is possible to configure a salt which is not the complete name of

the principal, but simply the name of the cell.
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:mark/[email protected]:mark/[email protected]:mark/[email protected]:mark/[email protected]:[email protected]:[email protected]


9/28

9

4) Key Version Number (kvno)

When a user changes a password or an administrator updates the secret key for an

application server, this change is logged by advancing a counter. The current value of the

counter identifying the key version is known as the Key Version Number or more brieflykvno.

E. Key Distribution Center (KDC)

The authentication server in a Kerberos environment, based on its ticket distribution function

for access to the services, is called Key Distribution Center or more briefly KDC. Since it

resides entirely on a single physical server (it often coincides with a single process) it can be

logically considered divided into three parts: Database, Authentication Server (AS) and

Ticket Granting Server (TGS).

1) Database

The database is the container for entries associated with users and services. We refer to an

entry by using the principal (i.e. the name of the entry) even if often the term principal is

used as a synonym for entry. Each entry contains the following information:

The principal to which the entry is associated; The encryption key and related kvno; The maximum validity duration for a ticket associated to the principal; The maximum time a ticket associated to the principal may be renewed(only

Kerberos5); The attributes or flags characterizing the behavior of the tickets; The password expiration date; The expiration date of the principal, after which no tickets will be issued.

In order to make it more difficult to steal the keys present in the database, the

implementations encrypt the database using the master key, which is associated with the

principal K/M@REALM. Even any database dumps, used as backups or for propagation

from the KDC master towards the slave, are encrypted using this key, which it is

necessary to know in order to reload them.

2) Authentication Server (AS)

The Authentication Server is the part of the KDC which replies to the initial authentication

request from the client, when the user, not yet authenticated, must enter the password. In

response to an authentication request, the AS issues a special ticket known as the

Ticket Granting Ticket, or more briefly TGT, the principal associated with which is

krbtgt/REALM@REALM. If the users are actually who they say they are they can use the

TGT to obtain other service tickets, without having to re-enter their password.

3) Ticket Granting Server (TGS)

The Ticket Granting Server is the KDC component which distributes service tickets toclients with a valid TGT, guaranteeing the authenticity of the identity for obtaining the
mailto:M@REALMmailto:REALM@REALMmailto:REALM@REALMmailto:M@REALM


10/28

10

requested resource on the application servers. The TGS can be considered as an application

server (given that to access it, it is necessary to present the TGT) which provides the

issuing of service tickets as a service. It is important not to confuse the abbreviations TGT

and TGS: the first indicates a ticket and the second a service.

F. Session Key

As we have seen, the users and services share a secret with the KDC. For users, this secret is

the key derived from their password, while for services, it is their secret key (set by the

administrator). These keys are called long term, since they do not change when the work

session changes.

However, it is necessary that the user also shares a secret with the service, at least for the

time in which a client has a work session open on a server: this key, generated by the

KDC when a ticket is issued, is called the Session Key. The copy intended for the service is

enveloped by the KDC in the ticket (in any case their application server knows the long

term key and can decode it and extract the session key), while the copy intended for the useris encapsulated in an encrypted packet with the user long term key. The session key plays a

fundamental role in demonstrating the authenticity of the user.

G. Authenticator

Even if the user principal is present in a ticket and only the application server can extract and

possibly manage such information (since the ticket is encrypted with the secret key of the

service), this is not enough to guarantee the authenticity of the client. An impostor could

capture (remember the hypothesis of an open and insecure network) the ticket when it is sent

by a legitimate client to the application server, and at an opportune time, send it to

illegitimately obtain the service. On the other hand, including the IP addresses of the

machine from where it is possible to use it is not very useful: it is known that in an open

and insecure network addresses are easily falsified. To solve the problem, one has to exploit

the fact that the client and server, at least during a session have the session key in common

that only they know (also the KDC knows it since it generated it, but it is trusted by

definition!!!). Thus the following strategy is applied: along with the request containing the

ticket, the client adds another packet (the authenticator) where the user principal and time

stamp (its at that time) are included and encrypts it with the session key; the server which

must offer the service, upon receiving this request, unpacks the first ticket, extracts the

session key and, if the user is actually who he/she says, the server is able to unencrypted the

authenticator extracting the timestamp. If the latter differs from the server time by less than 2minutes (but the tolerance can be configured) then the authentication is successful. This

underlines the criticality of synchronization between machines belonging to the same realm.

Credential

H. Replay Cache

The possibility exists for an impostor to simultaneously steal both the ticket and the

authenticator and use them during the 2 minutes the authenticator is valid. This is very

difficult but not impossible. To solve this problem with Kerberos 5, Replay Cache has been

introduced. In application servers (but also in TGS), there exists the capacity to rememberauthenticators which have arrived within the last 2 minutes, and to reject them if they are


11/28

11

replicas. With this the problem is resolved as long as the impostor is not smart enough to

copy the ticket and authenticator and make them arrive at the application server before the

legitimate request arrives. This really would be a hoax, since the authentic user would be

rejected while the impostor would have access to the service.

I. Credential Cache

The client never keeps the user's password, nor does it memorize the secret key obtained by

applying string2key: they are used to decrypt the replies from KDC and immediately

discarded. However, on the other hand, to implement the single sign-on (SSO)

characteristic, where the user is asked to enter the password just once per work session, it is

necessary to memorize the tickets and related session key. The place where this data is

stored is called the "Credential Cache". Where this cache needs to be located does not

depend on the protocol, but varies from one implementation to another. Often for portability

purposes they are located in the file system (MIT and Heimdal). In other implementations

(AFS and Active Directory), in order to increase security in the event of vulnerableclients, the credential cache is placed in an area of the memory accessible only to kernels

and not swappable on the disk.


12/28

12

4. WORKINGKerberos operates by encrypting data with a symmetric key. A symmetric key is atype of authentication where both the client and server agree to use a single

encryption/decryption key for sending or receiving data. When working withthe encryption key, the details are actually sent to a key distribution center, or

KDC, instead of sending the details directly between each computer. The

entire process takes a total of eight steps:

Step 1: The authentication service, or AS, receives the request by the client and

verifies that the client is indeed the computer it claims to be. This is usually just

a simple database lookup of the users ID. (Fig 1)

Fig 1. Authentication service verifies the user ID.

Step 2: Upon verification, a timestamp is created. This puts the current time

in a user session, along with an expiration date. The default expiration dateof a timestamp is 8 hours. The encryption key is then created. The

timestamp ensures that when 8 hours is up, the encryption key is useless. (Thisis used to make sure a hacker doesnt intercept the data, and try to crack the

key. Almost all keys are able to be cracked, but it will take a lot longer than 8

hours to do so.)

Step 3: The key is sent back to the client in the form of a ticket-granting

ticket, or TGT. This is a simple ticket that is issued by the authentication

service. It is used for authenticating the client for future reference. (Fig 2)


13/28

13

Fig 2. Authentication service issues TGT.

Step 4: The client submits the ticket-granting ticket to the ticket-granting

server, or TGS, to get authenticated. (Fig 3)

Fig 3. Client submit TGT to TGS.


14/28

14

Step 5: The TGS creates an encrypted key with a timestamp, and grants the

client a service ticket. (Fig 4)

Fig 4. TGS grants client the service ticket.

Step 6: The client decrypts the ticket, tells the TGS it has done so, and then

sends its own encrypted key to the service.


15/28

15

Step 7: The service decrypts the key, and makes sure the timestamp is still

valid. If it is, the service contacts the key distribution center to receive a sessionthat is returned to the client. (Fig 5)

Fig 5. Service server decrypts key and make sure timestamp is valid.


16/28

16

Step 8: The client decrypts the ticket. If the keys are still valid, communication is

initiated between client and server. (Fig 6)

Fig 6. For valid keys communication is initiated.

After the communication is made between the client and server, no further need of

transmitting logon information is needed. The client is authenticated until the session expires.

A. The Mutual Authentication Process

The authentication method described above seems a little one-sided. Kerberos provides

support for mutual authentication, for a more secure protection against man in the middle

attacks. This type of authentication is fairly easy to understand, since it only involves two

systems. The Steps involved in the mutual authentication process is as listed below:

Step 1: The first system creates a challenge code made up of random numbers.

Step 2: This code is sent to the second system, which generates a response to the received

code. This response and a challenge code of its own are then sent back to the first system.

Step 3: The first system verifies the response of the second system, and then sends a

response to the challenge code it received.

Step 4: When the second system receives the response, it is verified. If all is well, it notifies

the first system that they are indeed mutually authenticated.


17/28

17

This type of authentication uses challenge codes to ensure that both computers are who they

claim to be. If someone tries to intercept the data, they obviously will fail because they

cant pretend to be one of the computers after they have been authenticated with challenge

codes.


18/28

18

5. KERBEROS ENVIRONMENTA typical Kerberos environment can be divided into two main parts. On the one hand

there is the Kerberos infrastructure containing at least one Kerberos server or so called

Key Distribution Center (KDC). The KDC holds a complete database of user and service

keys. This is a serious disadvantage, because if an attacker could gain access to a Kerberos

server he learns every single key of the realm, the server is in. On the other hand there are

Kerberos-enabled clients and services called kerberized clients and services.

A. A Typical Infrastructure

As the trusted part, a Kerberos server has to be secured properly. This means, that an

attacker should not be able to gain access on the machine to get or alter the key database

stored on it. To assure that, physical access on logins should only be allowed to trusted staff

members and no other services should be placed on that host. To secure the server, virus

scanners and intrusion detection systems can be set up on it.

Usually more than one Kerberos servers are set up in a typical environment to provide an

almost error-free Kerberos service. This realm is the administrative domain. The realm is

entitled after the Internet domain name of the network, using this naming scheme, every

realm has a distinct name in a global name-space. Common environments use one realm

per institution but dividing big institutions into several realms is also possible. As one can see

in Fig 7, clients that want to access the Kerberos servers of a domain need not to be

connected to the local network. With a proper configuration, they can use Kerberos for their

realm from everywhere on the Internet.

One dedicated server per realm is holding the master copy of the Kerberos database. This

server is called the master server and any other Kerberos servers in the realm receive their

copies from this server. In case of a not responding server every client can contact the other

servers in the realm to obtain tickets. Unexpected interruptions as a result of hardware

failures can be avoided this way. Every client can connect to any Kerberos server he knows

in one realm.


19/28

19

Fig 7. A possible Kerberos environment.


20/28

20

B. Details of KDC

The Key Distribution Center is logically split into two services that reside on the same host.

The authentication service (AS) that authenticates users and the ticket granting service (TGS)

which takes tickets issued from the authentication service and issues tickets for services.

This is done because of a simple security reason. After authentication at the authenticationservice both KDC and client share a secret symmetric key, which can be used to construct an

authenticator for the ticket granting service to obtain service tickets by the client. There is no

need for the client to enter the password a second time and the password has not been cached

(which would be a security flaw). Both authentication service and ticket granting service

revert to the same database of keys, which resides on every Kerberos server. The database

contains every key, user keys, which are derived from the users password using a hash

algorithm and service keys that are once generated by a random number generator and

stored on the servicing host as well. To improve security this service keys should be changed

regularly.

C. Kerberized Services

To take full advantage of a Kerberos infrastructure not only authentication for local host

access is done. An optimal environment is made up of services which support Kerberos, so

that the user has to give his password one time he logs in. After that authentication the client

can read his email, access files on a file-server and log in on remote machines without giving

his password a second time.


21/28

21

6. KERBEROS DATABASEKerberos operations requiring both read-only and write access is done with the help of

Kerberos database. Operations requiring read-only access to the Kerberos database are

performed by the authentication service, which can run on both master and slavemachines. (Fig 8)

Fig 8. Authentication Request

These operations are performed by the administration service, called the Kerberos Database

Management Service (KDBM). The current implementation stipulates that changes may

only be made to the master Kerberos database; slave copies are read-only. Therefore, the

KDBM server may only run on the master Kerberos machine. (Fig 9)

Fig 9. Administrator Request

Note that, while authentication can still occur (on slaves), administration requests cannot be

serviced if the master machine is down. In our experience, this has not presented a problem,

as administration requests are infrequent.

The KDBM handles requests from users to change their passwords. The client side of this

program, which sends requests to the KDBM over the network, is the kpasswdprogram. The

KDBM also accepts requests from Kerberos administrators, who may add principals tothe database, as well as change passwords for existing principals. The client side of the


22/28

22

administration program, which also sends requests to the KDBM over the network, is the

kadmin program.

A. The KDBM Server

The KDBM server accepts requests to add principals to the database or change the passwordsfor existing principals. This service is unique in that the ticket-granting service will not issue

tickets for it. Instead, the authentication service itself must be used (the same service that

is used to get a ticket- granting ticket). The purpose of this is to require the user to enter apassword. If this were not so, then if a user left her/his workstation unattended, a passerby

could walk up and change her/his password for them, something which should be prevented.

Likewise, if an administrator left her/his workstation unguarded, a passerby could change

any password in the system.

When the KDBM server receives a request, it authorizes it by comparing the authenticated

principal name of the requester of the change to the principal name of the target of the

request. If they are the same, the request is permitted. If they are not the same, the KDBMserver consults an access control list (stored in a file on the master Kerberos system). If the

requesters principal name is found in this file, the request is permitted, otherwise it is denied.

By convention, names with a NULL instance (the default instance) do not appear in the

access control list file; instead, an admin instance is used. Therefore, for a user to become

an administrator of Kerberos an admin instance for that username must be created, and

added to the access control list. This convention allows an administrator to use a different

password for Kerberos administration then s/he would use for normal login.

All requests to the KDBM program, whether permitted or denied, are logged.

B. Database Replication

Each Kerberos realm has a master Kerberos machine, which houses the master copy of the

authentication database.It is possible (although not necessary) to have additional, read- only

copies of the database on slave machines elsewhere in the system. The advantages of

having multiple copies of the database are those usually cited for replication: higher

availability and better performance. If the master machine is down, authentication can still be

achieved on one of the slave machines. The ability to perform authentication on any one of

several machines reduces the probability of a bottleneck at the master machine.

Keeping multiple copies of the database introduces the problem of data consistency. We have

found that very simple methods suffice for dealing with inconsistency. The master database is

dumped every hour. The database is sent, in its entirety, to the slave machines, which then

update their own databases.


23/28

23

All passwords in the Kerberos database are encrypted in the master database key. Therefore,

the information passed from master to slave over the network is not useful to an

eavesdropper. However, it is essential that only information from the master host be accepted

by the slaves, and that tampering of data be detected, thus the checksum.


24/28

24

7. KERBEROS ADMINISTRATORThe Kerberos administrators job begins with running a program to initialize the database.

Another program must be run to register essential principals in the database, such as the

Kerberos administrators name with an admin instance. The Kerberos authentication server

and the administration server must be started up. If there are slave databases, theadministrator must arrange that the programs to propagate database updates from master to

slaves be kicked off periodically. After these initial steps have been taken, the administrator

manipulates the database over the network.

In particular, when a new Kerberos application is added to the system, the Kerberos

administrator must take a few steps to get it working. The server must be registered in the

database, and assigned a private key (usually this is an automatically generated random key).

Then, some data (including the servers key) must be extracted from the database and

installed in a file on the servers machine. The server uses the information in that file to

decrypt messages sent encrypted in the servers private key. The file authenticates

the server as a password typed at a terminal authenticates the user.

The Kerberos administrator must also ensure that Kerberos machines are physically secure,

and would also be wise to maintain backups of the Master database.


25/28

25

8. ANALYSIS OF KERBEROSA. Advantages

Passwords are never sent across the network unencrypted. This prevents those un-scrupulous people from being able to read the most important data sent over the

network.

Clients and applications services mutually authenticate. Mutual authentication al-lows for both ends to know that they truly know whom they are communicating with.

Tickets have a limited lifetime, so if they are stolen, unauthorized use is limited to thetime frame that the ticket is valid.

Authentication through the AS only has to happen once. This makes the security ofKerberos more convenient.

Shared secret keys between clients and services are more efficient than public-keys. Many implementations of Kerberos have a large support base and have been put

through serious testing.

Authenticators, created by clients, can only be used once. This feature prevents theuse of stolen authenticators.

B. Disadvantages

Kerberos only provides authentication for clients and services. Kerberos 4 uses DES, which has been shown to be vulnerable to brute-force-

attacks with little computing power.

Like any security tool, it is also vulnerable to users making poor password choices. Because Kerberos uses a mutual authentication model, it is necessary for both

client machines and service providers (servers) to be designed with Kerberos

authentication in mind.


26/28

26

9. PERSPECTIVE: PUBLIC KEY CRYPTOGRAPHY

A new direction for Kerberos is public key cryptography. Public key cryptography eases key

distribution a lot. Using only symmetric cryptography KDC and client must share a key;using asymmetric cryptography the client can present the public key, which can be used to

encrypt messages for it. This is used for email communication by the program Pretty Good

Privacy (PGP).

The big advantage for Kerberos is that the key distribution center does not have to save

the keys client keys in his database any longer. To obtain a ticket granting ticket, theclient has to present his public key. The KDC uses this key to encrypt the ticket and session

key. As everybody is able to create a key pair for public key cryptography, additional

infrastructure is needed. A trusted certification authority (CA) has to sign every valid public

key. The client can present his key which is signed by the trusted authority. Integration in

Kerberos is easy due to the fact that only interaction with the authentication service has to be

changed to use asymmetric cryptography; everything else can remain as it is. If the clientpresents his public key, the authentication service checks, whether it has a valid signature

from a trusted authority and return a session key afterwards. The client decrypts the session

key with the private key of his key pair. Following communication is handled like in

Kerberos without public key cryptography support.


27/28

27

10.CONCLUSIONKerberos isnt the only encryption protocol available. There are multiple ways to encrypt

data, and this holds true for many types of different applications. Email encryption protocols,

for example, are a breed all of their own.

With a product that has been researched and developed for over 8 years, it is generally

expected that the product should be well polished. Kerberos doesnt fail to deliver, and this

can be seen by looking at all the vendors who use it. Cisco, Microsoft, Apple, and many

others rely on this faithful three- headed dog for network security.

Authentication is critical for the security of computer systems. Without knowledge of the

identity of a principal requesting an operation, it's difficult to decide whether the operation

should be allowed. Traditional authentication methods are not suitable for use in computer

networks where attackers monitor network traffic to intercept passwords. The use of strong

authentication methods that do not disclose passwords is imperative. The Kerberos

authentication system is well suited for authentication of users in such environments.


28/28

11.REFERENCES[1] http://web.mit.edu/Kerberos/

[2] http://www.kerberos.org/software/tutorial.html

[3] http://www.zeroshell.net/eng/kerberos/Kerberos-aims/

[4]http://www.cisco.com/en/US/tech/tk59/technologies_white_paper0

9186a00800941b2.shtml#intro

[5] http://en.wikipedia.org/wiki/Kerberos_(protocol)

[6] http://learn-networking.com/network-security/how-kerberos- authentication-works

[7] http://www.networkcomputing.com/netdesign/kerb7.html

[8] http://www.cs.ucl.ac.uk/staff/B.Karp/gz03/f2008/kerberos.pdf

[9]http://searchsecurity.techtarget.com/sDefinition/0..sid14_gci21243700.html

[10]http://www.rsa.com/rsalabs/node.asp?id=2297

[11]http://docs.sun.com/app/docs/doc/816-4557/intro-5?a=view

[12] http://w3.darkwhole.de/~tf/uni/kerberos_paper.pdf

[13] Distributed Systems- Concepts and Design by George Coulouris, 4e, Pearson Education
http://web.mit.edu/Kerberos/http://www.kerberos.org/software/tutorial.htmlhttp://www.zeroshell.net/eng/kerberos/Kerberos-aims/http://www.cisco.com/en/US/tech/tk59/technologies_white_paper09186a00800941b2.shtml#introhttp://www.cisco.com/en/US/tech/tk59/technologies_white_paper09186a00800941b2.shtml#introhttp://www.cisco.com/en/US/tech/tk59/technologies_white_paper09186a00800941b2.shtml#introhttp://en.wikipedia.org/wiki/Kerberos_(protocol)http://learn-networking.com/network-security/how-kerberos-authentication-workshttp://www.networkcomputing.com/netdesign/kerb7.htmlhttp://www.cs.ucl.ac.uk/staff/B.Karp/gz03/f2008/kerberos.pdfhttp://searchsecurity.techtarget.com/sDefinition/0..sid14_gci21243700http://searchsecurity.techtarget.com/sDefinition/0..sid14_gci21243700http://searchsecurity.techtarget.com/sDefinition/0..sid14_gci21243700http://www.rsa.com/rsalabs/node.asp?id=2297http://www.rsa.com/rsalabs/node.asp?id=2297http://docs.sun.com/app/docs/doc/816-4557/intro-5?a=viewhttp://docs.sun.com/app/docs/doc/816-4557/intro-5?a=viewhttp://w3.darkwhole.de/~tf/uni/kerberos_paper.pdfhttp://w3.darkwhole.de/~tf/uni/kerberos_paper.pdfhttp://docs.sun.com/app/docs/doc/816-4557/intro-5?a=viewhttp://docs.sun.com/app/docs/doc/816-4557/intro-5?a=viewhttp://www.rsa.com/rsalabs/node.asp?id=2297http://searchsecurity.techtarget.com/sDefinition/0..sid14_gci21243700http://www.cs.ucl.ac.uk/staff/B.Karp/gz03/f2008/kerberos.pdfhttp://www.networkcomputing.com/netdesign/kerb7.htmlhttp://learn-networking.com/network-security/how-kerberos-authentication-workshttp://learn-networking.com/network-security/how-kerberos-authentication-workshttp://en.wikipedia.org/wiki/Kerberos_(protocol)http://www.cisco.com/en/US/tech/tk59/technologies_white_paper09186a00800941b2.shtml#introhttp://www.cisco.com/en/US/tech/tk59/technologies_white_paper09186a00800941b2.shtml#introhttp://www.zeroshell.net/eng/kerberos/Kerberos-aims/http://www.kerberos.org/software/tutorial.htmlhttp://web.mit.edu/Kerberos/

report on kerberos

Documents