Kerberos Infrastructure and Cross Realm Authentication
Kerberos: An Authentication
Service for Computer NetworksWhen using authentication based on cryptography, an attacker listening to thenetwork gains no information that would enable it to falsely claim another’sidentity. Kerberos is the most commonly used example of this type ofauthentication technology.* * *Modern computer systems provide service to multiple users and require theability to accurately identify the user making a request. In traditionalsystems, the user’s identity is verified by checking a password typed duringlogin; the system records the identity and uses it to determine whatoperations may be performed. The process of verifying the user’s identity iscalled authentication. Password based authentication is not suitable for useon computer networks. Passwords sent across the network can be intercepted andsubsequently used by eavesdroppers to impersonate the user. While thisvulnerability has been long known, it was recently demonstrated on a majorscale with the discovery of planted password collecting programs at criticalpoints on the Internet .
The introduction discussed the problems associated with password basedauthentication and, in particular, how passwords can be collected byeavesdropping. In addition to the security concern, password basedauthentication is inconvenient; users do not want to enter a password eachtime they access a network service. This has led to the use of even weakerauthentication on computer networks: authentication by assertion.While more convenient for the user, authentication by assertion hardlyqualifies as authentication at all. Examples include the Berkeley R-commandsuite and the IDENT protocol. With authentication by assertion, applicationsassert the identity of the user and the server believes it. Suchauthentication is easily thwarted by modifying the application. This mayrequire privileged access to the system, which is easily obtained on PCs andpersonal workstations. While most uses of authentication by assertion requirethat a connection originate from a “trusted” network address, on manynetworks, addresses are themselves simply assertions.Stronger authentication methods base on cryptography are required. When usingauthentication based on crytography, an attacker listening to the networkgains no information that would enable it to falsely claim another’s identity.Kerberos is the most commonly used example of this type of authenticationtechnology. Unfortunately, strong authentication technologies are not used asoften as they should be, although the situation is gradually improving.
The Kerberos Authentication Service
Kerberos is a distributed authentication service that allows a process (aclient) running on behalf of a principal (a user) to prove its identity to averifier (an application server, or just server) without sending data acrossthe network that might allow an attacker or the verifier to subsequentlyimpersonate the principal. Kerberos optionally provides integrity andconfidentiality for data sent between the client and server. Kerberos wasdeveloped in the mid-’80s as part of MIT’s Project Athena . As use ofKerberos spread to other environments, changes were needed to support newpolicies and patterns of use. To address these needs, design of Version 5 ofKerberos (V5) began in 1989 . Though V4 still runs at many sites, V5 isconsidered to be standard Kerberos.
How Kerberos works
The Kerberos Authentication System  uses a series of encrypted messages toprove to a verifier that a client is running on behalf of a particular user.The Kerberos protocol is based in part on the Needham and Schroederauthentication protocol , but with changes to support the needs of theenvironment for which it was developed. Among these changes are the use oftimestamps to reduce the number of messages needed for basic authentication, the addition of a “ticket-granting” service to support subsequentauthentication without re-entry of a principal’s password, and differentapproach to cross-realm authentication (authentication of a principalregistered with a different authentication server than the verifier).The remainder of this section describes the Kerberos protocol. The descriptionis simplified for clarity; additional fields are present in the actualprotocol. Readers should consult RFC 1510  for a more thoroughdescription of the Kerberos protocol.
Though conceptually, Kerberos authentication proves that a client is runningon behalf of a particular user, a more precise statement is that the clienthas knowledge of an encryption key that is known by only the user and theauthentication server. In Kerberos, the user’s encryption key is derived fromand should be thought of as a password; we will refer to it as such in thisarticle. Similarly, each application server shares an encryption key with theauthentication server; we will call this key the server key.Encryption in the present implementation of Kerberos uses the data encryptionstandard (DES). It is a property of DES that if ciphertext (encrypted data) isdecrypted with the same key used to encrypt it, the plaintext (original data)appears. If different encryption keys are used for encryption and decryption,or if the ciphertext is modified, the result will be unintelligible, and thechecksum in the Kerberos message will not match the data. This combination ofencryption and the checksum provides integrity and confidentiality forencrypted Kerberos messages.
The Kerberos Ticket
The client and server do not initially share an encryption key. Whenever aclient authenticates itself to a new verifier it relies on the authenticationserver to generate a new encryption key and distribute it securely to bothparties. This new encryption key is called a session key and the Kerberosticket is used to to distribute it to the verifier.The Kerberos ticket is a certificate issued by an authentication server,encrypted using the server key. Among other information, the ticket containsthe random session key that will be used for authentication of the principalto the verifier, the name of the principal to whom the session key was issued,and an expiration time after which the session key is no longer valid. Theticket is not sent directly to the verifier, but is instead sent to the clientwho forwards it to the verifier as part of the application request. Becausethe ticket is encrypted in the server key, known only by the authenticationserver and intended verifier, it is not possible for the client to modify theticket without detection.
Authentication request and response
The client requires a separate ticket and session key for each verifier withwhich it communicates. When a client wishes to create an association with aparticular verifier, the client uses the authentication request and response,messages 1 and 2 from figure 1, to obtain a ticket and session key from theauthentication server. In the request, the client sends the authenticationserver its claimed identity, the name of the verifier, a requested expirationtime for the ticket, and a random number that will be used to match theauthentication response with the request.In its response, the authentication server returns the session key, theassigned expiration time, the random number from the request, the name of theverifier, and other information from the ticket, all encrypted with the user’spassword registered with the authentication server, together with a ticketcontaining similar information, and which is to be forwarded to the verifieras part of the application request. Together, the authentication request andresponse and the application request and response comprise the basic Kerberosauthentication protocol.
Kerberos Infrastructure and Cross-Realm Authentication
In a system that crosses organizational boundaries, it is not appropriate forall users to be registered with a single authentication server. Instead,multiple authentication servers will exist, each responsible for a subset ofthe users or servers in the system. The subset of the users and serversregistered with a particular authentication server is called a realm (if arealm is replicated, users will be registered with more than oneauthentication server). Cross-realm authentication allows a principal to proveits identity to a server registered in a different realm.To prove its identity to a server in a remote realm, a Kerberos principalobtains a ticket granting ticket for the remote realm from its localauthentication server. This requires the principals’s local authenticationserver to share a cross-realm key with the verifier’s authentication server.The principal next uses the ticket granting exchange to request a ticket forthe verifier from the verifier’s authentication server, which detects that theticket granting ticket was issued in a foreign realm, looks up the cross-realmkey, verifies the validity of ticket granting ticket, and issues a ticket andsession key to the client. The name of the client, embedded in the ticket,includes the name of the realm in which the client was registered.With Version 4, it was necessary for an authentication server to register withevery other realm with which cross-realm authentication was required. This wasnot scalable; complete interconnection required the exchange of n^2 keys wheren was the number of realms.In contrast, Version 5 supports multi-hop cross-realm authentication, allowingkeys to be shared hierarchically. With V5, each realm shares a key with itschildren and parent, i.e. the ISI.EDU realm shares a key with the EDU realmwhich also shares keys with MIT.EDU, USC.EDU and WASHINGTON.EDU. If no key isshared directly by ISI.EDU and MIT.EDU, authentication of the clientbcn@ISI.EDU to a server registered with the MIT.EDU realm proceeds byobtaining a ticket granting ticket for EDU from the ISI.EDU authenticationserver, using that ticket granting ticket to obtain a ticket granting ticketfor the MIT.EDU realm from the EDU authentication server, and finallyobtaining a ticket for the verifier from the MIT.EDU authentication server.The list of realms that are transited during multi-hop cross-realmauthentication is recorded in the ticket and the verifier accepting theauthentication makes the final determination about whether the path that wasfollowed should be trusted. Shortcuts through the hierarchy are supported andcan improve both the trust in and the performance of the authenticationprocess.This hierarchical organization of realms is similar to the hierarchicalorganization of certification authorities and certificate servers for public-key cryptography . As with the public key certification hierarchy, theutility of the authentication infrastructure supporting authentication betweenparties not previously known to one another depends in part on theavailability of authentication servers for realms near the top of thehierarchy. Unfortunately, political and legal ambiguity has the potential toslow the establishment of these realms. In the mean time, pairwiserelationships between regions of the hierarchy (shortcuts) are important. Adiscussion of the tradeoffs available when establishing realms for largeorganizations can be found in .
Several utility programs must be installed on the workstation to allow usersto obtain Kerberos credentials (kinit), destroy credentials (kdestroy), listcredentials (klist), and change their Kerberos password (kpasswd). Some siteschoose to integrate the Kerberos login tool “kinit” with the workstationlogin program so that users do not need to type their password twice. Thismakes the use of Kerberos nearly transparent; users may not even be aware theyare using Kerberos.
Using “Kerberized” applications
Client/server applications must be modified to use Kerberos forauthentication; such Kerberos-aware applications are said to be Kerberized.Kerberizing an application is the most difficult part of installing Kerberos.Fortunately, the MIT reference implementation includes versions of popularapplications (the Berkeley R-commands, telnet, and POP) with support forKerberos already added. Other applications have been Kerberized by vendors andare included in their supported products. The availability of Kerberos-awareapplications has improved with time, and is expected to improve further.However, a site would have to arrange itself to add Kerberos support to anyapplication developed in-house.It is generally necessary to modify the client/server protocol whenKerberizing an application unless the protocol designer has already madeprovisions for an authentication exchange. The application program mustgenerate and send a Kerberos application request to the application serverduring the protocol initialization phase, and the server must verify theKerberos authentication information. The request must be transmitted withinthe client/server protocol. The Kerberos library provides routines thatgenerate and verify these messages.More recent implementations of Kerberos provide a Generic Security ServicesApplication Programmer Interface (GSSAPI) . The GSSAPI provides a standardprogramming interface which is authentication mechanism independent. Thisallows the application programmer to design an application and applicationprotocol which can used alternative different authentication technologies,including Kerberos. The use of the GSSAPI in application programs isrecommended wherever possible.Because it is a generic authentication interface, the GSSAPI does not supportall of the functionality provided by Kerberos. For example, Kerberos’s notionof user-to-user authentication is not currently supported. Hence, anapplication programmer will not always be able to use the GSSAPI in all cases,and may have to use the Kerberos API in order to use some features.
How authentication is used
User authentication occurs within most human-to-computer interactions outsideof guest accounts, automatically logged-in accounts and kiosk computersystems. Generally, a user has to choose a username or user ID and provide avalid password to begin using a system. User authentication authorizes human-to-machine interactions in operating systems and applications, as well as bothwired and wireless networks to enable access to networked and internet-connected systems, applications and resources.Many companies use authentication to validate users who log into theirwebsites. Without the right security measures, user data, such as credit anddebit card numbers, as well as Social Security numbers, could get into thehands of cybercriminals.Organizations also use authentication to control which users have access tocorporate networks and resources, as well as to identify and control whichmachines and servers have access. Companies also use authentication to enableremote employees to securely access their applications and networks.For enterprises and other large organizations, authentication may beaccomplished using a single sign-on (SSO) system, which grants access tomultiple systems with a single set of login credentials.
User authentication vs. machine authentication
Machines also need to authorize their automated actions within a network.Online backup services, patching and updating systems and remote monitoringsystems, such as those used in telemedicine and smart grid technologies, allneed to securely authenticate to verify that it is the authorized systeminvolved in any interaction and not a hacker.Machine authentication can be carried out with machine credentials much like auser’s ID and password only submitted by the device in question. They can alsouse digital certificates issued and verified by a certificate authority aspart of a public key infrastructure to prove identification while exchanginginformation over the internet, like a type of digital password.With the increasing number of internet-enabled devices, reliable machineauthentication is crucial to enable secure communication for home automationand other internet of things applications, where almost any entity or objectmay be made addressable and able to exchange data over a network. It isimportant to realize that each access point is a potential intrusion point.Each networked device needs strong machine authentication and also, despitetheir normally limited activity, these devices must be configured for limitedpermissions access as well, to limit what can be done even if they arebreached.Phishing – Wikipedia