Critical Analysis of X.509 and Kerberos for Distributed Authentication

Janantha Marasinghe ee04jdm@brunel.ac.uk

Brunel University

Samir Gadawala ee02ssg@brunel.ac.uk

Brunel University

February, 2007

Abstract

The focus of this analysis is to compare the popular authentication systems used in today’s distributed networks. X.509 and Kerberos will be analyzed in terms of trust models, structures, security mechanism, scalability, performance and maintenance. Kerberos system consists of two versions and this particular paper will be looking at the improvements from the earlier versions and the issues with regard to the current versions. Further on this paper will be discussing the recent mixed authentication system which was developed by integrating X.509 into Kerberos authentication. Grid CA’s and KCA’s are been used by academic and business community, this paper will be overlooking the behaviour of the above stated authentication systems in those architectures. In this paper “principals” are referred to clients, services, servers or a combination of them.

1. Introduction Authentication is a vital security requirement for today’s distributed networks. Without a suitable authentication system the distributed resources such as CPU processing time, storage space, and applications programs etc. will be at risk of misuse. Authentication is provides the service of identifying the entities which take part in providing a resource and consuming resource. X.5091 certificate based system and Kerberos2 ticket based system are the most popular authentication systems used by the industry today. Initially X.509 certificates were used for web-based

1 X.509 is the PKI based authentication system developed for X.500 global directory services but later adopted for web based authentication purposes. 2 Kerberos was developed by the MIT, USA for Project Athena to manage its network security.

authentication but recently it has been used by grid networks for distributed authentication purposes. Kerberos on the other hand is widely been used in the academic research community in a medium scale. To begin with this paper will be analyzing the trust model of each system in an attempt to improve the authentication work flow which will be covered in Section 2. Authentication workflow deals with sending and receiving messages and formats of the messages are discussed in section 3. Security mechanisms are used by each of the systems to protect message content against attacks. This paper will be looking at the prevailing security mechanisms and there weaknesses which will be discussed in Section 4. Distributed networks tend to grow exponentially within a short period of time and this result in many principals requiring authentication concurrently. Therefore X.509 and Kerberos systems are analyzed for scalability issues and remedies are proposed. It is vital for academic and businesses to have an understanding of the cost associated with deploying the authentication systems and section 5 of this paper will be analyzing those aspects. Both of the authentication systems rely on a Trusted Third Party (TTP) which in turn becomes a bottleneck issue. Section 6 will be analyzing the performance of the authentication. A system is considered a failure without a efficient maintenance system. In the context of authentication it requires CA’s and KDC’s to maintain an updated list of revocated certificates or key. The methods used for revocation and the revocation list distribution techniques are analyzed in section 7.

2. Trust models

X.509 is a certificate based system. It involves a Certification Authority (CA) as a TTP. The trust implemented by the X.509 is of a hierarchy structure. A root CA exists at top of the hierarchy and there can

be multiple CA’s located below and further down the tree are the clients as shown in figure 1.0. The root CA has a root certificate which is self signed. The remaining sub-CA’s has CA certificates.

Figure 1. X.509 Hierarchy of Trust

Figure 1. Depicts a scenario where client A in network A requires to use a service from service A of network B. In order for the requirement to be fulfilled “Cross Certification” should occur between the CA’s of each network. It means that the CA in network A and in network B agrees to trust the respective public key certificates and keys as if they had issued them themselves. Cross-certificates are then exchanged, which enables the principals from each network to interact securely. As a result of this process certificate chains are created. After successful cross-certification client A authenticates it self to the service B. This process verifies all the certificates issued by the CA’s along the chain to its destined service. The certification path is known as “A certification path logically forms an unbroken chain of trusted points between two users wishing to authenticate each other” [3]. The major issue with this is when a client accepts a particular CA it also implies that the client is to trust all the certificates issued by that particular CA. This can be a security risk if a particular CA is compromised or a principal is untrustworthy, the security mechanism to prevent such events is mentioned in section 4. X.509 version 3 facilitates the use of extensions. This gives the ability for X.509 certificates to include special attributes which enables security features like authorization, role based access control etc. However attribute certificates go beyond the scope of this paper, but detailed explanation of the certificates can be found in A.Lakshminarayanan at el’s paper [2].

