Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
2Activity
0 of .
Results for:
No results containing your search query
P. 1
Risk Assessment of Authentication Protocol: Kerberos

Risk Assessment of Authentication Protocol: Kerberos

Ratings: (0)|Views: 318 |Likes:
Published by ijcsis
Kerberos is a well-established authentication system. As new authentication methods arise, incorporating them into Kerberos is desirable. However, extending Kerberos poses challenges due to a lack of source code availability for some implementations and a lengthy standardization process. This proposal presents important functions, strengths and weakness in Kerberos. It details out design issues, limitations and risks associated with Kerberos. This proposal also explains one more aspect that is “extensibility” with Kerberos. This proposal also briefs Kerberos enhancements for using public-key cryptography. It discusses scalability and security needs & how public-key helps in accomplishing these goals. At the end it focuses on commercial application/services those uses Kerberos rigidly. This proposal on pre-authentication. A Pre-Authentication in Kerberos (EPAK) is Kerberos extension which enables many authentication methods to be loosely coupled with Kerberos, without further modification to Kerberos. Why pre-authentication is necessary? An attacker usually impersonates user by obtaining authentication responses & performs offline dictionary attacks against the encrypted data, this is a likely attack with Kerberos. Thus “pre-authentication” can lower the possibility for offline password-guessing attacks. We also discuss two prototype examples to understand flexibility Kerberos using EPAK .It uses public key approach which is very resource consuming but in the era of wireless communication and mobile devices we need to find the light weight application. Kerberos has grown to become the most widely deployed system for authentication and authorization in modern computer networks. Kerberos is currently shipped with all major computer operating systems and is uniquely positioned to become a universal solution to the distributed authentication and authorization problem of communicating parties.
Kerberos is a well-established authentication system. As new authentication methods arise, incorporating them into Kerberos is desirable. However, extending Kerberos poses challenges due to a lack of source code availability for some implementations and a lengthy standardization process. This proposal presents important functions, strengths and weakness in Kerberos. It details out design issues, limitations and risks associated with Kerberos. This proposal also explains one more aspect that is “extensibility” with Kerberos. This proposal also briefs Kerberos enhancements for using public-key cryptography. It discusses scalability and security needs & how public-key helps in accomplishing these goals. At the end it focuses on commercial application/services those uses Kerberos rigidly. This proposal on pre-authentication. A Pre-Authentication in Kerberos (EPAK) is Kerberos extension which enables many authentication methods to be loosely coupled with Kerberos, without further modification to Kerberos. Why pre-authentication is necessary? An attacker usually impersonates user by obtaining authentication responses & performs offline dictionary attacks against the encrypted data, this is a likely attack with Kerberos. Thus “pre-authentication” can lower the possibility for offline password-guessing attacks. We also discuss two prototype examples to understand flexibility Kerberos using EPAK .It uses public key approach which is very resource consuming but in the era of wireless communication and mobile devices we need to find the light weight application. Kerberos has grown to become the most widely deployed system for authentication and authorization in modern computer networks. Kerberos is currently shipped with all major computer operating systems and is uniquely positioned to become a universal solution to the distributed authentication and authorization problem of communicating parties.

More info:

Published by: ijcsis on Jul 07, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/24/2012

pdf

text

original

 
Risk Assessment of Authentication Protocol:Kerberos
 
Pathan Mohd. Shafi
1
, Dr Abdul sattar
2
, Dr. P. chenna Reddy
3
 
1
Smtg Kashibai Navale College of Engineering,Pune
2
Royal Institute of Technology and Science R. R. Dist.3
 
JNTU College of Engineering, Pulivendula.
 
 Abstract
Kerberos is a well-established authenticationsystem. As new authentication methods arise, incorporatingthem into Kerberos is desirable. However, extendingKerberos poses challenges due to a lack of source codeavailability for some implementations and a lengthystandardization process.This proposal presents important functions, strengths andweakness in Kerberos. It details out design issues,limitations and risks associated with Kerberos. Thisproposal also explains one more aspect that is“extensibility” with Kerberos. This proposal also briefsKerberos enhancements for using public-key cryptography.It discusses scalability and security needs & how public-keyhelps in accomplishing these goals. At the end it focuses oncommercial application/services those uses Kerberos rigidly.This proposal on pre-authentication. A Pre-Authentication in Kerberos (EPAK) is Kerberos extensionwhich enables many authentication methods to be looselycoupled with Kerberos, without further modification toKerberos. Why pre-authentication is necessary? Anattacker usually impersonates user by obtainingauthentication responses & performs offline dictionaryattacks against the encrypted data, this is a likely attackwith Kerberos. Thus “pre-authentication” can lower thepossibility for offline password-guessing attacks. We alsodiscuss two prototype examples to understand flexibilityKerberos using EPAK .It uses public key approach which isvery resource consuming but in the era of wirelesscommunication and mobile devices we need to find the lightweight application.Kerberos has grown to become the most widely deployedsystem for authentication and authorization in moderncomputer networks. Kerberos is currently shipped with allmajor computer operating systems and is uniquelypositioned to become a universal solution to the distributedauthentication and authorization problem of communicating parties.
I.
 
