Your SlideShare is downloading. ×
Rakesh
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rakesh

417
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
417
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. KERBEROS CHAPTER 1INTRODUCTION Computer security has been a problem since the very beginning. Proper authenticationand protection using cryptographic methods is a must in today’s electronic communication.Kerberos provides an infrastructure to achieve this using symmetric cryptography.1.1. History Kerberos was developed at the Massachusetts Institute of Technology (MIT) during aproject intended to integrate computers into the university’s undergraduate curriculum. Theproject, called Athena, started in 1983 with UNIX timesharing computers, having severalterminals connected to each one, but without a network connection. If a student or staff memberwanted to use any of the computers, he or she sat down at one of these terminals. As soon as theterminals and old computers were substituted by newer workstations with network connection,the project’s goal was to allow any user to sit down at the workstation of his or her choiceaccessing his data over the network (which is a very common scenario for every network today).The problem of network eavesdropping became apparent. Since the network has been accessiblefrom all over the campus, nothing prevented students from running network monitoring tools andlearning other users and root passwords. Another big problem was some PC/ATs which werelacking even fundamental internal security. To protect the users’ data in the networkenvironment as it had been protected in the timesharing environment Kerberos was invented.Kerberos is an authentication system that uses symmetric key cryptography to protect sensitiveinformation on an open network. It is a ticket based system that issues a ticket encrypted with theuser’s password when he or she logs in. The user decrypts the ticket and uses it to obtain ticketsfor other network services he or she wants to use. Because all information in tickets is encrypted,it is not susceptible to eavesdropping or misappropriation.DEPT OF Comp Engg. 1 D.B.N.C.O.E.T,YTL
  • 2. KERBEROS MIT developed Kerberos to protect network services provided by Project Athena. Theprotocol was named after the Greek mythological character Kerberos (or Cerberus), known inGreek mythology as being the monstrous three-headed guard dog of Hades.1.2. Motivation In a network of users requiring services from many separate computers, there are threeapproaches one can take to access control: One can do nothing, relying on the machine to whichthe user is logged in to prevent unauthorized access; one can require the host to prove its identity,but trust the host’s word as to who the user is; or one can require the user to prove her/hisidentity for each required service.In a closed environment where all the machines are under strictcontrol, one can use the first approach. When the organization controls all the hostscommunicating over the network, this is a reasonable approach. In a more open environment, one might selectively trust only those hosts underorganizational control. In this case, each host must be required to prove its identity.In thoseprotocols,authentication is done by checking the Internet address from which a connection hasbeen established. In the Athena environment, we must be able to honor requests from hosts thatare not under organizational control. Users have complete control of their workstations: they canreboot them, bring them up standalone, or even boot off their own tapes. As such, the thirdapproach must be taken; the user must prove her/his identity for each desired service. The servermust also prove its identity. It is not sufficient to physically secure the host running a networkserver; someone elsewhere on the network may be masquerading as the given server. The environment places several requirements on an identification mechanism. First, itmust be secure. Circumventing it must be difficult enough that a potential attacker does not findthe authentication mechanism to be the weak link. Someone watching the network should not beable to obtain the information necessary to impersonate another user. Second, it must be reliable.Access to many services will depend on the authentication service. If it is not reliable, the systemof services as a whole will not be. Third, it should be transparent. Ideally, the user should not beaware of authentication taking place. Finally, it should be scalable. Many systems canDEPT OF Comp Engg. 2 D.B.N.C.O.E.T,YTL
  • 3. KERBEROScommunicate with Athena hosts. Not all of these will support the mechanism, but softwareshould not break if they did. Kerberos is the result of our work to satisfy the above requirements. When a user walksup to a workstation she/he “logs in”. As far as the user can tell, this initial identification issufficient to prove her/his identity to all the required network servers for the duration of the loginsession. The security of Kerberos relies on the security of several authentication servers, but noton the system from which users log in, or on the security of the end servers that will be used. Theauthentication server provides a properly authenticated user with a way to prove her/his identityto servers scattered across the network.DEPT OF Comp Engg. 3 D.B.N.C.O.E.T,YTL
  • 4. KERBEROS CHAPTER 2KERBEROS Kerberos is a computer network authentication protocol, which allows nodescommunicating 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 andinsecure networks where communications between the hosts belonging to it may be intercepted.However, one should be aware that Kerberos does not provide any guarantees if the computersbeing used are vulnerable: the authentication servers, application servers and clients must be keptconstantly 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 onuntrusted networks". Kerberos is a trusted third-party authentication service based on the model presented byNeedham and Schroeder. It is 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 (largenumbers representing the current date and time) have been added to the original model to aid inthe detection of replay. Replay occurs when a message is stolen off the network and resent later.2.1.Protocol Kerberos uses as its basis the symmetric Needham-Schroeder protocol.2.1.1.Needham-Schroeder Authentication An approach to secure authentication is the Needham- Schroeder protocol. It defines athree-party authentication service and five step message chain. In the very first step the clientrequests a session key for communication with a certain service. The requested session key and amessage encrypted for the service is send back to the client encrypted with the client’s key toprotect it in an open network. The client forwards the part for the service (which is encryptedwith the service key) to the desired service. After that the service generates a random messagewhich is sent back to the client encrypted with the session key. This random message istransformed in a predefined way and sent back to the server encrypted with the session key asDEPT OF Comp Engg. 4 D.B.N.C.O.E.T,YTL
  • 5. KERBEROSwell to prove that A was the sender of message number three. After performing these five stepsthe service can be sure that the client has authenticated itself correctly, because only the clientknows the key to decrypt message two. This protocol is no longer considered secure as B does not know if the key is fresh. If anattacker obtains an old key he or she can perform a replay attack and convince B that the keythey hold is the current key of A.2.1.2.Needham-Schroeder in Kerberos Kerberos uses a variant of Needham-Schroeder, which uses timestamps on every messageto avoid the problem mentioned above. Due to the fact that it is a problem to keep all clocksreturning exact the same time in a network environment, every message is valid in a timewindow from five minutes in the past to five minutes in the future. In a short time slot of tenminutes length replay attacks are impeded by a replay cache held by every service. Messages arecached as long as they are valid and authentication attempts using messages which are alreadyheld in cache can be refused.DEPT OF Comp Engg. 5 D.B.N.C.O.E.T,YTL
  • 6. KERBEROS CHAPTER 3TERMINOLOGY This section provides the definition of the objects and terms, knowledge of which isessential for the subsequent description of the Kerberos protocol.3.1.Realm The term realm indicates an authentication administrative domain. Its intention is toestablish the boundaries within which an authentication server has the authority to authenticate auser, host or service. This does not mean that the authentication between a user and a service thatthey must belong to the same realm: if the two objects are part of different realms and there is atrust relationship between them, then the authentication can take place. This characteristic isknown as Cross-Authentication Basically, a user/service belongs to a realm if and only if he/itshares a secret (password/key) with the authentication server of that realm. The name of a realm is case sensitive, i.e. there is a difference between upper and lowercase letters, but normally realms always appear in upper case letters. It is also good practice, inan organization, to make the realm name the same as the DNS domain (in upper case lettersthough). Following these tips when selecting the realm name significantly simplifies theconfiguration 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, itis appropriate that the related Kerberos realm is EXAMPLE.COM.3.2.Principal A principal is the name used to refer to the entries in the authentication server database.A principal is associated with each user, host or service of a given realm. A principal in Kerberos5 is of the following type: component1/component2/.../componentN@REALMDEPT OF Comp Engg. 6 D.B.N.C.O.E.T,YTL
  • 7. KERBEROS However, in practice a maximum of two components are used. For an entry referring to auser the principal is the following type: Name[/Instance]@REALM The instance is optional and is normally used to better qualify the type of user. Forexample administrator users normally have the admin instance. The following are examples ofprincipals referred to users: mark@EXAMPLE.COM admin/admin@EXAMPLE.COM pluto/admin@EXAMPLE.COM If, instead, the entries refer to services, the principals assume the following form: Service/Hostname@REALM3.3. Ticket A ticket is something a client presents to an application server to demonstrate theauthenticity of its identity. Tickets are issued by the authentication server and are encryptedusing the secret key of the service they are intended for. Since this key is a secret shared onlybetween the authentication server and the server providing the service, not even the client whichrequested the ticket can know it or change its contents. The main information contained in aticket includes:· The requesting users principal (generally the username);· The principal of the service it is intended for;· The IP address of the client machine from which the ticket can be used. In Kerberos 5 this fieldis optional and may also be multiple in order to be able to run clients under multi-homed.· The date and time (in timestamp format) when the tickets validity commences;· The tickets maximum lifetime.DEPT OF Comp Engg. 7 D.B.N.C.O.E.T,YTL
  • 8. KERBEROS Each ticket has expiration (generally 10 hours). This is essential since the authenticationserver no longer has any control over an already issued ticket. Even though the realmadministrator can prevent the issuing of new tickets for a certain user at any time, it cannotprevent 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.3.4. 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 other words the same key is used to encryptand decrypt).3.4.1. Encryption type Kerberos 4 implements a single type of encryption which is DES at 56 bits. Theweakness of this encryption plus other protocol vulnerabilities has made Kerberos 4 obsolete.Version 5 of Kerberos, however, does not predetermine the number or type of encryptionmethodologies supported. It is the task of each specific implementation to support and bestnegotiate the various types of encryption. However, this flexibility and expandability of theprotocol has accentuated interoperability problems between the various implementations ofKerberos 5. In order for clients and application and authentication servers using differentimplementations to interoperate, they must have at least one encryption type in common. Thedifficulty related to the interoperability between UNIX implementations of Kerberos 5 and theone present in the Active Directory of Windows is a classic example of this. Indeed, WindowsActive Directory supports a limited number of encryptions and only had DES at 56 bits incommon with UNIX. This required keeping the latter enabled, despite the risks being wellknown, if interoperability had to be guaranteed. The problem was subsequently solved withversion 1.3 of MIT Kerberos 5. This version introduced RC4-HMAC support, which is alsopresent in Windows and is more secure than DES. Among the supported encryptions (but not byWindows) the triple DES (3DES) and newer AES128 and AES256 are worth mentioning.DEPT OF Comp Engg. 8 D.B.N.C.O.E.T,YTL
  • 9. KERBEROS3.4.2. Encryption key As stated above, one of the aims of the Kerberos protocol is to prevent the userspassword from being stored in its unencrypted form, even in the authentication server database.Considering that each encryption algorithm uses its own key length, it is clear that, if the user isnot to be forced to use a different password of a fixed size for each encryption method supported,the encryption keys cannot be the passwords. For these reasons the string2key function has beenintroduced, which transforms an unencrypted password into an encryption key suitable for thetype of encryption to be used. This function is called each time a user changes password or entersit 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 by bruteforce). Famous hashing algorithms are MD5 and CRC32.3.4.3. Salt In Kerberos 5, unlike version 4, the concept of passwordsalt has been introduced. This isa string to be concatenated to the unencrypted password before applying the string2key functionto obtain the key. Kerberos 5 uses the same principal of the user as salt: Kmark = string2key (Pmark + "mark@EXAMPLE.COM") Kmark is the encryption key of the user mark and Pmark is the unencrypted password ofthe user.This type of salt has the following advantages: Two principals belonging to the same realm and having the same unencrypted password,still have different keys. For example, imagine an administrator having a principal for everydaywork (mark@EXAMPLE.COM) and one for administrative work(mark/admin@EXAMPLE.COM). It is very likely that this user has set the same password forboth principals for reasons of convenience. The presence of the salt guarantees that the relatedkeys are different.DEPT OF Comp Engg. 9 D.B.N.C.O.E.T,YTL
  • 10. KERBEROS If a user has two accounts in different realms, it is fairly frequent that the unencryptedpassword is the same for both realms: thanks to the presence of the salt, a possible compromiseof an account in one realm will not automatically cause the other to be compromised. A null saltcan be configured for compatibility with Kerberos 4. Vice versa, for compatibility with AFS, it ispossible to configure a salt which is not the complete name of the principal, but simply the nameof the cell.3.4.4. Key Version Number (kvno) When a user changes a password or an administrator updates the secret key for anapplication server, this change is logged by advancing a counter. The current value of the counteridentifying the key version is known as the Key Version Number or more briefly kvno.3.5. Key Distribution Center (KDC) The authentication server in a Kerberos environment, based on its ticket distributionfunction for access to the services, is called Key Distribution Center or more briefly KDC. Sinceit resides entirely on a single physical server (it often coincides with a single process) it can belogically considered divided into three parts: Database, Authentication Server (AS) and TicketGranting Server (TGS).3.5.1 Database The database is the container for entries associated with users and services. We refer toan entry by using the principal (i.e. the name of the entry) even if often the term principal is usedas a synonym for entry. Each entry contains the following information:·The principal to which the entry is associated;·The encryption key and related kvno;·The maximum validity duration for a ticket associated to the principal;DEPT OF Comp Engg. 10 D.B.N.C.O.E.T,YTL
  • 11. KERBEROS·The maximum time a ticket associated to the principal may be renewed (only Kerberos 5);·The attributes or flags characterizing the behavior of the tickets;·The password expiration date;·The expiration date of the principal, after which no tickets will be issued. In order to make it more difficult to steal the keys present in the database, theimplementations encrypt the database using the master key, which is associated with theprincipal K/M@REALM. Even any database dumps, used as backups or for propagation fromthe KDC master towards the slave, are encrypted using this key, which it is necessary to know inorder to reload them.3.5.2 Authentication Server (AS) The Authentication Server is the part of the KDC which replies to the initialauthentication request from the client, when the user, not yet authenticated, must enter thepassword. In response to an authentication request, the AS issues a special ticket known as theTicket 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 TGTto obtain other service tickets, without having to re-enter their password.3.5.3 Ticket Granting Server (TGS) The Ticket Granting Server is the KDC component which distributes service tickets toclients with a valid TGT, guaranteeing the authenticity of the identity for obtaining the requestedresource on the application servers. The TGS can be considered as an application server (giventhat to access it, it is necessary to present the TGT) which provides the issuing of service ticketsas a service. It is important not to confuse the abbreviations TGT and TGS: the first indicates aticket and the second a service.DEPT OF Comp Engg. 11 D.B.N.C.O.E.T,YTL
  • 12. KERBEROS3.6. Session Key As we have seen, the users and services share a secret with the KDC. For users, thissecret is the key derived from their password, while for services, it is their secret key (set by theadministrator). These keys are called long term, since they do not change when the work sessionchanges. However, it is necessary that the user also shares a secret with the service, at least forthe time in which a client has a work session open on a server: this key, generated by the KDCwhen a ticket is issued, is called the Session Key. The copy intended for the service is envelopedby the KDC in the ticket (in any case their application server knows the long term key and candecode it and extract the session key), while the copy intended for the user is encapsulated in anencrypted packet with the user long term key. The session key plays a fundamental role indemonstrating the authenticity of the user.3.7. Authenticator Even if the user principal is present in a ticket and only the application server can extractand possibly manage such information (since the ticket is encrypted with the secret key of theservice), this is not enough to guarantee the authenticity of the client. An impostor could capture(remember the hypothesis of an open and insecure network) the ticket when it is sent by alegitimate client to the application server, and at an opportune time, send it to illegitimatelyobtain the service. On the other hand, including the IP addresses of the machine from where it ispossible to use it is not very useful: it is known that in an open and insecure network addressesare easily falsified. To solve the problem, one has to exploit the fact that the client and server, atleast during a session have the session key in common that only they know (also the KDC knowsit since it generated it, but it is trusted by definition!!!). Thus the following strategy is applied:along with the request containing the ticket, the client adds another packet (the authenticator)where the user principal and time stamp (it’s at that time) are included and encrypts it with thesession key; the server which must offer the service, upon receiving this request, unpacks thefirst ticket, extracts the session key and, if the user is actually who he/she says, the server is ableto unencrypt the authenticator extracting the timestamp. If the latter differs from the server timeby less than 2 minutes (but the tolerance can be configured) then the authentication is successful.This underlines the criticality of synchronization between machines belonging to the same realm.DEPT OF Comp Engg. 12 D.B.N.C.O.E.T,YTL
  • 13. KERBEROS3.8. Replay Cache The possibility exists for an impostor to simultaneously steal both the ticket and theauthenticator and use them during the 2 minutes the authenticator is valid. This is very difficultbut not impossible. To solve this problem with Kerberos 5, Replay Cache has been introduced. Inapplication servers (but also in TGS), there exists the capacity to remember authenticators whichhave arrived within the last 2 minutes, and to reject them if they are replicas. With this theproblem is resolved as long as the impostor is not smart enough to copy the ticket andauthenticator and make them arrive at the application server before the legitimate request arrives.This really would be a hoax, since the authentic user would be rejected while the impostor wouldhave access to the service.3.9. Credential Cache The client never keeps the users password, nor does it memorize the secret key obtainedby applying string2key: they are used to decrypt the replies from KDC and immediatelydiscarded. However, on the other hand, to implement the single sign-on (SSO) characteristic,where the user is asked to enter the password just once per work session, it is necessary tomemorize the tickets and related session key. The place where this data is stored is called the"Credential Cache". Where this cache needs to be located does not depend on the protocol, butvaries from one implementation to another. Often for portability purposes they are located in thefile system (MIT and Heimdal). In other implementations (AFS and Active Directory), in orderto increase security in the event of vulnerable clients, the credential cache is placed in an area ofthe memory accessible only to kernels and not swappable on the disk.DEPT OF Comp Engg. 13 D.B.N.C.O.E.T,YTL
  • 14. KERBEROS CHAPTER 4WORKING Kerberos operates by encrypting data with a symmetric key. A symmetric key is a type ofauthentication where both the client and server agree to use a single encryption/decryption keyfor sending or receiving data. When working with the encryption key, the details are actuallysent to a key distribution center, or KDC, instead of sending the details directly between eachcomputer. The entire process takes a total of eight steps:Step 1: The authentication service, or AS, receives the request by the client and verifies that theclient is indeed the computer it claims to be. This is usually just a simple database lookup of theuser’s ID. (Fig 4.1) Fig 4.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. Theencryption key is then created. The timestamp ensures that when 8 hours is up, the encryptionkey is useless. (This is used to make sure a hacker doesn’t intercept the data, and try to crack thekey. Almost all keys are able to be cracked, but it will take a lot longer than 8 hours to do so.)DEPT OF Comp Engg. 14 D.B.N.C.O.E.T,YTL
  • 15. KERBEROSStep 3: The key is sent back to the client in the form of a ticket-granting ticket, or TGT. This is asimple ticket that is issued by the authentication service. It is used for authenticating the clientfor future reference. (Fig 4. 2) Fig4. 2.Authentication service issues TGT.Step 4: The client submits the ticket-granting ticket to the ticket-granting server, or TGS, to getauthenticated. (Fig 4.3) Fig 4.3.Client submits TGT to TGS.DEPT OF Comp Engg. 15 D.B.N.C.O.E.T,YTL
  • 16. KERBEROSStep 5: The TGS creates an encrypted key with a timestamp, and grants the client a serviceticket. (Fig 4.4) Fig 4.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 ownencrypted key to the service.Step 7: The service decrypts the key, and makes sure the timestamp is still valid. If it is, theservice contacts the key distribution center to receive a session that is returned to the client. (Fig4.5)DEPT OF Comp Engg. 16 D.B.N.C.O.E.T,YTL
  • 17. KERBEROS Fig 4.5. Service server decrypts key and make sure timestamp is valid.Step 8: The client decrypts the ticket. If the keys are still valid, communication is initiatedbetween client and server. (Fig 4.6) Fig 4.6 For valid keys communication is initiated.After the communication is made between the client and server, no further need of transmittinglogon information is needed. The client is authenticated until the session expires.DEPT OF Comp Engg. 17 D.B.N.C.O.E.T,YTL
  • 18. KERBEROS4.1. The Mutual Authentication Process The authentication method described above seems a little one-sided. Kerberos providessupport for mutual authentication, for a more secure protection against man in the middle attacks.This type of authentication is fairly easy to understand, since it only involves two systems. TheSteps involved in the mutual authentication process is as listed below:Step 1: The first system creates a challenge code made up of random numbers.Step 2: This code is sent to the second system, which generates a response to the received code.This response and a challenge code of its own are then sent back to the first system.Step 3: The first system verifies the response of the second system, and then sends a response tothe challenge code it received.Step 4: When the second system receives the response, it is verified. If all is well, it notifies thefirst system that they are indeed mutually authenticated. This type of authentication uses challenge codes to ensure that both computers are whothey claim to be. If someone tries to intercept the data, they obviously will fail because they can’tpretend to be one of the computers after they have been authenticated with challenge codes.DEPT OF Comp Engg. 18 D.B.N.C.O.E.T,YTL
  • 19. KERBEROS CHAPTER 5KERBEROS ENVIRONMENT A typical Kerberos environment can be divided into two main parts. On the one handthere is the Kerberos infrastructure containing at least one Kerberos server or so called KeyDistribution Center (KDC). The KDC holds a complete database of user and service keys. This isa serious disadvantage, because if an attacker could gain access to a Kerberos server he learnsevery single key of the realm, the server is in. On the other hand there are Kerberos-enabledclients and services called kerberized clients and services.5.1. A Typical Infrastructure As the trusted part, a Kerberos server has to be secured properly. This means, that anattacker should not be able to gain access on the machine to get or alter the key database storedon it. To assure that, physical access on logins should only be allowed to trusted staff membersand no other services should be placed on that host. To secure the server, virus scanners andintrusion detection systems can be set up on it. Usually more than one Kerberos server are set up in a typical environment to provide analmost error-free Kerberos service. This realm is the administrative domain. The realm is entitledafter the Internet domain name of the network, using this naming scheme, every realm has adistinct name in a global name-space. Common environments use one realm per institution butdividing big institutions into several realms is also possible. As one can see in (Fig 5.1.1), clientsthat want to access the Kerberos servers of a domain need not to be connected to the localnetwork. With a proper configuration, they can use Kerberos for their realm from everywhere onthe Internet. One dedicated server per realm is holding the master copy of the Kerberos database. Thisserver is called the master server and any other Kerberos servers in the realm receive their copiesfrom this server. In case of a not responding server every client can contact the other servers inthe realm to obtain tickets. Unexpected interruptions as a result of hardware failures can beavoided this way. Every client can connect to any Kerberos server he knows in one realm.DEPT OF Comp Engg. 19 D.B.N.C.O.E.T,YTL
  • 20. KERBEROS Fig 5.1.1 A possible Kerberos environment5.2. Details of KDC The Key Distribution Center is logically split into two services that reside on the samehost. The authentication service (AS) that authenticates users and the ticket granting service(TGS) which takes tickets issued from the authentication service and issues tickets for services.This is done because of a simple security reason. After authentication at the authenticationservice both KDC and client share a secret symmetric key, which can be used to construct anauthenticator for the ticket granting service to obtain service tickets by the client. There is noneed for the client to enter the password a second time and the Ppassword has not been cached(which would be a security flaw). Both authentication service and ticket granting service revertto the same database of keys, which resides on every Kerberos server. The database containsevery key, user keys, which are derived from the users password using a hash algorithm andservice keys that are once generated by a random number generator and stored on the servicinghost as well. To improve security this service keys should be changed regularly.DEPT OF Comp Engg. 20 D.B.N.C.O.E.T,YTL
  • 21. KERBEROS5.3. Kerberized Services To take full advantage of a Kerberos infrastructure not only authentication for local hostaccess is done. An optimal environment is made up of services which support Kerberos, so thatthe user has to give his password one time he logs in. After that authentication the client can readhis email, access files on a file-server and log in on remote machines without giving hispassword a second time.DEPT OF Comp Engg. 21 D.B.N.C.O.E.T,YTL
  • 22. KERBEROS CHAPTER 6KERBEROS DATABASE Kerberos operations requiring both read-only and write access is done with the help ofKerberos database.Operations requiring read-only access to the Kerberos database are performedby the authentication service, which can run on both master and slave machines. (Fig 6.1) Fig 6.1. Authentication Requests. These operations are performed by the administration service, called the KerberosDatabase Management Service (KDBM). The current implementation stipulates that changesmay only be made to the master Kerberos database; slave copies are read-only. Therefore, theKDBM server may only run on the master Kerberos machine. (Fig 6.2) Fig 6.2. Administration Requests.DEPT OF Comp Engg. 22 D.B.N.C.O.E.T,YTL
  • 23. KERBEROS Note that, while authentication can still occur (on slaves), administration requests cannotbe serviced if the master machine is down. In our experience, this has not presented a problem,as administration requests are infrequent. The KDBM handles requests from users to change their passwords. The client side of thisprogram, which sends requests to the KDBM over the network, is the kpasswd program. TheKDBM also accepts requests from Kerberos administrators, who may add principals to thedatabase, as well as change passwords for existing principals. The client side of theadministration program, which also sends requests to the KDBM over the network, is the kadminprogram.6.1. The KDBM Server The KDBM server accepts requests to add principals to the database or change thepasswords for existing principals. This service is unique in that the ticket-granting service willnot issue tickets for it. Instead, the authentication service itself must be used (the same servicethat is used to get a ticket granting ticket). The purpose of this is to require the user to enter apassword. If this were not so, then if a user left her/his workstation unattended, a passerby couldwalk up and change her/his password for them, something which should be prevented. Likewise,if an administrator left her/his workstation unguarded, a passerby could change any password inthe system. When the KDBM server receives a request, it authorizes it by comparing theauthenticated principal name of the requester of the change to the principal name of the target ofthe request. If they are the same, the request is permitted. If they are not the same, the KDBMserver consults an access control list (stored in a file on the master Kerberos system). If therequester’s principal name is found in this file, the request is permitted, otherwise it is denied. By convention, names with a NULL instance (the default instance) do not appear in theaccess 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 theaccess control list. This convention allows an administrator to use a different password forDEPT OF Comp Engg. 23 D.B.N.C.O.E.T,YTL
  • 24. KERBEROSKerberos administration then s/he would use for normal login. All requests to the KDBMprogram, whether permitted or denied, are logged.6.2. Database Replication Each Kerberos realm has a master Kerberos machine, which houses the master copy ofthe authentication database. It is possible (although not necessary) to have additional, readonlycopies of the database on slave machines elsewhere in the system. The advantages of havingmultiple copies of the database are those usually cited for replication: higher availability andbetter performance. If the master machine is down, authentication can still be achieved on one ofthe slave machines. The ability to perform authentication on any one of several machines reducesthe probability of a bottleneck at the master machine. Keeping multiple copies of the databaseintroduces the problem of data consistency. We have found that very simple methods suffice fordealing with inconsistency. The master database is dumped every hour. The database is sent, inits entirety, to the slave machines, which then update their own databases. All passwords in the Kerberos database are encrypted in the master database key.Therefore, the information passed from master to slave over the network is not useful to anEaves dropper. However, it is essential that only information from the master host be acceptedby the slaves, and that tempering of data be detected, thus the checksum.DEPT OF Comp Engg. 24 D.B.N.C.O.E.T,YTL
  • 25. KERBEROS CHAPTER 7KERBEROS ADMINISTRATOR The Kerberos administrator’s job begins with running a program to initialize thedatabase. Another program must be run to register essential principals in the database, such asthe Kerberos administrator’s name with an admin instance. The Kerberos authentication serverand the administration server must be started up. If there are slave databases, the administratormust arrange that the programs to propagate database updates from master to slaves be kickedoff periodically. After these initial steps have been taken, the administrator manipulates thedatabase over the network. In particular, when a new Kerberos application is added to thesystem, the Kerberos administrator must take a few steps to get it working. The server must beregistered in the database, and assigned a private key (usually this is an automatically generatedrandom key). Then, some data (including the server’s key) must be extracted from the databaseand installed in a file on the server’s machine. The server uses the information in that file todecrypt messages sent encrypted in the server’s private key. The file authenticates the server as apassword typed at a terminal authenticates the user. The Kerberos administrator must also ensurethat Kerberos machines are physically secure, and would also be wise to maintain backups of theMaster database.DEPT OF Comp Engg. 25 D.B.N.C.O.E.T,YTL
  • 26. KERBEROS CHAPTER 8ANALYSIS OF KERBEROS8.1. Advantages1. Passwords are never sent across the network unencrypted. This prevents thoseunscrupulous people from being able to read the most important data sent over the network.2. Clients and applications services mutually authenticate. Mutual authentication allows forboth ends to know that they truly know whom they are communicating with.3. Tickets have a limited lifetime, so if they are stolen, unauthorized use is limited to thetime frame that the ticket is valid.4. Authentication through the AS only has to happen once. This makes the security ofKerberos more convenient.5. Shared secret keys between clients and services are more efficient than public-keys.6. Many implementations of Kerberos have a large support base and have been put throughserious testing.7. Authenticators, created by clients, can only be used once. This feature prevents the use ofstolen authenticators.8.2. Disadvantages1. Kerberos only provides authentication for clients and services.2. Kerberos 4 uses DES, which has been shown to be vulnerable to brute-force- attacks with little computing power.3. Like any security tool, it is also vulnerable to users making poor password choices.4. Because Kerberos uses a mutual authentication model, it is necessary for both client machines and service providers (servers) to be designed with Kerberos authentication in mind.DEPT OF Comp Engg. 26 D.B.N.C.O.E.T,YTL
  • 27. KERBEROS CHAPTER 9PERSPECTIVE: PUBLIC KEY CRYPTOGRAPHY A new direction for Kerberos is public key cryptography. Public key cryptography easeskey distribution a lot. Using only symmetric cryptography KDC and client must share a key;using asymmetric cryptography the client can present the public key, which can be used toencrypt messages for it. This is used for email communication by the program Pretty GoodPrivacy (PGP). The big advantage for Kerberos is that the key distribution center does not have to savethe keys client keys in his database any longer. To obtain a ticket granting ticket, the client has topresent his public key. The KDC uses this key to encrypt the ticket and session key. Aseverybody is able to create a key pair for public key cryptography, additional infrastructure isneeded. A trusted certification authority (CA) has to sign every valid public key. The client canpresent his key which is signed by the trusted authority. Integration in Kerberos is easy due to thefact that only interaction with the authentication service has to be changed to use asymmetriccryptography; everything else can remain as it is. If the client presents his public key, theauthentication service checks, whether it has a valid signature from a trusted authority and returna session key afterwards. The client decrypts the session key with the private key of his key pair.Following communication is handled like in Kerberos without public key cryptography support.DEPT OF Comp Engg. 27 D.B.N.C.O.E.T,YTL
  • 28. KERBEROS10. CONCLUSION Kerberos isn’t the only encryption protocol available. There are multiple ways to encryptdata, 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 forover 8 years, it is generally expected that the product should be well polished. Kerberos doesn’tfail to deliver, and this can be seen by looking at all the vendors who use it. Cisco, Microsoft,Apple, and many others rely on this faithful three headed dog for network security.Authentication is critical for the security of computer systems. Without knowledge of the identityof a principal requesting an operation, its difficult to decide whether the operation should beallowed. Traditional authentication methods are not suitable for use in computer networks whereattackers monitor network traffic to intercept passwords. The use of strong authenticationmethods that do not disclose passwords is imperative. The Kerberos authentication system iswell suited for authentication of users in such environments.DEPT OF Comp Engg. 28 D.B.N.C.O.E.T,YTL
  • 29. KERBEROS11. REFERENCES[1] Kerberos: Network Authentication System by Brain Pung.[2] Computer Networking by James Kurose and Keith Rose.[3] Introduction to kerberos technology[4] http://web.mit.edu/Kerberos/[5] http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci21243/7,00.html[6] http://www.google.co.in/DEPT OF Comp Engg. 29 D.B.N.C.O.E.T,YTL

×