Certificate acceptance process is of two main steps

Certificate validity is performed where the expiry date revocation check, acceptable key usage, CA signatures are checked.

An identity validation is initialized where a challenge response message is sent to verify if the recipient owns the private key for the corresponding certificates.

CA’s are maintained as per organization basis and all the principals requiring authentication should first generate a public and a private key and present the public key along with identification information to the CA. After verifying user details the CA binds the identity of the principal along with its public and signs the certificate using its private key. This registration process will not be favorable in a distributed environment. Therefore recently PKDA [6] was introduced to solve this problem. “Grid technology is a fast evolving form of distributed computing. It allows large numbers of distributed computer systems to work together towards large scale problem solving"[4]. In a grid environment the CA is known as the Grid CA. There are three types of authentication mechanisms used in a grid environment as mentioned by Prof Ian Sommerville at el. [4]. Mutual authentication is when two parties have authenticated each other. Then the next authentication method is done via a TTP as seen in both X.509 and Kerberos systems. Finally the proxy based authentication mechanism which relies on temporary credential service instead of a permanent certificate. Proxy certificates are immune to replay attacks as the life span of a certificate is minimum. X.509 offers proxy certificates as a new addition to its standard. Proxy Certificate Profile RFC can be found at IETF [8]. These types of certificates are similar to the ticketing system used by Kerberos. Grid CA’s are different from the normal CA’s in terms of the format of the Distinguish Name (DN)3 and authentication vetting process. The main advantage of the Grid CA is that it is independent of organizations therefore it only extracts minimum information from the certificates of its subscribers. 3 A unique identifier assigned to each key holder, having the structure required by the certificate Profile

Figure 2. Grid CA Hierarchy of Trust

As mentioned earlier the Grid CA is not aware of every entity requesting the certificates, it requires the use of a Registration Authority (RA) in order to verify the entities. The RA’s will contain information about the entities in concern. “The rules for establishing member identities should be published by each RA, and the procedures for verifying the identities and certificate requests should be consistent between all the RAs and approved by the CA”[1] .

Figure 3. Kerberos authentication flow [32]

On the other hand Key Distribution Centre (KDC) is the TTP for the Kerberos system. The KDC includes two servers, Authentication Server (AS) and Ticket Granting Server (TGS) as shown in Figure 3. The client trust is established with the KDC. The authentication process is initiated by user entering a password which is sent to the AS component of the KDC for verification. Kerberos support cross realm access from version 5, where each KDC’s in each realm share a symmetric key and authenticates each other. Using the authenticated channel secure access is provided between the networks.

Kerberos CA (KCA) is yet another improvement for authentication in gird networks in which the principals are presented with short-term X.509 credentials based on the existing Kerberos identity. The advantage of this solution is that the principals not requiring a long-term grid identity can transparently access the resources within the KCA administrated network without applying for one. The only downside of this system is it requires the KDC to maintain a well formed security policy. Kerberized X.509 certificates are not recommended for some applications and as a alternative long lived certificates should be used according to Fermilab [9]. Kerberos authentication is where Alice (A) authenticates herself to Bob (B) using a server S.

• KAS (authentication server)is a pre-

established secret key known only to A and S. • KBS is known only to B and S.

• KAB is a session key between A and B, and is

created every time both wish to authenticate themselves to each other.

• TS and TA are timestamps generated by S and

A. • L is a 'lifespan' value defining the validity of a

timestamp.

1. A asks S to be authenticated with B.

2. S generates KAB, and sends it to A together

with a timestamp TA and the same data

encrypted for B.

3. A passes on the message to B, obtains a new TA and passes it under the new session key.

4. B confirms receipt of the session key by returning a modified version of the timestamp to A.

