[attachment=1977]
INTRODUCTION
Security has prime importance in the field of networking. In a small closed environment, in which all systems are owned and operated by a single organization, the security risks are less. But in a more open environment, in which network connections to other machines are supported, we need a good authentication service to protect user information and resources housed at the server. For this purpose, Kerberos is used. Kerberos is an authentication service developed at Massachusetts Institute of Technology (MIT). It provides a centralized authentication server whose function is to authenticate users to servers and servers to users.
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
OVERVIEW
Kerberos is a network authentication service developed at lusetts Institute of Technology (MIT). It Is designed to provide strong ¦ _ - - _ :5tion for client/server applications by using the secret-key cryptography. Tame Kerberos came from the Greek mythology; it is the three-headed dog ; 3rded the entrance to Hades.
. -s: as the Greek Kerberos has three heads, the modern Kerberos was intended : ~ave three components to guard a network's gate : authentication, accounting : audit. The last two heads were never implemented. A free implementation of - J protocol is available from the MIT. Kerberos is available in many commercial products as well.
The Internet is an insecure place. Many of the protocols used in the Internet do not provide any security. Tools to "sniff' passwords off of the network are in common use by systems crackers. Thus, applications which send an unencrypted password over the network are extremely vulnerable. Worse yet, other client/server applications rely on the client program to be "honest" about the identity of the user who is using it. Other applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server.
I
Department of Computer Science and Engineering SNGCE, Kadayiruppu
I _____
problems. Unfortunately, firewalls assume that "the bad guys" are on the outside, which is often a very bad assumption. Most of the really damaging incidents of computer crime are carried out by insiders. Firewalls also have a significant disadvantage in that they restrict how your users can use the Internet. In many places, these restrictions are simply unrealistic and unacceptable.
In particular the following three threats exist:
¢ A user may gain access to a particular workstation and pretend to be another user operating from that workstation.
¢ A user may alter the network address of a workstation so that the requests sent from the altered workstation appear to come from the impersonated workstation.
¢ A user may eavesdrop on exchanges and use a replay attack to gain entrance to a server to disrupt operations.
In any of these cases, an unauthorized user may be able to gain access to services and data that he or she is not authorized to access.
Kerberos was created by MIT as a solution to these network security problems. Rather than building in elaborate authentication protocols at each server, Kerberos provides a centralized authentication server whose function is to authenticate user to servers and servers to users. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server have used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business,
Kerberos is freely available from MIT, under a copyright permission
.era of Computer Science and Rngineering SNGCE, Kadayiruppu
notice. MIT provides Kerberos in source form, so that anyone who wishes to use it may look over the code for themselves and assure themselves that the code is trustworthy. In addition, for those who prefer to reiy on a professional supported product, Kerberos is available as a product from many different vendors. Two versions of Kerberos are in common use. Version 4 is the most widely used in the industry. Version 5 corrects some of the security deficiencies of version 4 and has been issued as a proposed as a proposed Internet Standard.
Motivation
If a set of users is provided with dedicated personal computers that have no network connections, then a user's resources and files can be protected by physically securing each personal computer. When these users instead are served by a centralized time-sharing system, the time sharing operating system must provide the security. The operating system can enforce access control policies based on user identity and use the logon procedure to identify users.
Today, neither of these scenarios is typical. More common is a distributed architecture consisting of dedicated user workstations (clients) and distributed or centralized servers. In this environment, three approaches to security can be envisioned :
1. Rely on each individual client workstation to assure the identity of its user or users and rely on each server to enforce a security policy based on user identification (ID).
2. Require that client systems authenticate themselves to servers, but trust the client system concerning the identity of its user.
3. Require the user to prove the identity for each service invoked. Also require that servers prove their identity to clients.
ent of Computer Science and Engineering
SNGCE, ICadayiruppu
In a small closed environment, in which all systems are owned and operated by a single organization, the first or perhaps the second strategy may suffice. But in a more open environment, in which network connections to other machines are supported, the third approach is needed to protect user information and resources housed at the server. This third approach is supported by Kerberos. Kerberos assumes a distributed client/server architecture and employs one or more Kerberos servers to provide an authentication service.
The first published report on Kerberos listed the following requirements :
Secure
A network eavesdropper should not be able to obtain the necessary information to impersonate a user. More generally, Kerberos should be strong enough that a potential opponent does not find it to be the weak link.
Reliable
For all services that rely on Kerberos for access control, lack of the availability of the Kerberos service means lack of the availability of the supported services. Hence, Kerberos should be highly reliable and should employ a distributed server architecture, with one system able to back up another.
Transparent
Ideally, the user should not be aware that authentication is taking place, beyond the requirement to enter a password.
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
c = client
AS - authentication server
V = server
IDc = identifier of user on C
IDv - identifier of V
Pc = password of user on C
ADc = network address of C
Kv = secret encryption key shared by AS and V
- concatenation
In this scenario, the user log on to a workstation and requests access to server V. The client module C in the user's workstation requests the user's password and then sends a message to the AS that includes the user's ID, the server's ID, and the user's password. The AS checks its database to see if the user has supplied the proper password for this user ID and whether this user is permitted access to server V. If both tests are passed, the AS accepts the user as authentic and must now convince the server that this user is authentic. To do so, the AS creates a ticket that contains the user's ID and network address and the server's ID. This ticket is encrypted using the secret key shared by the AS and this server. This ticket is then sent back to C. Because the ticket is encrypted, it cannot be altered by C or by an opponent.
With this ticket, C can now apply to V for service. C sends a message to V containing C's ID and the ticket. V decrypts the ticket and verifies that the user ID in the ticket is the same as the unencrypted user ID in the message. If these two match, the server considers the user authenticated and grants the requested service.
Department of Computer Science and Engineering SNGCE. Kadayiruppu
Each of the ingredients of message (3) is significant. The ticket is encrypted to prevent alteration or forgery. The server's ID (IDv) is included in the ticket so that the server can verify that it has decrypted the ticket properly.
IDc is included in the ticket to indicate that this ticket has been issued on behalf of C. Finally, ADc serves to counter the following threat. An opponent could capture the ticket transmitted in message (2), then use the name IDc and transmit a message of form (3) from another workstation. The server could receive a valid ticket that matches the user ID and grant access to the user on that other workstation. To prevent this attack, the AS includes in the ticket the network address from which the original request came. Now the ticket is valid only if it is transmitted from the same workstation that initially requested the ticket.
A More Secure Authentication Dialogue
Although the foregoing scenario solves some of the problems of authentication in an open network environment, problems remain. Two in particular stand out:
First, we would like to minimize the number of times that a user has to enter a password. Suppose each ticket can be used only once. If user logs on to a workstation in the morning and wishes to check his or her mail at a mail server, C must supply a password to get a ticket for the mail server. If C wishes to check the mail several times during the day, each attempt requires reentering the password. We can improve matters by saying that tickets are reusable. For a single logon session, the workstation can store the mail server ticket after it is received and use for multiple accesses to the mail server.
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
However, under this scheme it remains the case that a user would need a new ticket for every different service. If a user wished to access a print server, a mail server, a file server, and so on, the first instance of each access would require a new ticket and hence require the user to enter the password.
The second problem is that the earlier scenario involved a plaintext transmission of the password [message (1)]. An eavesdropper could capture the password and use any service accessible to the victim.
To solve these additional problems, we introduce a scheme for avoiding plaintext passwords and a new server, known as the ticket-granting server (TGS). The new but still hypothetical scenario is as follows:
Once per user logon session: (1)C AS: IDc\\IDtgs
(2) AS C : EKc [Tickettgs] Once per type of service:
(3) C TGS : IDc || IDv \\ Tickettgs
(4) TGS C : Ticketv Once per service session :
(5)C V: IDc || Ticketv Tickettgs = EKtgs [IDc\\ ADc || IDtgs \\ TS1 \\ Lifetimel] Ticketv = EKv [IDC\\ ADC\\IDv \\ TS11| Lifetime2]
The new service, TGS, issues tickets to users who have been authenticated to AS. Thus the user first requests a ticket-granting ticket
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
{Tickettgs) from the AS. This ticket is saved by the client module in the user workstation. Each time the user requires access to a new service, the client applies to the TGS, using the ticket to authenticate itself. The TGS then grants a ticket for the particular service. The client saves each service-granting ticket and uses it to authenticate its user to a server each time a particular service is requested. The details of this scheme are:
1. The client requests a ticket-granting ticket on behalf of the user by sending its user's ID to the AS, together with the TGS ID, indicating a request to use the TGS service.
2. The AS responds with a ticket that is encrypted with a key that is derived from the users password. When this response arrives at the client, the client prompts the userfor his or her password, generates the key, and attempts to decrypt the incoming message. If the correct password is supplied, the ticket is successfully recovered.
Because only the correct user should know the password, only the correct user can recover the ticket. Thus, we have used the password to obtain credentials from Kerberos without having to transmit the password in plaintext. The ticket itself consists of the ID and network address of the user, and the ID of the TGS. The idea is that this ticket can be used by the client to request multiple service-granting tickets. So the ticket granting ticket to be reusable. However we do not want an opponent to be able to capture the ticket and use it. The ticket granting ticket is encrypted with a secret key known only to the AS and the TGS. This prevents alteration of the ticket. The ticket is reencrypted with a key based on the user's password. This assures that the ticket can be recovered only by the correct user, providing the authentication.
Now that the client has a ticket-granting ticket, access to any server can be obtained with steps 3 and 4.
Department of Computer Science and Engineering SNGCE, Kadayiruppu
3. The client requests a service-granting ticket on behalf of the user. For this purpose, the client transmits a message to the TGS containing the user's ID, the ID of the desired service, and the ticket-granting ticket.
4. The TGS decrypts the incoming ticket and verifies the success of the decryption by the presence of its ID. It checks to make sure that the lifetime has not expired. Then it compares the user ID and network address with the incoming information to authenticate the user. If the user is permitted access to V, the TGS issues a ticket to grant access to the requested service.
Finally, with a particular service-granting ticket, the client can gain access to the corresponding service with step 5.
5. The client requests access to a service on behalf of the user. For this
purpose, the client transmits a message to the server containing the user's
ID and the service-granting ticket. The server authenticates by using the
contents of the ticket.
This new scenario satisfies the two requirements of only one password query per user session and protection of the user password.
Kerberos involves 3 servers in addition to A (a client workstation):
Authentication Server (AS) : verifies users during login.
Ticket-Granting Server (TGS) : issues " proof of identity tickets ".
B the server : actually does the work A wants performed
AS is similar to a KDC (Key Distribution Center) in that it shares a secret password with every user. The TGC's job is to issue tickets that can convince the real servers that the bearer of a TGS ticket reaify is he or she claims to be.
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
TGT is the acronym for a "Ticket Granting Ticket", TGS is the acronym for the "Ticket Granting Service".
While it may seen that the two acronyms are used interchangeably, they refer to two very different things. The Ticket Granting Ticket is a Kerberos ticket for the Ticket Granting Service. Both play a special role in Kerberos.
When a user first authenticates to Kerberos, he talks to the Authentication Service on the KDC to get a Ticket Granting Ticket. This ticket is encrypted with the user's password. When the user wants to talk to a Kerberized service, he uses the Ticket Granting Ticket to talk to the Ticket Granting Service (which also runs on the KDC). The Ticket Granting Service verifies the user's identity using the Ticket Granting Ticket and issues a ticket for the desired service.
The reason the Ticket Granting Ticket exists is so a user doesn't have to enter in their password every time they wish to connect to a Kerberized service or keep a copy of their password around. If the Ticket Granting Ticket is compromised, an attacker can only masquerade as a user until the ticket expires.
Working :
To start a session, A (a client workstation) sits down at an arbitrary public workstation and types her name. The workstation sends her name to the AS (authentication server) in plaintext, as in the figure below.
What comes back is a session key and a ticket, KTGS (A,Ks), intended for the TGS.
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
KAIKS.KTGSfA.KStt
~l
AS
Login
KS(B,KAB),KB[A,KAB>
T G
S
Get a ticket
KB(A,KAB),KAB(t)
KAB(t+l)
B
Do the work
Fig: The operation of Kerberos V4
These items are packaged together and encrypted using A's secret key, so that only A can decrypt them. Only when message 2 arrives, does the workstation ask for A's password. The password is then used to generate KA, in order to decrypt message 2 and obtain the session key and TGS ticket inside it. At this point, the workstation overwrites A's password, to make sure that it is only inside the workstation for a few ms at most. If C tries logging in as A, the password he types will be wrong and the workstation will detect this because the standard part of message 2 will be incorrect.
After she logs in, A may tell the workstation that she wants to contact B the file server. The workstation then sends message 3 to the TGS asking for a ticket to use with B. The key element in this request is KTGS <A,KS), which is encrypted with the TGS's secret key and is used as proof that the sender really is A. The TGS responds by creating a session key, KAB, for A to use with B. Two versions of it are sent back. The first is encrypted with only Ks, so A can read it. The second is encrypted with B's key, KB, so B can read it.
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
C can copy message3 and try to use it again, but he will be foiled by the encrypted timestamp, t, sent along with it. C cannot replace the timestamp with a more recent one, because he does not know Ks, the session key A uses to talk to the TGS. Even if C replace message3 quickly, all he will get is another copy of messaged which he could not decrypt the second time either.
Now A can send KAB to B to establish a session with them. This exchange is also timestamped. The response is proof to A that she is actually talking to B, not to C.
After this series of exchanges, A can communicate with B under cover of KAB. If she later decides to talk to another server, D, she just repeats the message3 to the TGS, only now specifying D instead of B. The TGS will promptly respond with a ticket encrypted with Kc that A can send to D and that D will accept as proof that it came from A.
The point of all this work is that is that now A can access servers all over the network in a secure way, and her password never has to go over the network. In fact, it only had to be in her own workstation for a few milliseconds. However note that each server does its own authorization. When A presents her ticket to B, this merely proves to B who sent it. Precisely what A is allowed to do is up to B.
Since the Kerberos designers did not expect the entire world to trust a single authentication server, they made provision for having multiple realms, each with its own AS and TGS. To get a ticket for a server in a distant realm, A would ask her own TGS for a ticket accepted by the TGS in the distant realm. If the distant TGS has registered with the local TGS (the same way local servers do), the local TGS will give A a ticket valid at the distant TGS. She can then do ^ess over there, such as getting tickets for servers in that realm. Note,
Department of Computer Science and Engineering SNGCE, Kadayiruppu
however, that for parties in two realms to do business, each one must trust the other's TGS.
Resources needed to dedicate to a KDC:
You will need a dedicated machine to run the KDC on. The database stored on this machine is quite sensitive; if it's compromised, your entire realm will be compromised. Therefore, this machine needs to be as secure as possible. This machine also has to be reliable. If it is down, you will not be able to use any Kerberized services unless you have also configured a slave server.
Running the Kerberos server requires very little CPU power and a small amount of disk. An old PC with some hundreds of megabytes of free disk space should do fine. Most of the disk space will be used for various logs.
Because the KDC has all of the keys for all of the principals in your realm, loss of the Kerberos database would require your entire realm to be rekeyed. Thus, backing up your Kerberos database is critical. However, precisely because the database contains all of your keys, you should treat backups of the KDC with the same security that you treat the KDC itself.
Need to synchronize the system clocks to run Kerberos:
The actual verification of a client's identity is done by validating an authenticator. The authenticator contains the client's identity and a timestamp. To ¦T jre that the authenticator is up-to-date and is not an old one that has been captured by an attacker, the timestamp in the authenticator is checked against the current time. If the timestamp is not close enough to the current time
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
(typically within five minutes) then the authenticator is rejected as invalid. Thus, Kerberos requires your system clocks to be loosely synchronized (the default is 5 minutes, but it can be adjusted in Version 5 to be whatever you want).
Advantages of Kerberos over SSL
1) Key revocation.
If a Verisign certificate issued to a user is compromised and must be revoked, how will all the servers with whom that user interacts know that the certificate is no longer valid Either revocation certificates have to be circulated to all relevant servers and cached for a long time, or servers have to verify incoming user certificates against a "revocation server." In that case, the revocation server must be a highly available third party, which means you've eliminated one of the two major advantages of SSL over Kerberos. Kerberos principals can be disabled at will on the KDC and will then become unusable as soon as any cached tickets expire, on the order of hours, without any action by servers.
2) Key security.
If I'm issued a Verisign certificate, it has to live on my hard disk. It may be encrypted there such that I have to unlock it with a password before I can use it, but it's still on the hard disk and therefore vulnerable to cracking attacks. On the other hand, I don't need any sort of certificate to authenticate to Kerberos -- all I need is my password, which is in my brain, not on a hard disk.
3) Cost of use.
Kerberos doesn't infringe on any patents; which means that it can be used for free, while SSL users may have to pay.
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
If
4) Open standards,
Kerberos has been free from the beginning. The standards documenting it are open and have been developed openly from the start. On the other hand, SSL was developed by a company with a commercial interest in ensuring that its standards become THE standard. Let's just say that Netscape is not exactly known for "playing by the rules" when it comes to developing Internet standards.
5) Flexibility.
Kerberos is somewhat more flexible than SSL. For example, if I want to add a new authentication technology to Kerberos (e.g., a new kind of SmartCard with its own algorithm), all I have to do is modify my KDC and my ticket-acquiring client to know how to do the new authentication. Then, it can be used to get Kerberos tickets which will look the same as any other Kerberos tickets and will be usable with any Kerberos-capable application. On the other hand, if I want to implement a new authentication technology for SSL, I'd have to get new versions of all my SSL-capable applications.
Advantages of SSL
SSL has two major advantages over Kerberos:
(1) It doesn't require an accessible trusted third party;
(2) It can be used to establish a secure connection even when one end of the connection doesn't have a "secret" (a.k.a. "key" or "password").
Kerberos Realms and Multiple Kerberi
A full service Kerberos environment consisting of a Kerberos server, a number of clients, and a number of application servers requires the following :
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
p
The Kerberos server must have the user ID (UID) and hashed password of all participating users in its database. All users are registered with the Kerberos
1. The Kerberos server must share a secret key with each server. All servers are registered with the Kerberos server.
2. The Kerberos server in each inte rope rating realm shares a secret key with the server in the other realm. The two Kerberos servers are registered with each other.
Kerberos Version 5
Kerberos V5 is fancier than V4.The latest version of Kerberos 5 is 1.2.1. - ": many things were changed, the basic core ideas of the protocol have ¦amairted the same. Indeed, there are only two changes where Kerberos V5 dHers from the description of the "Kerberos" protocol.
The first change was born out of the recognition that using a small five iranute time skew wasn't necessarily sufficient to prevent replay attacks from an attacker who used a program to automatically grab the ticket and the
enticator as they traversed the network, and then immediately resent them to aunch a replay attack.
In Kerberos V5, authenticators are made to be truly "once-only" by having servers which accept tickets to have a "replay cache" which keeps note of authenticators have been presented to the server recently. If an attacker tries to snatch an authenticator and reuse it, even during the five-minute acceptance window, the replay cache will be able to determine that the authenticator has already been presented to the server.
|
Department of Computer Science and Engineering SNGCE, Kadayiruppu
The second major change to the protocol is that the ticket is no longer encrypted in the user's password when it is sent from the Kerberos server during the initial ticket exchange. The ticket is already encrypted in the ticket granting seer's secret key; furthermore when it is actually used to obtain other tickets, it gets sent in the network in the clear anyway. Hence, there is no reason why the
. ¦ . should be encrypted again in the user's password. (The rest of the - ‚¬~e-os server's reply to the user, containing for example the user's copy of the ticket session key, is still encrypted in the user's password, of course.)
A similar change was also made to the ticket granting service (TGS) zoY. tickets returned by TGS are also no longer encrypted by the ticket-granting ticket's service key, since application tickets are already encrypted by :.-¦=¦ application server's secret key.
In both Kerberos 4 and Kerberos 5, a machine's network address is za~. cf the ticket information. This address is used as an additional check to ~ 3*e sure the ticket hasn't been stolen and is being used on another machine.
In Kerberos 4, there was room for only one IP address in the ticket, which did not work with multihomed machines. KTH krb4 includes some hacks to make it work with Kerberos 4.
Kerberos 5 supports multiple IP addresses in a ticket, thus allowing Kerberos 5 tickets to deal with multi-homed machines. However, doing so requires careful configuration of your DNS server
What things to do to make V4 clients work with the V5 KDC
1. The network protocol used is very different.
2. The string-to-key algorithm is different.
3. The format of the encrypted tickets is very different.
-ese are the main differences between V4 and V5 .
The MIT V5 KDC can speak the V4 protocol as well as the V5 protocol, so difference number 1 isn't a big problem. The MIT V5 KDC also supports the V4 string-to-key algorithm, and will use this to encrypt tickets when e
V4 requests.
The MIT distribution also included a special daemon called krb524d. This can be used to convert an encrypted Kerberos 5 ticket into an encrypted - T":ETOS4 ticket A number of the MIT application servers (telnetd, rlogind, rshd) support V4 clients as well as V5.
If your application needs to get a Kerberos 4 TGT, then you need to :. jre your KDC to support Kerberos 4 salted keys. You can tell if your :: cation needs to get a V4 TGT if you have to give it a Kerberos password at point.
If your application needs to get V4 service tickets, then you have Vte option of using krb524init to convert your V5 TGT into a V4 TGT, and then . - application can use the V4 TGT to acquire V4 service tickets.
If you can modify your application, then you can change it so it converts a V5 service ticket into a V4 service ticket internally. This is the approach used by the aklog program in the AFS-Kerberos 5 migration kit.
If you want to support a V4 application server, you need to create a V4 format keytab containing the principal used by the application server. You can do this by using ktutil to convert a V5 format keytab into the corresponding V4 keytab. If you simply wish to support incoming Kerberos 4 telnet or rlogin, then all you need to do is configure the daemons to support V4 connections. This is done by an additional flag in inetd.conf for the Berkeley r-commands. The V4
Department of Computer Science and Engineering SNGCE, Kadayiruppu
:: -ipatibility routines can read a Kerberos 5 keytab, so there's no need to copy it
over.
There is a bug in telnetd that prevents it from talking correctly to V4 cients; to work around it, you simply need to create an empty /etc/srvtab. There is one more important point when dealing with V4 clients. You should never create V4 format principals in your KDC; you should use the V5 names. For example, you shouldn't create rcmd.foo; you should instead always use hostyfoo.bar.org
The KDC automatically converts back and forth between V4 and V5 principal names at the appropriate times. This is trivial for user principals, but is trickier for host-based principals. Since the instance was the "short" name in V4 and is now fully qualified in V5, rules have to be configured to convert between V4 and V5 instances. This is done via the default_domain and the v4_instance_convert lines in krbS.conf.
The default_domain variable is used to indicate the DNS domain name that is removed or added when converting between V4 and V5 principals. For example, if you have:
[realms]
F00.BAR.ORG = {
kdc = kdc1.foo.bar.org defaultdomain = foo.bar.org
}
Then the V5 principal host/sun 1.foo.bar.org will be converted to the V4 principal rcmd/sunl.
Department of Computer Science and Engineering SNGCE, Kadayiruppu
The v4_jnstance_convert variable is used to configure exceptions ID the default mapping rule. For example, let's say the above realm has a host called foo.bar.org. Under V4 the host principal for this machine would be called rcmd/foo, but the default_domain rule would fail to convert this principal name correctly. However, if we place the following in our krbS.conf:
v4jnstance_convert = { foo = foo.bar.org
1
Then the instance will be converted correctly. Since all of these name translations take place on the KDC, you generally only needs to make sure the krbS.conf files on the KDC are the ones that are up-to-date.
Administering the Kerberos
This information applies to the MIT Kerberos 5 release. If you're using one of the commercial versions of Kerberos, then you should consult the documentation that came with it.
First, you should read at least some of the documentation and you will find that administrating Kerberos is much easier once you understand the fundamentals. Once you feel you understand the basics, you should download the software from MIT. Note that Kerberos is usually distributed as three tar files containing the src, doc, and crypto directories; you'll want to download all three tar files.
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
The doc directory contains three important files that you'll want to read: ¦mKerberos installation guide, the Kerberos administration guide, and the kerberos user's guide. The first one you'll need to read is the installation guide.
After you have everything downloaded, you should compile the ;ros distribution. If you don't have the space or would rather not, binary snapshots of Kerberos are available from the Kerberos web site for some of the more popular versions of Unix,
If you're compiling Kerberos yourself, the installation guide explains how to do it, and lists most of the options you can give to configure program. Unless you have special needs the defaults are usually sufficient. Building the MIT Kerberos 5 distribution requires GNU make. Once Kerberos is built, you should follow the instructions in the install guide: "Installing Kerberos 5".
Unfortunately, it is difficult to give specific directions on how to deploy Kerberos at your site, since every site is different.
Programming with Kerberos
Some common mistakes that newbies do when they Kerberize their first client-server application:
1. They hard-code various things into their code, such as the location of the keytab file, or the server's principal name. Bad ideas. Consider that people may want to put the keytab files in places other than your products' installation directory.
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
Further, you should also make sure that end-users can choose whatever principal name they wish for each server instance... This has a side effect that the client side protocol needs to be able to discover the principal name of the server process before getting and sending an authenticator. Without the ability to choose principal names, it may be difficult to multiply-instantiate servers in a Kerberos realm.
2. Put lots of debugging trace statements in your implementation. These are invaluable for diagnosing Kerberos related problems once your product is in deployment.
3. Consider using generic GSSAPI (Generic Security Services Application Programming Interface, generic API fordoing client-server authentication) services.
Another point worth mentioning is that if you are using a standardized protocol such a POP, IMAP, etc) it is strongly recommended that you work within the ¢>amework of that protocol. In the case of protocols like POP and IMAP, there is already a standard authentication framework into which Kerberos fits. This saves you the work of having to design a protocol for your application. This doesn't apply to custom protocols developed internally, of course, but the design decisions made for standardized protocols might give you some ideas to apply to your own protocol.
Issues in Kerberos
Consider the following situation:
Employee <X> just left the company, and he had root on our KDC, What should be done
Department of Computer Science and Engineering
SNGCE, Kadayiruppu
If a person had root on your KDC, then they had the ability to grab a copy of your entire Kerberos database. While the database is encrypted with the master key, a root user could have read the master key out of the stash file, or even attached a debugger to the KDC process to read the master key out of the KDC's memory.
When a user's key is compromised, the attacker can impersonate that user. If a host key is compromised, then an attacker could generate forged service tickets for that host with any user in the ticket. However, the worst key to get compromised is the krbtgt key, as an attacker could use this to generate a valid TGT for any principal in your realm.
The steps you should take depend on the exact circumstances of the incident and your local site policy. If such a situation happened, it is recommended that you should immediately change the key for the krbtgt and the admin principals, and force a global user password change over some period of time.
A compromised master key isn't quite as bad as one would normally fear. The master key is only used to encrypt the Kerberos database and as a seed for the random number generator. As long as access to your KDC is secure, an attacker can't do much with the master key.
Weaknesses in Kerberos
Kerberos makes no provisions for host security; it assumes that it is running on trusted hosts with an untrusted network. If your host security is compromised, then Kerberos is compromised as well.
Department of Computer Science and Engineering SNGCE, Kadayiruppu
However, the degree to which Kerberos is compromised depends on the host that is compromised. If an attacker breaks into a mufti-user machine and steals all of the tickets stored on that machine, he can impersonate the users who have tickets stored on that machine but only until those tickets expire.
Kerberos uses a principal's password (encryption key) as the fundamental proof of identity. If a user's Kerberos password is stolen by an attacker, then the attacker can impersonate that user with impunity. Since the KDC holds all of the passwords for all of the principals in a realm, if host security on the KDC is compromised, then the entire realm is compromised.
In Kerberos 4, authenticators are valid for 5 minutes. If an attacker sniffs the network for authenticators, they have a 5 minute window in which they can re-use it and gain access to the same service you used. Kerberos 5 introduced a replay cache which prevents any authenticator from being used more than once.
Since anybody can request a TGT for any user, and that ticket is encrypted with the user's secret key (password), it is simple to perform an offline attack on this ticket by trying to decrypt it with different passwords. Kerberos 5 introduced preauthentication to solve this problem.
Department of Computer Science and Engineering SNGCE, Kadayiruppu
CONCLUSION
The Internet is an insecure place. Many of the protocols used in the Internet do not provide any security. Tools to "sniff' passwords off of the network are in common use by systems crackers. Thus, applications which send an unencrypted password over the network are extremely vulnerable. Worse yet, other client/server applications rely on the client program to be "honest" about the identity of the user who is using it. Other applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server. To solve these network security problems, MIT developed an authentication sen/ice called Kerberos. Kerberos provides a centralized authentication server whose function is to authenticate user to servers and servers to users. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. Kerberos is available in two versions; version 4 and a more secure version 5.
BIBLIOGRAPHY
1. web.mJt.edu/kerberos
2. isi.edu
3. Computer Networking-A Top Down Approach Featuring the Internet
James F Kurose, Keith W Ross
4. Computer Networks :- Andrew S Tanenbaum
INDEX
SI No: Description Page No:
1. INTRODUCTION 1
2. OVERVIEW 2
3. MOTIVATION 4 - KERB EROS VERSION 4 6
4.1 A SIMPLE AUTHENTICATION DIALOGUE 6
4.2 A MORE SECURE AUTHENTICATION DIALOGUE 8
4.3 WORKING 12 |. RESOURCES NEEDED TO DEDICATE TO A KDC 15
6. NEED TO SYNCHRONIZE SYSTEM CLOCKS 15
7. ADVANTAGES OF KERB EROS OVER SSL 16
8. KERBEROS REALMS AND MULTIPLE KERBERI 18
9. KERBEROS VERSION 5 18 ADMINISTERING THE KERBEROS 22
I [.PROGRAMMING WITH KERBEROS 23
: 2.ISSUES IN KERBEROS 24
13.WEAKNESSES IN KERBEROS 25
14.CONCLUSION 27
15.BIBLIOGRAPHY 28
