Continuous availability of the KDC
- Kerberosrequires continuous availability of the KDC. When theKDC is down, the system will suffer from the single pointof failure problem. This can be mitigated by usingmultiple Kerberos servers.
Lack of standards to explain administration
- Thereare no standards to explain the administration of theKerberos protocol. This will differ between serverimplementationsDESIGN CHALLENGES
Deciding appropriate lifetime for a ticket
-The ticket lifetime problem is a puzzle situationbetween security and convenience. If the life of a ticket islong, then if a ticket and its associated session key arestolen or misplaced, they can be used for a longer periodof time. Such information can be stolen if a user forgetsto log out of a public workstationIf a user has been authenticated on a system that allowsmultiple users, a “super user” or a user having access as“root user” might be able to find the information neededto use stolen tickets (of other users).Also, the obvious problem with giving a ticket a shortlifetime is that when it expires the user will have to obtaina new ticket. In this case it requires the user to enter thepassword again.
Allowing proxies requests / proxy services / on-behalf services-
How can an authenticated user allow a server to acquireother network services on her/his behalf? An openproblem is the proxy problem. This is applicable forscenarios when authentication forwarding is not desirablebut still remote accesses are needed.An example of this problem is what we callauthentication forwarding. If a user is logged into aworkstation and logs in to a remote host, it would be niceif the user can access to the local data (workstation data)while running a program on the remote host. What makesthis difficult is that the user might not trust the remotehost, thus authentication forwarding is not desirable in allcases.
How to guarantee workstation integrity:
Another problem, and one that is important in the Athenaenvironment, is how to guarantee the integrity of thesoftware running on a workstation. This is not so much of a problem on private workstations since the user that willbe using it has control over it. On public workstations,however, someone might have come along and modifiedthe login program to save the user's password. The onlysolution presently available in our environment is tomake it difficult for people to modify software running onthe public workstations.
POSSIBLE AREAS FOR MINIMIZING RISKS
MINIMIZE RISKS WITH OPTIMUM OVERHEADS
•
Kerberos Database Replication:
Each Kerberos realm has a master Kerberosmachine, which houses the master copy of theauthentication database. To meet high availabilityrequirements there can be additional, read-only copies of the database on slave machines elsewhere in the system.The advantages of having multiple copies of thedatabase are higher availability and better performance. If the master machine is down, authentication can still beachieved on one of the slave machines. The ability toperform authentication on any one of several machinesreduces the probability of a bottleneck at the mastermachine
•
Load Balance Kerberos Authentication Servers:
To scale performance, clustering technology can beused for Kerberos servers. Once the architecture isproperly designed to use clustering technology, incomingIP traffic can be distributed across multiple cluster hosts.If one of the cluster systems fails, network architecture should support in detecting the failure on thefly. The requests can be automatically redistributedsurviving hostsThere are different ways to look at this unique problemin real world. One of the way to sort this issues is bykeeping keys independent of passwords. As the keys arenot at all derived from password, there is no easy way tocrack the key code and or read the contents, thus we canpossibly eliminate password guessing attacks.The principal’s secret key will be independent of theuser password to overcome the weak passwords chosenby the network principals that are susceptible to passwordguessing attacks, the main drawback of Kerberosprotocol. Instead the Kerberos distribution center saves aprofile for every instance in its realm to generate theprincipal secret key by hashing the profile, andencrypting the output digest
III. KERBEROS EXTENSION THROUGH PUBLICKEY (PKINIT)Authentication in Kerberos (PKINIT)Microsoft, CyberSafe and Heimdal have all adoptedPKINIT in their implementations of Kerberos. Thespecification defines how public-key cryptography can beused to secure the initial authentication procedure.Steps:i. The KDC receives AS_REQ and verifies theclient’s digital signatureii.The KDC encrypts the TGT using the client’spublic key, and transmit it in AS_REP. This message issigned by the KDC with its private key.iii.The client validates AS_REP using KDC’s publickeyiv. TGT.v.The client proceeds with standard symmetriccryptography and secret keys.IV.
KERBEROS EXTESIONS IN REAL WORLD1. ACTIVE DIRECTORY IMPLEMENTATIONSUSING KERBEROS“Kerberos has replaced NTLM as the defaultauthentication protocol in an Active Directory basedsingle sign-on scheme, Kerberos is an integral part of Windows Active Directory implementations”
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 6, June 2011185http://sites.google.com/site/ijcsis/ISSN 1947-5500