The protocol relies heavily on timestamps T and life spans L of tickets, to indicate how reliable A, B and the requests they make are.

Note: The server S here stands for both authentication service (AS), and ticket granting service (TGS).

In ,

Is the client to server ticket.

is the authenticator, and

Confirms true identification of A as it is required for mutual authentication.

New developments in the industry had given birth to Kerberized Certification Authority (KCA) where short lived X.509 certificates are used in the existing Kerberos infrastructure. When ever a ticket is created a certificate and a private key is also generated in the process. Therefore this system has characteristics of the X.509 certification system such as operating online, CA communication etc.

In a distributed environment systems requires the digital signature to be valid for a longer periods of time. The problem occurs when the X.509 certificate is revoked during the period where the validation is required. Therefore the IETF has introduced a Time Stamping Service which uses Time Stamp Protocol [7]. It further mentions “This Trusted Third Party provides a "proof-of-existence" for this particular message at an instant in time” This is similar to the Kerberos Ticketing System’s time stamping method. The RFC states that the time keeping element to be a TTP called the Time Stamp Authority (TSA). Local clocks available in different system may not be trusted as time is the prevention against possible replay attacks the TSA proves a trusted time reference.

3. Structures X.509 certificate consists of 9 attributes as shown in figure 4.

Version number Signature algorithm ID Issuer name Validity period Subject name Subject public key information Issuer unique identifier Subject unique identifier Extensions

Figure 4. X.509 certificate structure The version number indicates the version of the certificate. Currently X.509 is in its 3rd version. Signature algorithm ID defines the signature algorithm used to generate the digital signatures. The signature algorithms used by X.509 are RSA and DSA. There are attacks related to the signatures which will be discussed in section. Issuer name specifies the authority which issued the certificate. In this particular scenario it could be the Grid CA or the KCA. Validity period defines the time period the certificate is deemed valid. This is an important attribute as it prevents replay attack described in section. The subject name defines the principal who will be representing the certificate. The public key information consists of the algorithm used for the public key. This includes RSA keys, Diffie Hellman exchange keys, DSA keys, KEA public keys, ECDSA and ECDH keys. Issuer unique identifier is a unique identifier for the CA as there is a possibility of another CA having the same name. The same implies for the subject unique identifier field. The Extensions field is used to define the key usage etc.

Kerberos Version Server Realm Server Name Flags Session Key Client Realm Client Name Validity Start Time Validity End Time

Figure 5. Kerberos ticket structure The Kerberos version defines the version of Kerberos used. The Client and Server Realms define the network the respective party is operating from. The Client Name and Server Name provides the names of

the respective principal in concern. Flags are similar to extension of the X.509 system. But the flag indicates whether the ticket requires forwarding. Session key is the symmetric key shared between the two principals. The most important attribute is the Validity Start and End Times which specifies the time period the ticket should remain active. From the attribute and below everything is encrypted using the service key. There are few security issues regarding the s ticket which will be discussed in the next section.

4. Security Mechanisms The flow of data in the authentication requires

protection against security attacks. Following are the most common attacks to occur during authentication flow. This section will be discussing about the ways the X.509 and Kerberos attempt to avert to attacks.

� Masquerading � Altering IP deader � Eavesdropping � Traffic analysis � Replay

X.509 certificate consists of a public key and

identification details of the entity which owns it. This in turn is signed by the private key of the CA which issues the certificate. The verifier uses the entities public key to verify the authenticity of the certificate. The successful verification proves that the entity in concern is truly is the holder of the private key which disregard the fact of masquerading. Kerberos system requires a password to be entered at the initial stages of authentication with the KDC. This prevents against the masquerading unless the attacker obtains the password by other means. 4.1 Replay Attacks The authenticator relies on use of a timestamp to guard against reuse. The claim is made that no replays are likely within the lifetime of the authenticator (typically five minutes). An intruder would not start by capturing a ticket and authenticator, and then develop the software to use them; rather, everything would be in place before the ticket-capture was attempted. Kerberos must be made so that it is network infrastructure independent, and have explicit basic

