16.2 AUTHENTICATION AND KEY DISTRIBUTION SYSTEMS

Team-Fly

16.2 AUTHENTICATION AND KEY DISTRIBUTION SYSTEMS

In the late 1980s and early 1990s, a considerable amount of research and development was dedicated to authentication and key distribution systems that could be used to secure arbitrary network applications. Examples include:

  • Kerberos, developed at MIT;

  • Network Security Program (NetSP), developed by IBM;

  • SPX, developed by Digital Equipment Corporation (DEC);[11]

  • The Exponential Security System (TESS), developed at the University of Karlsruhe.

In addition, several extensions to the Kerberos authentication system have been developed, such as Yaksha, a Secure European System for Applications in a Multi-vendor Environment (SESAME), and the Distributed Computing Environment (DCE) developed by the Open Group.[12] In this section we are not going to describe and discuss all of these systems. Instead, we refer to [29] for a comparative overview.

Among the authentication and key distribution systems mentioned here, only Kerberos and SESAME are still in use. In addition, a Kerberos implementation is used in Windows 2000 to provide a single sign-on service. Kerberos, SESAME, and Windows 2000 are overviewed next.

16.2.1 Kerberos

The authentication and key distribution system Kerberos[13] [30-32] was originally developed at MIT to protect the emerging network services provided by the Athena project [33, 34]. The aim of the Kerberos system was to extend the notion of authentication to the computing and networking environment at MIT. According to Project Athena's technical plan [35], this environment consisted of public and private workstations, centrally operated server systems, and a campus network that interconnects the various components. In this environment, the primary security threats resulted from the potential of a user to forge the identity of another user in order to gain unauthorized access to system resources. These and similar threats are still relevant in many contemporary computing and networking environments.

The first three versions of the Kerberos system were used only at MIT. The first version that was made publicly available was Kerberos version 4 (Kerberos V4), and this version has achieved widespread use beyond MIT.[14] Officially released in December 1992, MIT Kerberos V4 is in its final state. In fact, MIT does not anticipate ever making a new Kerberos V4 software release in the future.

Some sites require functionality that Kerberos V4 does not provide, while others have a computing and networking environment or administrative procedures that differ from those at MIT. In addition, Steven Bellovin and Michael Merrit published a paper describing some shortcomings and limitations of Kerberos V4 in 1990 [36]. Against this background, work on Kerberos version 5 (V5) commenced in 1989, also fueled by discussions with Kerberos V4 users and administrators about their experience with the Kerberos model in general, and the MIT reference implementation in particular. In September 1993, Kerberos V5 was officially specified in RFC 1510 [37], and as such it was submitted to the Internet standards track.[15] Again, MIT provided a publicly and freely available Kerberos V5 reference implementation.

It should be noted that Kerberos V4 and V5, although conceptually similar, are substantially different from one another, and are even competing for dominance in the marketplace. In short, Kerberos V4 has a greater installed base, is simpler, and has better performance than V5, but works only with IP addresses; whereas Kerberos V5 has a smaller installed base, is less simple and thus less efficient, but provides more functionality than V4. For the purpose of this book, we simplify the Kerberos system and protocol considerably. This simplified form of Kerberos is equally valid for Kerberos V4 and V5. Further and more detailed information can be obtained from Chapter 2 of [29] or [38]. Also, the Kerberos home pages at MIT[16] and the Information Sciences Institute (ISI)[17] of the University of Southern California provide good sources of information. In particular, there is a document originally written by Bill Bryant in 1988. Entitled "Designing an Authentication System: A Dialogue in Four Scenes," the document introduces and discusses the considerations and decisions that led to Kerberos V4 design. The document is highly recommended reading and can be downloaded from the MIT Kerberos home page[18] and many other sites related to network security.

Kerberos is based on authentication and key distribution protocols that were originally proposed in [39, 40] and later modified to use time stamps [41]. In the Kerberos model and terminology, an administration domain is called a realm. It is assumed that every company or organization that runs the Kerberos system establishes a realm that is uniquely identified by a realm name. Also, Kerberos is based on the client-server model. Users, clients, and servers implementing and providing specific network services are considered as principals, and each principal is uniquely identified by a principal identifier.

The aim of Kerberos is to allow a client acting on behalf of a user to authenticate (i.e., prove its identity) to a service (i.e., an application server) without having to send authentication information in the clear across the network. Also, user authentication should be empowered by passwords, but the use of the passwords should be minimized (i.e., they should be used only once during the single sign-on processes). To achieve these goals, the Kerberos system requires the existence of a TTP that acts as KDC. The KDC, in turn, consists of two logically separated components:

  • An authentication server (AS);

  • A set of ticket-granting servers (TGSs).