I
NTRODUCTION
 Authentication is critical for the security Computersystems. Without knowledge of a principal requesting anoperation, it is difficult to decide whether the operationshould be allowed. Traditional authentication methods arenot suitable for use in computer networks where attackersmonitor network traffic to intercept passwords. The useof strong authentication methods that do not disclosepasswords is imperative. The Kerberos authenticationsystem is well suited for authentication of users in suchenvironmentsKerberos is a system of authentication developed at MIT(Massachusetts Institute of Technology) as part of theAthena project. Steve Miller and Clifford Neuman areprimary designers of Kerberos version 4 (Published year -1980)Although they had targeted it primarily for projectAthena, Version 5 designed by John Kohl and CliffordNeuman ,appeared as PFC 1510 in 1993,with intention of overcoming the limitations and security problems of version 4.The Kerberos protocol involves use of a trusted thirdparty known as the Key Distribution Center (KDC) tonegotiate shared session keys between clients andservices and provide mutual authentication between them.Kerberos differs from many other distributed securitysystems in its ability to incorporate a very wide range of security technologies and mechanisms. Kerberos hasrisen from a well-respected authentication standard to aleading security infrastructure component in recent years,for example Microsoft announced that Microsoft ActiveDirectory would support the protocol for authenticationpurposes within Windows Primary Domain Controllers.MOTIVATIONToday, open & distributed architectures are widely usedacross organizations, companies, offices & IT services. Ingeneral such open & distributed environments consist of dedicated workstations and distributed or centralizedservers. In open environment user requires to proveidentity for each service invoked, and in turn server(s)also require proving their identity to clients. The processof verifying the user's identity is called authentication.Traditional Kerberos provides a centralizeauthentication server whose function is to authenticateusers to servers and servers to users. The authenticationservice in open environments can made more secure byenhancing or extending Kerberos. New authenticationsystems need to integrate more easily into Kerberos toincrease their usability and performance withoutchanging existing Kerberos base security framework.UNDERSTANDING KERBEROS
 
Kerberos is a network authentication protocol based onconventional cryptography that relies on symmetricalcryptographic algorithms that use the same key forencryption as for decryption. Network authenticationprotocols do two things: help you discover who is on theother end of the wire, and help you and your peerexchange a cryptographic key (also known as a session
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 6, June 2011183http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
key) so you can maintain integrity and confidentialityprotection for the ensuing conversation.Figure 1. Kerberos overviewExchange between the client and the Kerberos AS(Authentication Server) in messages 1 and 2 are usedonly when the user first logs in to the system. Exchangebetween the client and the Kerberos TGS (TicketGranting Server) in Messages 3 and 4 are used whenevera user authenticates to a new server. Message 5 is usedeach time the user authenticates itself to a server. Andfinally, Message 6 is the mutual-authentication responseby the serverHOW IT WORKS?It basically involves THREE primary phases when aclient wishes to authenticate to an application server.
Phase 1: LOGIN / Requesting ticket granting ticket(TGT)
In the first phase, the client sends a request to theKerberos Authentication Server (AS) requesting a ticketgranting ticket ticket(tgs) to be used in the second phasewith the Ticket Granting Server (TGS). The AS isexpected to reply with a message consisting of a ticketgranting ticket ticket(tgs) of lifetime lifetime2 and anencrypted component containing a fresh session keyKc,tgs to be shared between the client and the TGS.Another copy of this session key is contained in theTicket granting ticket and is encrypted using the long-term secret key of the TGS Ktgs which is shared betweenTGS and Kerberos infrastructure (the AS can access thedatabase of Kerberos infrastructure). The informationdirected to the client is encrypted under the client's long-term secret key KC.
Phase 2: Requesting service granting ticket (SGT)
 
In the second phase, the client forwards the ticketgranting ticket, along with an authenticatorAuthenticatorC1 encrypted with the session key
Kc,tgs
 obtained in the first phase, to the TGS, requesting aservice ticket to be used in the third phase with theapplication server. The TGS is expected to reply with amessage consisting of an application server ticket ticketVof lifetime lifetime4 and an encrypted componentcontaining a fresh session key
Kc,v
to be shared betweenthe client and the application server. Another copy of thissession key is contained in the application server ticket
ticketV
and is encrypted using the long-term secret keyof the application server KV which is shared between theapplication server and the Kerberos infrastructure (theTGS can access the database of the Kerberosinfrastructure). The information directed to the client isencrypted with the session key of the first stage
Kc,tgs
.
Phase 3: Contacting application server / Requestingspecific service
Figure 2 - Kerberos authentication dialogIn the third phase, the client forwards the applicationserver ticket
ticketV
, along with a new authenticatorAuthenticatorC2 encrypted with the session key obtainedin the second phase
Kc,v
, to the application server,requesting certain service. The application server ticketplus the secret session key are the client's credentials tobe authenticated to a specific application server. If allcredentials are valid, the application server willauthenticate the client and provide the service. Theacknowledgement message from the application server isoptional and used only when the system requires mutualauthentication by the application server.II. ANALYSIS OF KERBEROS WEAKNESSES
Vulnerability to password guessing attacks -
Kerberos is vulnerable to password guessing attacks. TheKerberos message includes material encrypted with a keybased on the client's password. An opponent can capturethis message and attempt to decrypt it by trying variouspasswords. If the result of a test decryption is of theproper form, then the opponent has discovered the client'spassword and may subsequently use it to gainauthentication credentials from Kerberos.
Dependency on system clock synchronization –
Thesystem clock 
 
of the hosts that are involved in the protocolshould be synchronized. The tickets have a timeavailability period and if the host clock is notsynchronized with the Kerberos server clock, theauthentication will fail. In practice, Network TimeProtocol daemons are usually used to keep the host clockssynchronized.
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 6, June 2011184http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
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

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->