rules that must be met before the authentication can take place securely. 4.2 Secure Time Services A principal can be misled about the correct time; an old authenticator can be replayed. Since some time synchronization protocols are unauthenticated, [11 ] and hosts are still using these protocols despite the existence of better ones, [11] such attacks are not difficult. The design philosophy of building an authentication service on top of a secure time service is itself questionable [11]. That is, it may not make sense to build an authentication system assuming an already - Authenticated underlying system. Furthermore, while spoofing an unauthenticated time service may be a difficult programming task, it is not cryptographically difficult. Using time-based protocols in a secure fashion means thinking through all these issues carefully and making the appropriate synchronization an explicit part of the protocol. As Kerberos is proposed for more varied environments, its dependence on a secure time service becomes more problematic and must be stressed. Must have timing protocol build in which is independent. Secure clocks. RFCs. Timestamp authority (tsp). 4.3 Password-Guessing Attacks A password attack on the Kerberos protocols involves an intruder recording login dialogs. When a user requests TGS (the ticket-granting ticket), the answer is returned encrypted, a key derived by a publicly-known algorithm from the user's password. A guess at the user's password can be confirmed by calculating the encrypted answer, and using it to decrypt the recorded answer. An intruder who has recorded many such login dialogs has good odds of finding several new passwords. 4.4 Spoofing Login In a workstation environment, an intruder can replace the login command with a bogus program that records a user’s password before using it in the Kerberos authentication process. Such an attack invalidates the fact that passwords are never transmitted in cleartext over a network. The fix to this type of attack is the use of one-time passwords.

A typical one-time password process uses a secret key shared between a server and some electronic device in the user's possession. The server picks a random number and transmits it to the user. Both the server and the user (using the device) encrypt this number using the secret key. The result is transmitted back to the server. If the two computed values match, the user is assumed to possess the appropriate key. Another way to authenticate user is to use a "smart card" that understands the entire Kerberos protocol. 4.5 Exposure of Session Keys The term "session key" is a misnomer in the Kerberos protocol. This key is contained in the service ticket and is used in the multiple sessions between the client and server that use that ticket. Thus, it is more properly called a "multi-session key". Making this point explicit leads naturally to the suggestion that true session keys be negotiated as part of the Kerberos protocol . This limits the exposure to cryptanalysis lxat,n67 , Beke82, Deav85l of the multi-session key contained in the ticket, and precludes attacks which substitute messages from one session in another. (The chosen-plaintext attack of the previous section is one such example.) The session key could be generated by the server or could be computed as a session-specific function of the multi-session key. 4.6 The Scope of Tickets Kerberos tickets are limited in both time and space. That is, tickets are usable only within the realm of the ticket-granting server, and only for a limited period of time. the longer a ticket is in use, the greater the risk of it being stolen or compromised . Version 5 incorporates provisions for ticket-forwarding; however, this introduces the problem of cascading trust. E.g. Host A may be willing to trust credentials from host B, and B may be willing to trust host C, but A may not be willing to accept tickets originally created on host C, which A believes to be insecure. Kerberos has a flag bit to indicate that a ticket was forwarded, but does not include the original source. There should be an explicit option to allow forwarding of tickets [9].

5. Scalability

Grid environment requires scalability and flexibility at the highest level as principals enter and leave dynamically. Whenever a principal enters a distributed network it’s required to be authenticated before access is granted for network resources.

Kerberos system’s use of symmetric encryption requires it to store and share keys with its local principals and KDC’s as well as remote KDC’s. This is a major scalability issue when system expands too many keys need to be shared and maintained. A solution to this problem is PKDA which is now been introduced where it integrates X.509 certificates into Kerberos system.

Attempts have been made by Russell Lock at el [6] to create group certificates where each realm has a single certificate which is used by all principals. This is an ideal solution for the scalability problem but if the certificate is comprised, the risk of an attack is eminent for all the principals using the certificate.

Further on with regard to the X.509 certificates, when a certificate

6. Performance

