Upload
imane-oubalid
View
236
Download
3
Embed Size (px)
Citation preview
7/28/2019 24018536 Kerberos Seminar Report
1/29
KerberosDepartment of Computer Science
Mahatma Gandhi College of Engineering
Vandithadam, Thiruvananthapuram, India
Abstract - In an open network computing environment, aworkstation cannot be trusted to identify its users correctly to
network services. Kerberos provides an alternative approach
whereby a trusted 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 allowsnodes 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
authentication both 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 strong cryptography over the network to help
user secure his information systems across the entire enterprise.
I. INTRODUCTION
Computer security has been a problem since the verybeginning. Proper authentication and protection using
cryptographic methods is a must in todays electroniccommunication. 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. Theproject, 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 oneof these terminals. As soon as the terminals and old computers
were substituted by newer workstations with networkconnection, the projects goal was to allow any user to sit
down at the workstation of his or her choice accessing his dataover the network (which is a very common scenario for every
network today). The problem of network eavesdroppingbecame 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 whichwere lacking even fundamental internal security. To protect
the users data in the network environment as it had beenprotected in the timesharing environment Kerberos was
invented. Kerberos is an authentication system that usessymmetric 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 logsin. The user decrypts the ticket and uses it to obtain tickets for
other network services he or she wants to use. Because allinformation in tickets is encrypted, it is not susceptible to
eavesdropping or misappropriation.
MIT developed Kerberos to protect network services
provided by Project Athena. The protocol was named after theGreek mythological character Kerberos (or Cerberus), known
in Greek mythology as being the monstrous three-headedguard dog of Hades.
B. Motivation
In a network of users requiring services from manyseparate computers, there are three approaches one can take to
access control: One can do nothing, relying on the machine towhich the user is logged in to prevent unauthorized access;
one can require the host to prove its identity, but trust thehosts 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 thenetwork, 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 Internetaddress from which a connection has been established.
In the Athena environment, we must be able to honor
requests from hosts that are not under organizational control.
7/28/2019 24018536 Kerberos Seminar Report
2/29
Users have complete control of their workstations: they can
reboot them, bring them up standalone, or even boot off theirown 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 tophysically secure the host running a network server; someone
elsewhere on the network may be masquerading as the givenserver.
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 theweak link. Someone watching the network should not be able
to obtain the information necessary to impersonate anotheruser. Second, it must be reliable. Access to many services will
depend on the authentication service. If it is not reliable, thesystem of services as a whole will not be. Third, it should be
transparent. Ideally, the user should not be aware ofauthentication 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 notbreak if they did.
Kerberos is the result of our work to satisfy the aboverequirements. When a user walks up to a workstation she/he
logs in. As far as the user can tell, this initial identificationis sufficient to prove her/his identity to all the required
network servers for the duration of the login session. Thesecurity of Kerberos relies on the security of several
authentication servers, but not on the system from which userslog 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 scatteredacross the network.
II. KERBEROS
Kerberos is a computer network authentication protocol,which allows nodes communicating over a non-secure
network to prove their identity to one another in a securemanner. The Kerberos protocol is designed to provide reliable
authentication over open and insecure networks wherecommunications between the hosts belonging to it may be
intercepted. However, one should be aware that Kerberos does
not provide any guarantees if the computers being used arevulnerable: the authentication servers, application servers andclients must be kept constantly updated so that the authenticity
of the requesting users and service providers can beguaranteed. Thus we can say that: "Kerberos is an
authentication protocol for trusted hosts on untrustednetworks".
Kerberos is a trusted third-party authentication service
based on the model presented by Needham and Schroeder. Itis trusted in the sense that each of its clients believes
Kerberos judgement as to the identity of each of its other
clients to be accurate. Timestamps (large numbersrepresenting 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 authenticationservice and five step message chain. In the very first step the
client requests a session key for communication with a certainservice. The requested session key and a message encrypted
for the service is send back to the client encrypted with theclients 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 servicegenerates 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 serverencrypted with the session key as well to prove that A was the
sender of message number three. After performing these fivesteps the service can be sure that the client has authenticated
itself correctly, because only the client knows the key todecrypt message two.
This protocol is no longer considered secure as B does notknow 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 mentionedabove. Due to the fact that it is a problem to keep all clocks
returning exact the same time in a network environment, everymessage is valid in a time window from five minutes in the
past to five minutes in the future. In a short time slot of ten
minutes length replay attacks are impeded by a replay cacheheld 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.
III. TERMINOLOGY
This section provides the definition of the objects and
terms, knowledge of which is essential for the subsequentdescription of the Kerberos protocol.
A.Realm
7/28/2019 24018536 Kerberos Seminar Report
3/29
The term realm indicates an authentication administrative
domain. Its intention is to establish the boundaries withinwhich 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 mustbelong 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 ifhe/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 adifference between upper and lower case letters, but normally
realms always appear in upper case letters. It is also goodpractice, in an organization, to make the realm name the same
as the DNS domain (in upper case letters though). Followingthese tips when selecting the realm name significantly
simplifies the configuration of Kerberos clients, above all
when it is desired to establish trust relationships withsubdomains. 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 theauthentication server database. A principal is associated with
each user, host or service of a given realm. A principal inKerberos 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 ofprincipals referred to users:
[email protected]/[email protected]
pluto/[email protected]
If, instead, the entries refer to services, the principals assumethe 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. Ticketsare 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 serverand the server providing the service, not even the client which
requested the ticket can know it or change its contents. Themain information contained in a ticket includes:
The requesting user's principal (generally the
username);
The principal of the service it is intended for;
The IP address of the client machine from which theticket can be used. In Kerberos 5 this field is optional
and may also be multiple in order to be able to runclients under NAT or multihomed.
The date and time (in timestamp format) when the
tickets validity commences;
The ticket's maximum lifetime
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 anycontrol over an already issued ticket. Even though the realm
administrator can prevent the issuing of new tickets for acertain user at any time, it cannot prevent users from using the
tickets they already possess. This is the reason for limiting thelifetime 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 thatKerberos uses only symmetrical key encryption (in otherwords the same key is used to encrypt and decrypt).
1) Encryption type
Kerberos 4 implements a single type of encryption whichis 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 thenumber or type of encryption methodologies supported. It is
the task of each specific implementation to support and bestnegotiate the various types of encryption. However, this
flexibility and expandability of the protocol has accentuatedinteroperability problems between the various
implementations of Kerberos 5. In order for clients andapplication and authentication servers using different
implementations to interoperate, they must have at least oneencryption type in common. The difficulty related to the
interoperability between UNIX implementations of Kerberos5 and the one present in the Active Directory of Windows is a
classic example of this. Indeed, Windows Active Directory
7/28/2019 24018536 Kerberos Seminar Report
4/29
supports a limited number of encryptions and only had DES at
56 bits in common with UNIX. This required keeping thelatter enabled, despite the risks being well known, if
interoperability had to be guaranteed. The problem was
subsequently solved with version 1.3 of MIT Kerberos 5. Thisversion introduced RC4-HMAC support, which is also present
in Windows and is more secure than DES. Among thesupported encryptions (but not by Windows) the triple DES
(3DES) and newer AES128 and AES256 are worthmentioning.
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 itsunencrypted 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 adifferent 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. Thisfunction 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 the password which generated it (unless bybrute force). Famous hashing algorithms are MD5 and
CRC32.
3) Salt
In Kerberos 5, unlike version 4, the concept of passwordsalt has been introduced. This is a string to be concatenated to
the unencrypted password before applying the string2keyfunction to obtain the key. Kerberos 5 uses the same principal
of the user as salt:
Kmark = string2key (Pmark + "[email protected]")
Kmark is the encryption key of the user mark and P mark is 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. Forexample, imagine an administrator having a principal for
everyday work ([email protected]) and one for
administrative work (mark/[email protected]). It isvery 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 bothrealms: 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 withKerberos 4. Vice versa, for compatibility with AFS, it is
possible to configure a salt which is not the complete name ofthe principal, but simply the name of the cell.
4) Key Version Number (kvno)
When a user changes a password or an administrator
updates the secret key for an application server, this change islogged by advancing a counter. The current value of the
counter identifying the key version is known as the KeyVersion Number or more briefly kvno.
E. Key Distribution Center (KDC)
The authentication server in a Kerberos environment,
based on its ticket distribution function for access to theservices, is called Key Distribution Center or more briefly
KDC. Since it resides entirely on a single physical server (itoften coincides with a single process) it can be logically
considered divided into three parts: Database, AuthenticationServer (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 isused 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 ticketassociated to the principal;
The maximum time a ticket associated to the
principal may be renewed (only Kerberos 5);
7/28/2019 24018536 Kerberos Seminar Report
5/29
The attributes or flags characterizing the behavior of
the tickets;
The password expiration date;
The expiration date of the principal, after which notickets will be issued.
In order to make it more difficult to steal the keys present
in the database, the implementations encrypt the databaseusing the master key, which is associated with the principal
K/M@REALM. Even any database dumps, used as backupsor for propagation from the KDC master towards the slave,
are encrypted using this key, which it is necessary to know inorder 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 aspecial ticket known as the Ticket Granting Ticket, or more
briefly TGT, the principal associated with which iskrbtgt/REALM@REALM. If the users are actually who they
say they are they can use the TGT to obtain other servicetickets, without having to re-enter their password.
3) Ticket Granting Server (TGS)
The Ticket Granting Server is the KDC component whichdistributes service tickets to clients with a valid TGT,
guaranteeing the authenticity of the identity for obtaining the
requested resource on the application servers. The TGS can beconsidered as an application server (given that to access it, it
is necessary to present the TGT) which provides the issuing ofservice tickets as a service. It is important not to confuse the
abbreviations TGT and TGS: the first indicates a ticket andthe 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 theirpassword, 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 awork session open on a server: this key, generated by the
KDC when a ticket is issued, is called the Session Key. Thecopy 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), whilethe copy intended for the user is 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 theapplication server can extract and possibly manage such
information (since the ticket is encrypted with the secret keyof the service), this is not enough to guarantee the authenticity
of the client. An impostor could capture (remember thehypothesis of an open and insecure network) the ticket when it
is sent by a legitimate client to the application server, and atan opportune time, send it to illegitimately obtain the service.
On the other hand, including the IP addresses of the machinefrom 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 havethe 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 (theauthenticator) 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
unencrypt the authenticator extracting the timestamp. If thelatter differs from the server time by less than 2 minutes (but
the tolerance can be configured) then the authentication is
successful. This underlines the criticality of synchronizationbetween machines belonging to the same realm.
Credential
H. Replay Cache
The possibility exists for an impostor to simultaneouslysteal both the ticket and the authenticator and use them during
the 2 minutes the authenticator is valid. This is very difficult
7/28/2019 24018536 Kerberos Seminar Report
6/29
but not impossible. To solve this problem with Kerberos 5,
Replay Cache has been introduced. In application servers (butalso in TGS), there exists the capacity to remember
authenticators which have arrived within the last 2 minutes,
and to reject them if they are replicas. With this the problem isresolved as long as the impostor is not smart enough to copy
the ticket and authenticator and make them arrive at theapplication server before the legitimate request arrives. This
really would be a hoax, since the authentic user would berejected 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 theuser 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 "CredentialCache". Where this cache needs to be located does not depend
on the protocol, but varies from one implementation toanother. 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 vulnerable clients, the credential cache is placedin an area of the memory accessible only to kernels and not
swappable on the disk.
IV. WORKING
Kerberos operates by encrypting data with a symmetric key.
A symmetric key is a type of authentication where both theclient and server agree to use a single encryption/decryption
key for sending or receiving data. When working with theencryption key, the details are actually sent to a key
distribution center, or KDC, instead of sending the detailsdirectly between each computer. The entire process takes a
total of eight steps:
Step 1: The authentication service, or AS, receives the requestby the client and verifies that the client is indeed the computer
it claims to be. This is usually just a simple database lookup ofthe 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 date of 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. (This is
used to make sure a hacker doesnt intercept the data, and tryto crack the key. Almost all keys are able to be cracked, but itwill take a lot longer than 8 hours to do so.)
Step 3: The key is sent back to the client in the form of aticket-granting ticket, or TGT. This is a simple ticket that is
issued by the authentication service. It is used forauthenticating the client for future reference. (Fig 2)
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)
7/28/2019 24018536 Kerberos Seminar Report
7/29
Fig 3.Client submits TGT to TGS.
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.
Step 7: Theservice decrypts the key, and makes sure thetimestamp is still valid. If it is, the service contacts the key
distribution center to receive a session that is returned to the
client. (Fig 5)
Step 8: The client decrypts the ticket. If the keys are still
valid, communication is initiated between client and server.(Fig 6)
Fig 5. Service server decrypts key and make sure timestamp is valid.
Fig 6. For valid keys communication is initiated.
7/28/2019 24018536 Kerberos Seminar Report
8/29
After the communication is made between the client and
server, no further need of transmitting logon information isneeded. The client is authenticated until the session expires.
A. The Mutual Authentication Process
The authentication method described above seems a littleone-sided. Kerberos provides support for mutualauthentication, for a more secure protection against man in the
middle attacks. This type of authentication is fairly easy tounderstand, since it only involves two systems. The Steps
involved in the mutual authentication process is as listedbelow:
Step 1: The first system creates a challenge code made up ofrandom numbers.
Step 2: This code is sent to the second system, whichgenerates a response to the received code. This response and a
challenge code of its own are then sent back to the firstsystem.
Step 3: The first system verifies the response of the secondsystem, 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 areindeed mutually authenticated.
This type of authentication uses challenge codes to ensurethat both computers are who they claim to be. If someone tries
to intercept the data, they obviously will fail because theycant pretend to be one of the computers after they have been
authenticated with challenge codes.
V. KERBEROS ENVIRONMENT
A 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 socalled 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 aKerberos server he learns every single key of the realm, the
server is in. On the other hand there are Kerberos-enabledclients 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 togain 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 servicesshould 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 server are set up in a
typical environment to provide an almost error-free Kerberosservice. This realm is the administrative domain. The realm is
entitled after the Internet domain name of the network, usingthis naming scheme, every realm has a distinct name in a
global name-space. Common environments use one realm perinstitution but dividing big institutions into several realms is
also possible. As one can see in Fig 7, clients that want toaccess 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 copyof 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 respondingserver 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 canconnect to any Kerberos server he knows in one realm.
Fig 7. A possible Kerberos environment
B. Details of KDC
The Key Distribution Center is logically split into twoservices that reside on the same host. The authentication
service (AS) that authenticates users and the ticket grantingservice (TGS) which takes tickets issued from the
authentication service and issues tickets for services. This isdone because of a simple security reason. After authentication
at the authentication service both KDC and client share asecret symmetric key, which can be used to construct an
authenticator for the ticket granting service to obtain servicetickets by the client. There is no need for the client to enter the
7/28/2019 24018536 Kerberos Seminar Report
9/29
password a second time and the password has not been cached
(which would be a security flaw). Both authentication serviceand 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 theusers password using a hash algorithm and service keys that
are once generated by a random number generator and storedon 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 onlyauthentication 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, accessfiles on a file-server and log in on remote machines without
giving his password a second time.
VI. KERBEROS DATABASE
Kerberos operations requiring both read-only and write accessis done with the help of Kerberos database. Operations
requiring read-only access to the Kerberos database areperformed by the authentication service, which can run on
both master and slave machines. (Fig 8)
WS WS WS
Slave Master
Fig 8. Authentication Requests.
These operations are performed by the administrationservice, called the Kerberos Database Management Service
(KDBM). The current implementation stipulates that changesmay only be made to the masterKerberos database; slave
copies are read-only. Therefore, the KDBM server may onlyrun on the masterKerberos machine. (Fig 9)
WS WS WS
Slave Master
Fig 9. Administration Requests.
Note that, while authentication can still occur (on slaves),
administration requests cannot be serviced if the mastermachine 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 sendsrequests to the KDBM over the network, is the kpasswd
program. The KDBM also accepts requests from Kerberosadministrators, who may add principals to the database, as
well as change passwords for existing principals. The clientside of the administration program, which also sends requests
to the KDBM over the network, is the kadminprogram.
A. The KDBM Server
The KDBM server accepts requests to add principals to the
database or change the passwords for existing principals. Thisservice is unique in that the ticket-granting service will notissue 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 a password. If this were not so, then if a user left her/his
workstation unattended, a passerby could walk up and changeher/his password for them, something which should be
prevented. Likewise, if an administrator left her/his
workstation unguarded, a passerby could change anypassword in the system.
When the KDBM server receives a request, it authorizes it
by comparing the authenticated principal name of therequester of the change to the principal name of the target of
the request. If they are the same, the request is permitted. Ifthey are not the same, the KDBM server consults an access
control list (stored in a file on the master Kerberossystem). Ifthe requesters principal name is found in this file, the request
is permitted, otherwise it is denied.
By convention, names with a NULL instance (the defaultinstance) do not appear inthe access control list file; instead,
an admin instance is used. Therefore, for a user to become anadministrator 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 differentpassword for Kerberosadministration then s/he would use for
normallogin.
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.
7/28/2019 24018536 Kerberos Seminar Report
10/29
It is possible(although not necessary) to have additional,read-
only copies of the database on slave machines elsewhere inthe system. The advantagesof having multiple copies of the
database are those usually cited for replication: higher
availability and better performance. If the mastermachine isdown, authentication can still beachieved on one of the slave
machines. The abilityto perform authentication on any one ofseveral machines reduces the probability of abottleneck at the
master machine.
Keeping multiple copies of the database introduces theproblem of data consistency. We have found that very simple
methods suffice for dealing with inconsistency. The masterdatabase is dumped every hour. The database is sent, in its
entirety, to the slave machines, which then update their owndatabases.
All passwords in the Kerberosdatabase are encrypted in
the master database key. Therefore, the information passedfrom 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 thattampering of data be detected, thus the checksum.
VII.KERBEROS ADMINISTRATOR
The Kerberos administrators job begins with running aprogram to initialize the database. Another program must be
run to register essential principals in the database, such as theKerberos administrators name with an admin instance. The
Kerberos authentication server and the administration servermust be started up. If there are slave databases, the
administrator must arrange that the programs to propagatedatabase updates from master to slaves be kicked off
periodically. After these initial steps have been taken, theadministrator manipulates the database over the network.
In particular, when a new Kerberosapplication is added to
the system, the Kerberos administrator must take a few stepsto get it working. The server must be registered in the
database, and assigned a private key (usually this is anautomatically generated random key). Then, some data
(including the servers key) must be extracted from thedatabase 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 fileauthenticates the server as a password typed at a terminal
authenticates the user.
The Kerberosadministrator must also ensure that Kerberos
machines are physically secure, and would also be wise tomaintain backups of the Master database.
VIII.ANALYSIS OF KERBEROS
A. Advantages
Passwords are never sent across the network
unencrypted. This prevents those unscrupulouspeople from being able to read the most important
data sent over the network.
Clients and applications services mutuallyauthenticate. Mutual authentication allows for both
ends to know that they truly know whom they arecommunicating with.
Tickets have a limited lifetime, so if they are stolen,
unauthorized use is limited to the time frame that theticket is valid.
Authentication through the AS only has to happen
once. This makes the security of Kerberos moreconvenient.
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 serioustesting.
Authenticators, created by clients, can only be used
once. This feature prevents the use of stolenauthenticators.
B. Disadvantages
o Kerberos only provides authentication for clients and
services.
o Kerberos 4 uses DES, which has been shown to be
vulnerable to brute-force-attacks with little
computing power.
o Like any security tool, it is also vulnerable to users
making poor password choices.
o Because Kerberos uses a mutual authentication
model, it is necessary for both client machines andservice providers (servers) to be designed with
Kerberos authentication in mind.
IX. 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 thepublic key, which can be used to encrypt messages for it. This
is used for email communication by the program Pretty GoodPrivacy (PGP).
The big advantage for Kerberos is that the key distributioncenter does not have to save the keys client keys in his
database any longer. To obtain a ticket granting ticket, the
7/28/2019 24018536 Kerberos Seminar Report
11/29
client has to present his public key. The KDC uses this key to
encrypt the ticket and session key. As everybody is able tocreate 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 hiskey which is signed by the trusted authority. Integration in
Kerberos is easy due to the fact that only interaction with theauthentication 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 andreturn a session key afterwards. The client decrypts the
session key with the private key of his key pair. Followingcommunication is handled like in Kerberos without public key
cryptography support.
X. CONCLUSION
Kerberos 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, forexample, 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 canbe 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 principalrequesting an operation, it's difficult to decide whether the
operation should be allowed. Traditional authenticationmethods are not suitable for use in computer networks where
attackers monitor network traffic to intercept passwords. Theuse of strong authentication methods that do not disclose
passwords is imperative. The Kerberos authentication systemis well suited for authentication of users in such environments.
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_paper09186a00800941b2.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_gci21243
7,00.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://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch19s03.html
[13] http://w3.darkwhole.de/~tf/uni/kerberos_paper.pdf[14] Distributed Systems-Concepts and Design by George Coulouris,
Jean Dollimore and Tim Kindberg, 4e,Person 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://en.wikipedia.org/wiki/Kerberos_(protocol)http://learn-networking.com/network-security/how-kerberos-authentication-workshttp://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_gci212437,00.htmlhttp://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci212437,00.htmlhttp://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://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch19s03.htmlhttp://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch19s03.htmlhttp://w3.darkwhole.de/~tf/uni/kerberos_paper.pdfhttp://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://en.wikipedia.org/wiki/Kerberos_(protocol)http://learn-networking.com/network-security/how-kerberos-authentication-workshttp://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_gci212437,00.htmlhttp://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci212437,00.htmlhttp://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://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch19s03.htmlhttp://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch19s03.htmlhttp://w3.darkwhole.de/~tf/uni/kerberos_paper.pdf7/28/2019 24018536 Kerberos Seminar Report
12/29
MATERIALS
1.Kerberos
(http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci212437,00.html)
By Steve Spence
7/28/2019 24018536 Kerberos Seminar Report
13/29
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. Briefly and approximately, here's how Kerberos works:
Suppose you want to access a server on another computer (which you may get to by sending a Telnet or similar
login request). You know that this server requires a Kerberos "ticket" before it will honor your request.
2. To get your ticket, you first request authentication from the Authentication Server (AS). The Authentication
Server creates a "session key" (which is also an encryption key) basing it on your password (which it can get from
your user name) and a random value that represents the requested service. The session key is effectively a "ticket-
granting ticket."
3. You next send your ticket-granting ticket to a ticket-granting server (TGS). The TGS may be physically the sameserver as the Authentication Server, but it's now performing a different service.The TGS returns the ticket that can
be sent to the server for the requested service.
4. The service either rejects the ticket or accepts it and performs the service.
5. Because the ticket you received from the TGS is time-stamped, it allows you to make additional requests using the
same ticket within a certain time period (typically, eight hours) without having to be reauthenticated. Making the
ticket valid for a limited time period make it less likely that someone else will be able to use it later.
The actual process is much more complicated than just described. The user procedure may vary somewhat according toimplementation.
7/28/2019 24018536 Kerberos Seminar Report
14/29
7/28/2019 24018536 Kerberos Seminar Report
15/29
3.Kerberos Service - System Administration Guide: Security Services
(http://docs.sun.com/app/docs/doc/816-4557/intro-5?a=view)
The Kerberos service is a client-server architecture that provides secure transactions over networks. The service offersstrong user authentication, as well as integrity and privacy. Authentication guarantees that the identities of both the sender and
the recipient of a network transaction are true. The service can also verify the validity of data being passed back and forth
(integrity) and encrypt the data during transmission (privacy). Using the Kerberos service, you can log in to other machines,
execute commands, exchange data, and transfer files securely. Additionally, the service provides authorization services, which
allows administrators to restrict access to services and machines. Moreover, as a Kerberos user, you can regulate other people's
access to your account.
The Kerberos service is a single-sign-on system, which means that you only need to authenticate yourself to the service
once per session, and all subsequent transactions during the session are automatically secured. After the service has
authenticated you, you do not need to authenticate yourself every time you use a Kerberos-based command such as ftp or rsh, or
to access data on an NFS file system. Thus, you do not have to send your password over the network, where it can be
intercepted, each time you use these services.
The Solaris Kerberos service is based on the Kerberos V5 network authentication protocol that was developed at the
Massachusetts Institute of Technology (MIT). People who have used Kerberos V5 product should therefore find the Solaris
version very familiar. Because the Kerberos V5 protocol is a de facto industry standard for network security, the Solaris version
promotes interoperability with other systems. In other words, because the Solaris Kerberos service works with systems that use
the Kerberos V5 protocol, the service allows for secure transactions even over heterogeneous networks. Moreover, the service
provides authentication and security both between domains and within a single domain.
The Kerberos service allows for flexibility in running Solaris applications. You can configure the service to allow both
Kerberos-based and non-Kerberos-based requests for network services such as the NFS service, telnet, and ftp. As a result,
current Solaris applications still work even if they are running on systems on which the Kerberos service is not enabled. Ofcourse, you can also configure the Kerberos service to allow only Kerberos-based network requests.
The Kerberos service provides a security mechanism which allows the use of Kerberos for authentication, integrity,
and privacy when using applications that use the Generic Security Service Application Programming Interface (GSS-API).
However, applications do not have to remain committed to the Kerberos service if other security mechanisms are developed.
Because the service is designed to integrate modularly into the GSS-API, applications that use the GSS-API can utilize
whichever security mechanism best suits their needs.
7/28/2019 24018536 Kerberos Seminar Report
16/29
4.Kerberos Network Design Manual
(http://www.networkcomputing.com/netdesign/kerb1.html)
By Dan Backman
Kerberos, a network security protocol developed MIT for its Athena computing environment is now a well-known, yet
not well-understood technology. Named after the guardian of the underworld in Ancient Greek mythology, Kerberos (a.k.a.:
Cerberus) uses strong encryption and a complex ticket-granting algorithm to authenticate users on a network. Also of interest to
many of users, Kerberos has the ability to distribute "session keys" to allow encrypted data streams over an IP network. Used to
secure particularly vulnerable network communications like FTP, telnet and other Internet protocols, which often transmit user
IDs and passwords in clear text, Kerberos provides the backbone for secured communications in many large networks.
Kerberos is available in many forms. However, for many organizations, it is an attractive choice as its reference
platform (published and maintained by MIT), which includes full source code. Most Kerberos distributions also include APIs
for developing new Kerberos-enabled (Kerberized) applications. While Kerberized services are best supported under Unix,
clients are available for most major desktop operating systems like DOS, Windows95, Windows NT and MacOS.
In addition to its pure form, Kerberos provides the core authentication services for computing environments such as the
Open Group's (formerly, the Open Software Foundation) DCE (Distributed Computing Environment) as well as Microsoft
Corp.'s forthcoming ADS (Active Directory Service).
In this Network Design Manual, we relate our ongoing experiences with the Kerberos protocol in our Syracuse
University labs. Although some organizations still rely on Kerberos 4, all examples and notation in this manual refer to
Kerberos 5. This version includes several modifications, such as cross-realm authentication, forwardable tickets, and internal
security enhancements, that make it the best choice for new installations. Some references to Kerberos' implementation in DCE
are included, but this Network Design Manual is not intended to cover DCE.
Network Security: The Basics
The concepts behind network security break nicely into four categories: Authentication, Authorization (a.k.a. Access
Control), Accounting, and Secure Communications.
7/28/2019 24018536 Kerberos Seminar Report
17/29
Authentication: This is simple verification of a user's identity. Always based on some form of trust, authentication relies on
something that the user has, which can be compared to a known constant (the trusted value). This can occur either in an
interaction with the user (a user ID and password are entered), or can range up to complex biometrics systems like fingerprint
identification, face recognition or retinal scans. Authentication also can occur by proxy, such as a stored authentication token
(kept in a workstation's memory while the user remains logged in, o r on a token such as a smartcard).
Authorization: Also known as access control, this form of security decides who is allowed where. File permissions are a good
example of access controls. Usually stored in resource-level ACLs (access control lists), these are simply lists of authenticated
users (or groups of users) who are allowed to access or are barred from accessing a given resource. This is usually the most
complex aspect of network security since it requires the secure, centralized storage and access of these ACLs. Authorization can
occur only once a user is authenticated, as authorization systems rely on lists of authenticated users.
Accounting: The basic task of recording who accessed what resource. Most network operating systems and services include
some form of logging. This can either be performed independently at each service, or through a centralized accounting server.However, if performed centrally, all accounting information must be transferred securely, and can be affected by denial of
service attacks (for instance, a hacker wishing to cover his tracks could prevent logging messages from reaching the accounting
server).
Secure communications: The ability to protect network transmissions from both interception (where private information can be
compromised) as well as unauthorized transmission, where a hacker can masquerade as a secure host, or can insert data into an
established connection.
Kerberos is not a complete network security solution. While it does provide powerful tools to enable networkwide user
authentication and secure communications, it has no provisions for access control or accounting. The designers of Kerberos felt
that it should function as part of a larger network environment, where access control is best left up to individual applications or
a dedicated access control manager. Although the Kerberos server itself includes a minimal ACL to specify users authorized to
change the Kerberos database, no other authorization system is pr ovided. Likewise, as the actual authentication process occurs
on the workstation, the Kerberos server doesn't concern itself with who is successfully authenticated. While the KDC (Kerberos
server) does keep track of which tickets were issued, it provides more of a debugging function than an audit trail.
7/28/2019 24018536 Kerberos Seminar Report
18/29
5.Kerberos configuration as an authentication system for single sign-on
(http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1353067,00.html)
By David Griffeth
7/28/2019 24018536 Kerberos Seminar Report
19/29
Most of us have heard of the Kerberos network authentication protocol, but what is it? What is its roll in an identity
and access management (IAM) program, and how can it be leveraged for access control initiatives like single sign-on (SSO) and
custom application authentication?
Designed to provide strong authentication for client/server applications by using secret-key cryptography, Kerberos
defines a typical key-exchange mechanism; it's a way of proving an identity to a system (the Kerberos server) and having that
system then authenticate the identity to other systems for the duration of the session. It is well suited for authentication on
physically insecure networks.
Features of Kerberos
Kerberos offers several important features, such as providing a secure, reliable means of authentication, authenticating
to multiple applications in a way that is transparent to the user, and accommodating any organization by way of a scalability
model. It is a mature and industry-accepted protocol that can support cryptography as well.
These features entail more robust controls to prevent eavesdropping and malicious attacks on the network, a friendlier
end-user experience, and the ability to expand use of the protocol to a broad spectrum of applications. It also prevents
unauthorized reading of communications through encryption.
Each application that is setup to use Kerberos trusts the Kerberos server to authenticate the user, so the user isn't asked
for a username and password on each application. Kerberos provides secure communication between two parties by
manufacturing secret keys on an open network and providing a mechanism for those keys to be securely communicated to the
appropriate parties.
Because single sign-on relies on a centralized and trusted authentication mechanism, Kerberos is a natural fit. A well-
designed implementation should have a means of confidently authenticating users to the Kerberos server and communicating
those credentials securely to all applications participating in the Kerberos implementation.
Implementing single sign-on with Kerberos across core applications and intranet sites in an enterprise can also offer huge
cost savings in several ways:
Custom applications can leverage the enterprise Kerberos single sign-on system to authenticate users, reducing
development time.
Password-reset requests will drop dramatically if users are only required to remember one set of credentials.
Access management is simplified by providing a single point to terminate access. (This means fewer hours required to
manage the account through its life cycle.)
Kerberos is a non-proprietary technology, so it supports interoperability of multiple vendors' products, from Apple Inc.
to IBM.
Businesses tend to have several enterprise-wide applications that fulfill distinct business needs. With their own processes,
GUIs, databases, business abstraction layers, Web servers, etc., the structures of these applications may inhibit them from
leveraging existing authentication mechanisms like Active Directory or TopSecret. Implementing Kerberos single sign-on
across these various applications means that users who access more than one of them can now authenticate once and aren't
asked for separate credentials for each application.
7/28/2019 24018536 Kerberos Seminar Report
20/29
Kerberos: Drawbacks and limitations
There are limitations to Kerberos that should be considered and understood before implementation. For instance,
Kerberos does not provide authorization or accounting, although it is possible for applications to use their secret keys to perform
those functions securely.
There are also concerns about centralizing all of the application passwords on one system. If an attacker gains root
access to a Kerberos server, he or she will have access to the database of encrypted passwords of the applications leveragingKerberos. If the Kerberos server is compromised, the attacker could also modify the Kerberos software and configuration files
to make the system perform authentications that should not otherwise be successful.
There are also two different distributions and versions of Kerberos available: Versions 4 and 5. Version 5 (v5) is the
newest, introduced in 1995. There are several distributions of it, including a freeware version from MIT as well as a
commercially available distribution from the Open Group called OSF DCE (Distributed Computing Environment) Security.
Be aware that v4 and v5 are completely different protocols and are not compatible. Different distributions don't always
implement together well either. There may be tweaks and customization required if the company chooses to run multiple
distributions in the same organization. I strongly recommend against this because the support issues involved may be
problematic.
Where to use Kerberos
Kerberos should be considered if an organization is looking for a mature means of authenticating users to multiple
applications across a variety of technologies.
It is also worth considering if a company has a Web presence that directs end users to a portal with several different
applications providing underlying functionality. A bank is a great example of this: users could have a combination of a checking
account, a savings account, an IRA or a mortgage from the same bank. It would be a much better user experience to have a
single set of credentials for conducting business than to log in to each of these accounts separately.
Kerberos is intended to help enable centralized authentication to simplify the user experience and the system
administrators' account management process. It can be a useful technology and is worth examining by any organization
exploring single sign-on systems.
6.Network Authentication Kerberos
(http://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch19s03.html)
7/28/2019 24018536 Kerberos Seminar Report
21/29
An open network provides no means to ensure that a workstation can identify its users properly except the usual
password mechanisms. In common installations, the user must enter the password each time a service inside the network is
accessed. Kerberos provides an authentication method with which a user must register once and is then trusted in the complete
network for the rest of the session. To have a secure network, the following requirements must be met:
Have all users prove their identity for each desired service and make sure no one can take the identity of someone else.
Make sure each network server also proves its identity. If you do not, an attacker might be able to impersonate the
server and obtain sensitive information transmitted to the server. This concept is called mutual authentication, because
the client authenticates to the server and vice versa.
Kerberos helps you meet the above requirements by providing strongly encrypted authentication. The following shows
how this is achieved. Only the basic principles of Kerberos are discussed here. For detailed technical instruction, refer to the
documentation provided with your implementation of Kerberos.
Kerberos Terminology
The following glossary defines some Kerberos terminology.
1. Credential
Users or clients need to present some kind of credentials that authorize them to request services. Kerberos knows two
kinds of credentials tickets and authenticators.
2. Ticket
A ticket is a per-server credential used by a client to authenticate at a server from which it is requesting a service. It
contains the name of the server, the client's name, the client's Internet address, a time stamp, a lifetime, and a random session
key. All this data is encrypted using the server's key.
3. Authenticator
Combined with the ticket, an authenticator is used to prove that the client presenting a ticket is really the one it claims
to be. An authenticator is built of the client's name, the workstation's IP address, and the current workstation's time all encrypted
with the session key only known to the client and the server from which it is requesting a service. An authenticator can only be
used once, unlike a ticket. A client can build an authenticator itself.
4. Principal
A Kerberos principal is a unique entity (a user or service) to which it can assign a ticket. A principal consists of the
following components:
primary the first part of the principal, which can be the same as your user name in the case of a user.
instance some optional information characterizing the primary. This string is separated from the primary by a /.
realm this specifies your Kerberos realm. Normally, your realm is your domain name in uppercase letters.
5. Mutual authentication
7/28/2019 24018536 Kerberos Seminar Report
22/29
Kerberos ensures that both client and server can be sure of each others identity. They share a (session) key, which they
can use to communicate securely.
6. Session key
Session keys are temporary private keys generated by Kerberos. They are known to the client and used to encrypt the
communication between the client and the server for which it requested and received a ticket.
7. Replay
Almost all messages sent in a network can be eavesdropped, stolen, and resent. In the Kerberos context, this would be
most dangerous if an attacker manages to obtain your request for a service containing your ticket and authenticator. He could
then try to resend it (replay) to impersonate you. However, Kerberos implements several mechanisms to deal with that problem.
8. Server or Service
Service is used to refer to a specific action to perform. The process behind this action is referred to as a server.
How Kerberos Works
Kerberos is often called a third party trusted authentication service, which means all its clients trust Kerberos'sjudgment of another client's identity. Kerberos keeps a database of all its users and their private keys.
To ensure Kerberos is worth all the trust put in it, run both the authentication and ticket-granting server on a dedicated
machine. Make sure only the administrator can access this machine physically and over the network. Reduce the (networking)
services run on it to the absolute minimum do not even run sshd.
First contact
Your first contact with Kerberos is quite similar to any login procedure at a normal networking system. Enter your user
name. This piece of information and the name of the ticket-granting service are sent to the authentication server (Kerberos). If
the authentication server knows about your existence, it will generate a (random) session key for further use between your client
and the ticket-granting server. Now the authentication server prepares a ticket for the ticket-granting server. The ticket contains
the following information all encrypted with a session key only the authentication server and the ticket-granting server know:
the names both of the client and the ticket-granting server
the current time
a lifetime assigned to this ticket
the client's IP address
the newly-generated session key
This ticket is then sent back to the client together with the session key, again in encrypted form, but this time the
private key of the client is used. This private key is only known to Kerberos and the client, because it is derived from your user
password. Now that the client has received this response, you are prompted for your password. This password is converted into
the key that can decrypt the package sent by the authentication server. The package is unwrapped and password and key are
erased from the workstation's memory. As long as the lifetime given to the ticket used to obtain other tickets does not expire,
your workstation can prove your identity.
Requesting a service
7/28/2019 24018536 Kerberos Seminar Report
23/29
To request a service from any server in the network, the client application needs to prove its identity to the server.
Therefore, the application generates an authenticator. An authenticator consists of the following components:
the client's principal
the client's IP address
the current time
a checksum (chosen by the client)
All this information is encrypted using the session key that the client has already received for this special server. The
authenticator and the ticket for the server are sent to the server. The server uses its copy of the session key to decrypt the
authenticator, which gives him all information needed about the client requesting its service to compare it to that contained in
the ticket. The server checks if the ticket and the authenticator originate from the same client.
Without any security measures implemented on the server side, this stage of the process would be an ideal target
forreplay attacks. Someone could try to resend a request stolen off the net some time before. To prevent this, the server will not
accept any request with a time stamp and ticket received previously. In addition to that, a request with a time stamp differing too
much from the time the request is received can be ignored.
Mutual authentication
Kerberos authentication can be used in both directions. It is not only a question of the client being the one it claims to
be. The server should also be able to authenticate itself to the client requesting its service. Therefore, it sends some kind of
authenticator itself. It adds one to the checksum it received in the client's authenticator and encrypts it with the session key,
which is shared between it and the client. The client takes this response as a proof of the server's authenticity and they both start
cooperating.
Ticket-granting getting into contact with all servers
Tickets are designed to be used for one server at a time. This implies that you have to get a new ticket each time yourequest another service. Kerberos implements a mechanism to obtain tickets for individual servers. This service is called the
ticket-granting service. The ticket-granting service is a service just like any other service mentioned before, so uses the same
access protocols that have already been outlined. Any time an application needs a ticket that has not already been requested, it
contacts the ticket-granting server. This request consists of the following components:
the requested principal
the ticket-granting ticket
an authenticator
Like any other server, the ticket-granting server now checks the ticket-granting ticket and the authenticator. If they areconsidered valid, the ticket-granting server builds a new session key to be used between the original client and the new server.
Then the ticket for the new server is built, containing the following information:
the client's principal
the server's principal
the current time
7/28/2019 24018536 Kerberos Seminar Report
24/29
the client's IP address
the newly-generated session key
The new ticket is assigned a lifetime, which is the lesser of the remaining lifetime of the ticket-granting ticket and the
default for the service. The client receives this ticket and the session key, which are sent by the ticket-granting service, but this
time the answer is encrypted with the session key that came with the original ticket-granting ticket. The client can decrypt the
response without requiring the user's password when a new service is contacted. Kerberos can thus acquire ticket after ticket forthe client without bothering the user more than once at login time.
7.How Kerberos Authentication Works
(http://learn-networking.com/network-security/how-kerberos-authentication-works)
You may not know it, but your network is probably unsecured right now. Anyone with the right tools could capture,
manipulate, and add data between the connections you maintain with the internet. The security cat and mouse game isnt one
sided, however. Network administrators are currently taking advantage of Kerberos to help combat security concerns.
Project Athena
Project Athena was initiated in 1983, when it was decided by the Massachusetts Institute of Technology that security in
the TCP/IP model just wasnt good enough. A total of 8 long years of research passed before Kerberos, named after the three-
headed Greek mythological dog known as Cerberus, was officially complete.
The result of MITs famous research became widely used as default authentication methods in popular operating
systems. If you are running Windows 2000 or later, you are indeed running Kerberos by default. Other operating systems such
as the Mac OS X also carry the Kerberos protocol. Kerberos isnt just limited to operating systems, however, since it is
employed by many of Ciscos routers and switches.
What Does It Protect Against, Anyways?
If you have ever used an FTP program over a network, you are at risk. If you have ever used a Telnet program over a
network, you are again at risk. These are just two examples of how little security some applications allow. FTP and Telnet use
what are called plaintext passwords, or otherwise known as cleartext passwords. These passwords are ridiculously easy to
intercept with the right tools.
Anyone with a simple packet sniffer and packet analyzer can obtain an FTP or telnet logon with ease. With that kind of
sensitive information being transmitted, the need for Kerberos is obvious. This need doesnt stop there, however. Sure FTP and
Telnet related logons are easy to intercept, but then again so is every other connection any of your applications has to the
internet.
Through a process of man in the middle attacks, any hacker can get most logon information for just about anything.From online bank passwords to private passwords on your computer, they are all generally vulnerable to this attack. A man in
the middle attack generally occurs when the hacker acts as the man in the middle between two computers. The hacker
attempts to pretend to each computer that it is in fact, the computer they have connected to. In reality, all the data is being routed
to the hacker, who can then modify or add instructions to the data.
Okay, This Sounds UsefulBut How Does It Work?
Kerberos operates by encrypting data with a symmetric key. A symmetric key is a type of authentication where both
the client and server agree to use a single encryption/decryption key for sending or receiving data. When working with the
7/28/2019 24018536 Kerberos Seminar Report
25/29
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, as shown below.
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.
2. Upon verification, a timestamp is created. This puts the current time in a user session, along with an expiration date. The
default expiration date of 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. (This is 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)
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.
7/28/2019 24018536 Kerberos Seminar Report
26/29
4. The client submits the ticket-granting ticket to the ticket-granting server, or TGS, to get authenticated.
5. The TGS creates an encrypted key with a timestamp, and grants the client a service ticket.
6. The client decrypts the ticket, tells the TGS it has done so, and then sends its own encrypted key to the service.
7/28/2019 24018536 Kerberos Seminar Report
27/29
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 session that is returned to the client.
8. The client decrypts the ticket. If the keys are still valid, communication is initiated between client and server.
Is all that back-and-forth communication really necessary? When concerning speed and reliability, it is entirely
necessary. 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.
Yet More Authentication
7/28/2019 24018536 Kerberos Seminar Report
28/29
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. Remember how the client no longer needs to
send logon information after the authentication takes place? Well it sure would ruin everything if a hacker just intercepted our
communication to the server and pretended to be us!
This type of authentication is fairly easy to understand, since it only involves two systems.
The Mutual Authentication Process
1. The first system creates a challenge code made up of random numbers.
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.
3. The first system verifies the response of the second system, and then sends a response to the challenge code it received.
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.
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.
Sounds Great! Any Drawbacks I Should Know About?
Of course, nothing is perfect. Kerberos has a couple of main flaws that system administrators need to take into
account.First and foremost is the need of the Kerberos server. This server will handle all the functions required for
authentication. If this server goes down, no one can get authenticated, and thus- the network is down. A total network crash can
be prevented by using more than one Kerberos server, but that is more costly than some people would like to think.
Next, we have the issue of clock synchronization. Since Kerberos uses timestamps to handle all activity, the clocks on
all host machines must be within 10 minutes of the Kerberos servers clock. Since not all clocks are perfect, the host clock and
server clock will eventually be misaligned enough to cause a failure. This can usually be remedied by keep clocks up to date, or
use a Network Time Protocol, or NTP.
Closing Comments
Kerberos 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.
7/28/2019 24018536 Kerberos Seminar Report
29/29
Other References
1. http://sawaal.ibibo.com/computers-and-technology/what-kerberos-authentication-protocol-240180.html
2. http://www.ibm.com/developerworks/ibm/library/it-kerbero.html
3. http://en.wikipedia.org/wiki/Kerberos_(protocol)
4. http://www.google.co.in
5. http://www.mit.edu
http://sawaal.ibibo.com/computers-and-technology/what-kerberos-authentication-protocol-240180.htmlhttp://www.ibm.com/developerworks/ibm/library/it-kerbero.htmlhttp://en.wikipedia.org/wiki/Kerberos_(protocol)http://www.google.co.in/http://sawaal.ibibo.com/computers-and-technology/what-kerberos-authentication-protocol-240180.htmlhttp://www.ibm.com/developerworks/ibm/library/it-kerbero.htmlhttp://en.wikipedia.org/wiki/Kerberos_(protocol)http://www.google.co.in/