Note that the AS and the TGSs are only logically separated components and that they may be processes running on the same machine. Also note that the machines that provide these services must be carefully protected and located in physically secure environments. If an intruder is able to subvert either the AS or any of the TGSs, he or she may compromise the entire system at will.

The KDC maintains a database that includes an entry for every principal registered in the Kerberos realm. The information a Kerberos KDC stores for each principal P includes (but is not restricted to) the following two items:

  • The principal identifier of P;

  • The key Kp that is shared between P and the KDC (e.g., a password if P is a user);

For obvious reasons, the confidentiality of the keys (i.e., Kp for each principal P) must be protected. The Kerberos system therefore encrypts all keys with a KDC master key. This encryption allows a system manager to remove copies of the KDC database from the master server, and send copies thereof to slave servers without going to extraordinary lengths to protect the privacy of the copies. Slave servers are required in large realms to provide a highly available Kerberos authentication service. Note that Kerberos does not store the KDC master key in the same database, but manages that key separately.

In prinicple, Kerberos implements a ticketing system. What this basically means is that a central authority (i.e., the KDC) issues tickets that clients and servers can use to mutually authenticate themselves and to agree on a shared secret. The shared secret, in turn, can then be used for subsequent data authentication and encryption. In either case, a Kerberos ticket is a data record that is issued by the Kerberos KDC. Among other things, the ticket contains:

  • The session key that will be used for authentication between the client and the server;

  • The name of the principal to whom the session key was issued;

  • An expiration time after which the session key is no longer valid.

The ticket is not sent directly to the server, but instead sent to the client who forwards it to the server as part of an authentication exchange. A Kerberos ticket is always encrypted with the server key, known only to the AS and the intended server. Because of this encryption, it is not possible for the client to modify the ticket without detection. There are two types of tickets:

  • Ticket-granting tickets (TGTs) are issued by the Kerberos As and can be used to request service tickets from a TGS;

  • Service tickets, or tickets, in turn, are issued by a TGS and can be used to authenticate to specific server systems.