Performance is another aspect in distributed authentication system environments. Both systems discussed in this system depend upon a TTP, therefore when the number of principal’s increase, each of the authentication requests requires processing. Especially X.509 certificate requires more processing power and time than the Kerberos as it works on public key encryption. Kerberos on the other hand uses symmetric key encryption which is faster as the key used for encryption is the same key used for decryption.

PKDA as referred before uses decreases the number

of messages by using X.509 certificates in the initial authentication process.

As all authentication requests goes through the KDC

it forms a bottleneck, therefore it is highly like that under certain conditions the KDC service will be unavailable for service. As a solution currently there are redundant KDC’s running on the local networks, but they are only been activated when the central KDC service is down. As a result there can be a short time delay before the backup service starts and in a distributed environment even the slightest downtime can cause inconvenience as there can be a large number of principals awaiting KDC service. The solution this paper presents deals with implementing multiple KDC's

to run in a parallel where requests are sent to random KDC chosen as shown in Figure 6. This is possible by using Windows Server 2003 OS, as it has replicating capabilities and multiple host controls. The problem with using multiple KDC's running parallel is that it should have a switching mechanism which can be either integrated into the application running on the clients or it should have a front end switching mechanism in the KDC it self. The front-end to the KDC will contain a buffer like temporary storage. This switching mechanism checks for possible buffer space and depending on it redirects the requests to the neighboring KDC's it is aware of. The messaging could be done using XML. This may involve a short time delay. Therefore depending on the scale of the network traffic it may be decided whether to embed the Multiple KDC Aware (MKA) functions in the client applications or the KDC front-end. The models proposed below can be tested depending on the network size.

Figure 6. MKA switching in the middle model

Figure 7. MKA switching at the front-end

model

Figure 8. MKA switching at client end model

7. Maintenance

Authentication relies on efficient maintenance systems as the TTP requires the most up to date validation status of the certificates, private keys and symmetric keys. If proper up to date validation data isn’t available it could pose a security threat to the networks as invalid certificates, tickets, keys will be used to gain access to resources.

X.509 provides two ways to the CA’s to verify the status of a certificate.

� CRL (Certificate Revocation List) � OCSP ( Online Certificate Status Protocol)

CA’s manage a CRL which consists of a database of

invalidated certificates. The lists are updated between the CA’s. This is a critical a factor of certificate security. But it faces problem because of the central point of failure. Therefore OCSP is more suitable for distributed network which is mentioned.

The Online Certificate Status Protocol (OCSP) is an

Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 2560[ ] and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders. For the Kerberos system where the symmetric keys are stored and shared between principals the problem is much more severe compared to X.509. When the KDC

is compromised the keys that it shares required to be revoked and new keys are generated and shared. The recommended solution for this problem is the to use KCA where possible which provides X.509 management system. Although Kerberized Key Management systems exist further improvements are done to make XML based key management system [10].

8. Conclusion Analysis revealed that the X.509 and Kerberos protocol version 5 alone could not provide a fully secure and efficient authentication service. Currently hybrid system are been developed where X.509 is integrated to Kerberos system like PK-INIT to enhance performance as well and to make the system efficient. Also it was also revealed that new security threat are threatening the security of Kerberos system and there for merger with X.509 had become mandatory. In the future, the development of X.509 and Kerberos will be likely to be interlinked. It was also noted that the Grid CA’s and KCA are to dominate most of the distributed authentication systems in time to come. Further on the study concluded that the performance and scalability of the systems are improving with the introduction of the hybrid systems.

9. Bibliography 1. Carlo U. Nicola, Daniel Mall, SGI FH Aargau, "Kerberos and X.509" 2. Daniel Kouril, Ludek Matyska, Michal Procházka, "Kerberos and PKI Cooperation", AFS & Kerberos Best Practices Workshop, Masaryk University, 2006. 3. Alan H. Harbitter, "Performance of Public-Key-Enabled Kerberos Authentication in Large Networks", PEC Solutions Inc. 4. E. Oswald, N.P. Smart, "Public Key Infrastructure", University Of Bristol, October 13, 2006. 5. Colin I'Anson, Chris Mitchell, "Security Defects in CCITT Recommendation X .509 -The Directory Authentication Framework", Hewlett Packard Laboratories. 6. Dr. Rolf Oppliger, "Authentication and Authorization Infrastructures: Kerberos vs. PKI", eSECURITY Technologies. 7. Santosh Chokhani, "A Security Flaw in the X.509 Standard",CygnaCom Solutions Inc.

8. Sam Meder, "GT 4 Security Goals & Plans",The Globus Alliance. 9. Reyhan Aydogan, "Authentication Applications: Kerberos, X.509 and Certificates". 10. Scott Bradner, "IETF Structure and Internet Standards Process", 66th IETF. 11. "A Secure Framework for a Secure Future", Oxford Computer Group. 12. Keys Botzum,"WebSphere Application Server 5.0 Security – Advanced Topics", July 24 2003. 13. Vishal Kher, Yongdae Kim, "Securing Distributed Storage: Challenges, Techniques, and Systems", University of Minnesota. 14. "Kerberos Proposal Existing MIT Realm and Windows2000 Support". 15. "Kerberos 5 (krb5) Interoperability" 16. Lalana Kagal, Timothy Finin, Yun Peng, "A Delegation Based Model for Distributed Trust", University of Maryland Baltimore County. 17. John Shewchuk, "The Next Generation of Internet Identity Internet Identity", CTO Distributed Systems. 18. Paul Syverson, Iliano Cervesato, "The Logic of Authentication Protocols", Naval Research Laboratory ,Washington DC. 19. Ilya Mironov, "Hash functions: Theory, attacks, and applications", Microsoft Research, Silicon Valley Campus, November 14, 2005 20. "Tradeoffs in Certificate Revocation Schemes", University of Pennsylvania.

10. References [1] Mary R. Thompson LBNL , Doug Olson LBNL, Robert Cowles SLAC, Shawn Mullen IBM, Mike Helm ESnet, "CA-based Trust Model for Grid Authentication and Identity Delegation", Global Grid Forum, Oct 2002. [2]A.Lakshminarayanan, Jianying Zhou, "FlexiCert: Merging X.509 Identity Certificates and Attribute Certificates", Proceedings of the 14th International Workshop on Database and Expert Systems Applications (DEXA’03), Institute of Infocomm Research, 2003. [3] Suzan Mendesa, Christian Huitemab, "A New Approach to the X.509 Framework: Allowing a Global Authentication Infrastructure without a Global Trust Model", aTS-E3X - Research and Development Center.

[4] Russell Lock, Prof Ian Sommerville, "Grid Security and its use of X.509 Certificates", Lancaster University. [5] Tom Yu, Sam Hartman, Kenneth Raeburn, "The Perils of Unauthenticated Encryption: Kerberos Version 4", Massachusetts Institute of Technology. [6] Marvin A. Sirbu, John Chung-I Chuang, "Distributed Authentication in Kerberos Using Public Key Cryptography", Carnegie Mellon University. [7] C. Adams , P. Cain, D. Pinkas ,R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)IETF RFC3161", "http://www.ietf.org/rfc/rfc3161.txt", accessed in December 2006. [8] S. Tuecke, V. Welch, D. Engert , L. Pearlman ,M. Thompson, "Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile",

"http://www.ietf.org/rfc/rfc3820.txt", accessed in December 2006. [9] Computer Security Team, Fermi National Accelerator Laboratory,"What is a Certificate?", "http://security.fnal.gov/pki/what_is_cert.html", accessed in January 2007. [10]The TCFS Team, “The Kerberized Key Management Scheme “http://www.usenix.org/event/usenix01/freenix01/full_papers/cattaneo/cattaneo_html/node13.html “, accessed on Jan 2007. [11] I. Cervesato, A.D. Jaggard, “Specifying Kerberos 5 Cross Realm Authentication”, Tulane University.