During the duration of a typical session, a TGT is usually obtained first. The TGT is then locally stored on the client (instead of the user's password) and used to request service tickets for each and every server system the client must authenticate to.

Figure 16.1 illustrates the Kerberos system and the corresponding protocol steps. The six steps can be be formalized as follows:

  1. : C AS : KRB_AS_REQ(U,TGS,L1, N1)

  2. : AS C : KRB_AS_REP(U,Tc,tgs, {TGS, K, Tstart, Texpire, N1} KU)

  3. : C TGS : KRB_TGS_REQ(S, L2, N2, Tc,tgs, Ac,tgs)

  4. : TGS C : KRB_TGS_REP(U, Tc,s, {S,K, Tstart, Texpire, N2}K)

  5. : C S : KRB_AP_REQ(Tc,s, Ac,s)

  6. : S C : KRB_AP_REP({T}K)

click to expand
Figure 16.1: The Kerberos system and the corresponding protocol steps.

Furthermore, the six steps can be grouped in three exchanges:

  • The AS exchange between the client and the AS (steps 1 and 2);

  • The TGS exchange between the client and the TGS (steps 3 and 4);

  • The AP exchange between the client and the application server (steps 5 and 6).

Obviously, the AS exchange must be performed only once during the login process, whereas the TGS exchange and the AP exchange must be performed for each server the client wants to access (if the server requires authentication).

When a user U wants to sign on a Kerberos realm, he or she has a client C send a KRB_AS_REQ (Kerberos authentication server request) message to the AS of the Kerberos KDC in step 1. The message basically includes the principal identifier for U, the identifier for a TGS, a desired lifetime L1 for the TGT, and a randomly chosen nonce N1.

After having received the KRB_AS_REQ message, the AS looks up and extracts the secret keys for both U and the TGS. If required, the AS preauthenticates the request, and if preauthentication fails, a corresponding error message is returned to C. Otherwise, the AS randomly selects a new session key K, and returns a KRB_AS_REP message to C in step 2. The message includes U, a TGT Tc,tgs = {U, C, TGS, K, Tstart,Texpire} Ktgs, and {TGS, K, Tstart, Texpire, N1} KU. The TGT's start and expiration times Tstart and Texpire are set in accordance with the realm's security policy in a way that fits the specified lifespan L1 of the KRB_AS_REQ message.

After having received the KRB_AS_REP message in step 2, C applies a well-known one-way hash function h to the user-provided password pwdU to compute the user's master key KU = h(pwdU).[19] Equipped with this key, C can decrypt {TGS, K, Tstart, Texpire} KU, and extract TGS, K, Tstart, and Texpire accordingly. C is now in the possession of a TGT that is valid from Tstart to Texpire. It can use this TGT to request service tickets from the TGS for any server S in the realm. Note that in a TGT, a lifetime is used like a password expiration time. Limiting the lifetime of a TGT thus limits the amount of damage that can be caused by a compromise of the TGT. In Kerberos, there is generally no possibility to revoke a TGT once it has been issued. Thus, limiting the TGT lifetime implicitly sets a deadline after which the TGT becomes obsolete.

Before initiating a TGS exchange, C must determine in which realm the application server he or she will request a ticket for what has been registered. If C does not already possess a TGT for that realm, C must obtain one. This is first attempted by requesting a TGT for the destination realm from the local Kerberos server (using the KRB_TGS_REQ message recursively). The Kerberos server may return a TGT for the desired realm, in which case C can proceed. Alternatively, the Kerberos server may also return a TGT for a realm which is closer to the desired realm, in which case this step must be repeated with a Kerberos server in the realm specified in the returned TGT. If neither is returned, the request must be retried with a Kerberos server for a realm higher in the hierarchy. This request will itself require a TGT for the higher realm, which must be obtained by recursively applying these directions. Once the client obtains a TGT for the appropriate realm, it determines which Kerberos servers serve that realm, and contacts one. The list might be obtained through a configuration file or a corresponding network service.

In step 3, C sends a KRB_TGS_REQ (Kerberos ticket-granting server request) message to the TGS. The message includes the principal identifier S for the server, a requested lifetime L2 for the service ticket, a nonce N2, the TGT Tc,tgs, and an authenticator Ac,tgs, to prove legitimate ownership of the TGT. Ac,tgs can be regarded as the principal identifier of C and a time stamp, both of them encrypted with the session key K: Ac,tgs = {C,T} K. Note that Tc,tgs can have a comparably long lifetime, and could be eavesdropped and replayed. The purpose of the authenticator is thus to show that C holds the secret key, and to thwart this kind of attack. Also note that the use of authenticators generally requires that principals on the network keep reasonably synchronized time. The times can be off by some amount. The allowable time skew is independently set at each server, and therefore some servers may be configured to be fussier than others about times being close. The allowed time skew is usually set to be accurate within 5 minutes without undue administrative burden. In practice, that assumption has turned out to be more problematic than expected. Distributed time services, once deployed, make much tighter synchronization possible.

The KRB_TGS_REQ message is processed in a manner similar to that of the KRB_AS_REQ message, but there are some additional checks to be performed. In step 4, the TGS returns a KRB_TGS_REP message (Kerberos ticket-granting server reply) that shares its format with the KRB_AS_REP message. It includes the principal identifier for the user, a ticket Tc,s for the requested server S, and an expression (i.e., {S, K, Tstart, Texpire, N2}) encrypted with K. Again, the client can use K to decrypt the expression and to extract the identifier for the server, the new session key K' (which the client uses to talk to the server), a lifetime for the ticket, and the nonce N2.

When the KRB_TGS_REP is received by C, it is processed in the same manner as the KRB_AS_REP processing described above. The primary difference is that the ciphertext part of the response must be decrypted with the session key that is shared with the TGS rather than with the user's master key.

It turns out that there is neither functionality nor security gained by having Kerberos require an authenticator as part of the KRB_TGS_REQ message. If someone who did not know the session key K transmitted Tc,tgs to the TGS, the TGS would return a message encrypted with K, which would be of no use to someone who did not know the session key. The reason the designers of Kerberos did it this way is to make the protocol for talking to the TGS be the same as for talking to the other servers. When talking to other servers, the authenticator does indeed provide security, because it authenticates the knowledge of the corresponding session key.

The AP exchange of the Kerberos V4 protocol is used by network applications either to authenticate a client to a server, or to mutually authenticate a client and a server to each other. The client must have already acquired credentials for the server using the AS or TGS exchange.

In step 5, C sends a KRB_AP_REQ (Kerberos application request) message to the server S. The message includes Tc,s, Ac,s = {C,T} K, and some additional bookkeeping information. Authentication is based on the server's current time of day, the ticket Tc,s, and the authenticator Ac,s.

To make sure that the KRB_AP_REQ message is not a replay of a request recent enough to look current given the time skew, S should keep all time stamps received within the maximum allowable time skew and check that each received time stamp is different from any of the stored values. Any authenticator older than the maximum allowable time skew would be rejected anyway, so there is no need to remember values older than the threshold value. Kerberos V4, however, does not bother saving time stamps. Saving time stamps does not help if S is a replicated service in which all the instances of the service use the same master key. The threat of an eavesdropper replaying the authenticator C sent to one instance of S to a different instance of S could have been avoided if Kerberos had done something like put the network layer of the instance of S in the authenticator, too.

If no error occurs, and if mutual authentication is required, S has to return a KRB_AP_REP (Kerberos application reply) message to C in step 6. Again, this message is encrypted with the session key K' that is shared between C and S. Since this key was in the ticket encrypted with the server's secret key, possession of this key is proof that S is the intended principal. More accurately, S has to increment the time stamp included in the KRB_AP_REQ message authenticator and reencrypt it with K.

As described thus far, Kerberos provides mutual authentication services for the client and server. However, a by-product of the Kerberos authentication protocol is the exchange of a session key K that is shared between the client and the server. This key can then be used by the application to protect the confidentiality and integrity of communications. Typically, communications between the client and server is transparently encrypted and decrypted using the DES and the session key K.

There are at least two problems that should be considered with care when it comes to the large-scale deployment of the Kerberos system:

  1. The fact that one part of the KRB_AS_REP message is encrypted with KU can be used to launch a verifiable password guessing attack against the user's password. More accurately, it is possible to guess a password candidate, derive a candidate KU from this value, and decrypt the relevant part of the KRB_AS_REP message with this key. It is then verifiable whether the password candidate was properly guessed. There are several strategies to protect against this type of attack, but unfortunately, all require the use of public key cryptography or similar constructs.

  2. The fact that the Kerberos KDC shares a secret key with each principal in the realm allows the administrator of the KDC to spoof any principal. This is a consequence of the fact that the Kerberos system only uses secret key cryptography.

Furthermore, every network application must be modified to make use of the Kerberos system. The process of modifying a network application to make use of the Kerberos system is commonly referred to as "Kerberizing" it. In general, Kerberizing network applications is usually the most difficult part of installing Kerberos. Fortunately, the MIT reference implementations of the Kerberos system include Kerberized versions of some popular network applications, such as Telnet and the Berkeley r-tools. Other applications have been Kerberized by vendors and are included in their supported products. The availability of Kerberized applications has improved with time, and is expected to further improve in the future. However, a site would still have to arrange itself to add Kerberos support to any application developed in house.

One of the main design principles for an authentication and key distribution system is its use of a standardized API, such as the Generic Security Services API (GSS-API) specified by the IETF Common Authentication Technology (CAT) WG. Unfortunately, the use of the GSS-API for Kerberos V5 has not been specified until recently [42]. Also, more work is needed to standardize and eventually simplify the GSS-API, such as demonstrated by GSS-API version 2 or the Simple Public-Key GSS-API Mechanism [43, 44].

Finally, note that the Kerberos system provides authentication, data confidentiality, and data integrity services. By itself, it provides no information as to whether or not the client is authorized to access the server and to use the corresponding services. In general, there are three possibilities to address authorization within the basic Kerberos model:

  1. The Kerberos KDC could maintain authorization information for each service and issue tickets to authorized users only.

  2. A dedicated service could maintain authorization information by keeping access lists for each service and allowing the client to obtain sealed certification of list membership. The client would then present the sealed certification in addition to a Kerberos ticket to the requested service.

  3. Each service could maintain its own authorization information, with the optional help of a service that stores access lists and provides certification of list membership.

The Kerberos model is based on the assumption that each service knows best who its users should be and what form of authorization is appropriate for them. Consequently, the third approach is employed in the Kerberos system. Next we will see that the main difference between Kerberos and SESAME and Windows 2000 is that SESAME and Windows 2000 both employ the second approach to address authorization.

16.2.2 SESAME

SESAME was a European research and development project aimed at developing an authentication and authorization infrastructure (AAI) and system for distributed computing and networking environments [45–47]. It achieved this by including and combining an extended Kerberos V5 authentication service and a privilege attribute service that can be used to provide authorization and corresponding access control services.

Recall that in the Kerberos system a client requests a TGT from the AS, and that the client can use this TGT to request service tickets from the TGS. In the SESAME system, a similar approach is used for authorization and access control. If a client wants to use a service, he or she must not only be authenticated by the AS, but also have his or her other privilege attributes certified by an additional component, a so-called privilege attribute server (PAS). In SESAME, the term privilege attribute certificate (PAC) is used to refer to a certified set of privilege attributes. In principle, a PAC consists of both the user's privileges and corresponding control information. The user's privileges are data such as the user's identity, role, organizational group, and security clearance, whereas the control information says where and when the PAC can be used and whether it can be delegated or not. Note that a PAC is conceptually similar to an attribute certificate. In short, the client and the PAS must exchange KRB_PAS_REQ and KRB_PAS_REP messages between the AS exchange (using the KRB_AS_REQ and KRB_AS_REP messages) and the TGS exchange (using the KRB_TGS_REQ and KRB_TGS_REP messages). In these messages, the client is provided with a PAC that is relevant for the user on whose behalf it is acting.

Refer to Chapter 6 of [29] or [47] to get a more comprehensive overview and discussion of the SESAME system. Also, the SESAME home page[20] provides a good source of information for further study. With the deployment of similar mechanisms in Windows 2000, interest in SESAME and SESAME-enabled applications has become negligible in the recent past.

16.2.3 Windows 2000

More recently, Microsoft has implemented the Kerberos V5 authentication service with extensions for public key authentication[21] for the Windows 2000 operating system. The Kerberos KDC is integrated with other Windows 2000 security services running on the domain controller and uses the domain's active directory as its security account database.[22]

In addition to the functionality specified in [37], Windows 2000 implements an authorization mechanism in the Kerberos system in a specific and unique way. When the Kerberos protocol is used for authentication, a list of security identifiers (SID) identifying a principal and the principal's group memberships is transported to the client in the authorization data field of a ticket. Authorization data, in turn, are gathered in two steps:

  • The first step takes place when the KDC in a Windows 2000 domain prepares a TGT.

  • The second step is accomplished when the KDC prepares a service ticket for the server in the domain.

When a user requests a TGT, the KDC in the user's account domain queries the domain's active directory. The user's account record includes the user's SID as well as SIDs for any security group to which the user belongs. The list of SIDs returned by the KDC is placed in the authorization data field of the TGT.[23] In a multiple-domain environment, the KDC also queries the Global Catalog for any universal groups that include the user or one of the user's domain security groups. If any are found, their SIDs are also added to the list in the TGT's authorization data field.

When a user requests a service ticket, the KDC in the server's domain copies the contents of the TGT's authorization data field to the ticket's authorization data field. Furthermore, if the server's domain is different from the user's account domain, the KDC queries the active directory to find out whether any security groups in the local domain include the user or one of the user's security groups. If any are found, their SIDs are also added to the list in the service ticket's authorization data field.

[11]DEC has been acquired by Compaq.

[12]The Open Group was formed in early 1996 by the consolidation of two open systems consortia, namely the Open Software Foundation (OSF) and the X/Open Company, Ltd. The Open Group includes a large number of computer vendors, including IBM and Microsoft.

[13]In Greek mythology, Kerberos is the name of the three-headed watchdog of Hades, whose duty it was to guard the entrance of the underworld.

[14]Outside the United States and Canada, the eBones distribution of Kerberos V4 is heavily used and widely deployed. The eBones distribution is available at http://www.pdc.kth.se/kth-krb/.

[15]As of this writing, the protocol is still in the status of a Proposed Standard.

[16]http://web.mit.edu/kerberos/www/

[17]http://nii.isi.edu/info/kerberos/

[18]http://web.mit.edu/kerberos/www/dialogue.html

[19]Kerberos V4 did not prompt the user to enter the password until after C has received the KRB_AS_REP message. This is because Kerberos V4 was serious in following the generally good security rule of having C know the user's password only for the minimum time possible. But waiting the few seconds to retrieve the KRB_AS_REP message before asking the user for the password really does not enhance security significantly, and in fact Kerberos V5 has the user enter the password before C sends the KRB_AS_REQ message. The reason for the designers of Kerberos V5 to change the order was that V5 requires C to prove that it knows the user's password before the AS sends the KRB_AS_REP message, which makes it less easy to obtain a quantity with which to launch an offline password guessing attack.

[20]http://www.esat.kuleuven.ac.be/cosic/sesame/

[21]These extensions are specified by the IETF CAT WG under the acronym PKINT.

[22]For consistency, the Microsoft documentation uses the term "domain" instead of "realm." Furthermore, the distinction between an AS and a TGS is not made. Both components are collectively referred to as a KDC.

[23]Note that this use of the authorization data field to actually carry authorization information is consistent with revisions to the Kerberos V5 protocol specification [37] submitted to the IETF.


Team-Fly


Internet and Intranet Security
Internet & Intranet Security
ISBN: 1580531660
EAN: 2147483647
Year: 2002
Pages: 144

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net