1

A

Minor Project Report on

“KERBEROS-TRUSTED THIRD PARTY PROTOCOL USING PUBLIC KEY CRYPTOGRAPHY”

submitted in partial fulfillment of the requirement for

B.Tech (CSE) Programme

By

Anuj Jain– 08CS000166

Anuj Mehta -08CS000167

Taru Lodha– 08CS000262

Lakshya Nahta-08cs000206

Yatindra Singh Choudhary– 08CS000272

Session:2011-2012

The Department of Computer Science Engineering

2

ACKNOWLEDGMENT

I would like to thank everyone who helped to see this project to completion. In

particular, I would like to thank my project’s mentor Mr. KAMALJEET

LAKHTARIA for his moral support and guidance to complete my project on

time.

I would like to take this opportunity to thank Mr. PRASUN

CHAKRABARTY Head of the Department, Computer Science & Engineering for

his support and encouragement.

3

ABSTRACT

Kerberos is a security system that helps prevent people from stealing information that gets sent across the wires from one computer to another. Usually, these people are after your password.

The name "Kerberos" comes from the mythological three-headed dog whose duty it was to guard the entrance to the underworld. The Kerberos security system, on the other hand, guards electronic transmissions that get sent across the Internet. It does this by scrambling the information -- encrypting it -- so that only the computer that's supposed to receive the information can unscramble it. In addition, it makes sure that your password itself never gets sent across the wire: only a scrambled "key" to your password.

Kerberos is necessary because there are people who know how to tap the lines between computers and listen for your password. They do this with programs called "sniffers", and the only way to stop them would be to physically guard every inch of the Internet ... computers, cables and all. This, of course, is impossible. As long as there are physically insecure networks in the world, we'll need something like Kerberos to maintain the integrity and security of our electronic communications.

This document describes protocol extensions (hereafter called PKINIT)to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields.

4

Index

1)Introduction:...........................................................................................

1.1) Benefits of Kerberos:.......................................................…………..

2)Motivation:……………………………………………………

3)How does it work:…………………………………………….

4) Encryption:……………………………………………………

5)Kerberos authentication system:……………….…………….

6)Kerberos using public key cryptography:.................................

7)Algorithms Used:………………………………………………

8) Conclusion:……………………………………………………

9)References:…………………………………………………….

5

CHAPTER 1: INTRODUCTION

6

1.Introduction

Kerberos gets its name from Greek mythology. Cerberus, also known as Kerberos, was a three headed beast that guarded the Underworld and kept the living from entering the world of the dead. Kerberos protocol design began in the late 1980s at the Massachusetts Institute of Technology (MIT), as part of project Athena. It is a secure authentication mechanism designed for distributed severs, which assumes the network is unsafe. It enables a client and a server to mutually authenticate before establishing a connection. The first public release was Kerberos version 4, which leads to the actual version (v5) in 1993 after a wide public review. It followed the IETF standard process and its specifications are defined in Internet RFC 1510. Originally designed for UNIX, it is now available for all major operating systems, freely from MIT or also through commercial versions.

The problem that the Kerberos addresses is this: Assume an open distributed environment in which users at workstations wish to access services on servers distributed throughout the network. We would like for servers to restrict access to authorized users and to be able to authenticate requests for service. In this environment, a work station cannot be trusted to identify its users correctly to network services. In particular, the following three threats exist:

A user may gain access to a particular workstation and pretend to be another user operating from that workstation.

A user may alter the network address of a workstation so that the requests sent from the altered workstation appear to come from the impersonated workstation.

A user may eavesdrop on exchanges and use a reply attack to gain entrance to a server or to disrupt operations.

In any of these cases, an unauthorized user may be able to gain access to services and data that he or she is not authorized to access. Rather than building in elaborate authentication protocols at each server, Kerberos provides a centralized authentication server whose function is to authenticate users to servers and servers to users. Unlike most other authentication schemes, Kerberos relies exclusively on symmetric encryption, making no use of public -key encryption.

Two versions of Kerberos are in common use. Version 4 [MILL88,STEI88]is still widely used. Version 5[KOHL94] corrects some of the security deficiencies of version 4 and has been issued as a proposed Internet Standard (RFC 1510).

7

1.1.Benefits of using Kerberos

Nothing is easier today than to catch credentials over a network. If we try to run a sniffer in our environment we will see that we certainly get a login/password combination within a few minutes. This could lead to an unauthorized use of our network services and would certainly compromise all data present in our environment; even protected confidential data, as most users are using only one password for every application. Authentication is critical to security. Too many applications use a weak authentication mechanism, like clear text passwords or, even worse, rely on the “honesty” of client applications, known as authentication by assertion. However, it is not the primary role of an application to manage security. Consider a mail server: its role is to deliver email messages over the network to the appropriate recipients, but not to verify the user’s identity! This is where Kerberos comes in. It has the advantage to manage secure authentication from a central location, and for many applications. For each application that requires this service, it is a reliable, simple and easy to manage solution to use Kerberos. Furthermore, it unloads application servers from this time consuming authentication task and allows concentrating on their primary function.

8

CHAPTER 2:MOTIVATION

9

2. Motivation

If a set of users is provided with dedicated personal computers that have no network connections, then a user’s resources and files can be protected by physically securing each personal computer. When these users are served by a central time sharing system, the time sharing operation must provide the security. The operating system can enforce access control policies based on user identity and use the logon procedure to identify users.

Today, neither of these scenarios is typical. More common is a distributed architecture consisting of dedicated user work stations (clients) and distributed or centralized servers. In this environment, three approaches of security can be envisioned:

1. Rely on each individual client workstations to assure the identity of its user or users and rely on each server to enforce a security policy based on user identification (ID).

2. Requires that client systems authenticate themselves to servers, but trust the client system concerning the identity of the user.

3. Requires the user to prove identity fro each service invoked. Also requires that severs prove their identity to clients.

In a small, closed environment, in which all systems are owned and operated by a single organization, the first or perhaps the second strategy may suffice. But in a more open environment, in which network connections to other machines are supported, the third approach is needed to protect user information and resources housed by the server. The third approach is supported b Kerberos. Kerberos assumes distributed client/server architecture and employs one or more Kerberos servers to provide an authentication service.

The first published report on Kerberos [STEI88] listed the following requirements for Kerberos:

Secure: A network eavesdropper should not be able to obtain the necessary information to impersonate a user. More generally, Kerberos should be strong enough that a potential opponent does not find it to be the weak link.

10

Reliable: For all the services that rely on Kerberos for access control, lack of availability of the Kerberos service means lack of availability of the supported services. Hence, Kerberos should be highly reliable and should employ distributed server architecture, with one system able to back up another.

Transparent: Ideally, the user should not be aware that authentication is taking place, beyond the requirement to enter a password.

Scalable: The system should be capable of supporting large number of clients and servers. This suggests a modular, distributed architecture.

To support these requirements, the overall scheme of Kerberos is that of a trusted third-party authentication service that uses a protocol based on that proposed by Needham and Schroeder [NEED78]. It is trusted in the sense that clients and servers trust Kerberos to mediate their mutual authentication. Assuming the Kerberos protocol is well designed, then the authentication service is secure if the Kerberos server itself is secure.

11

CHAPTER 3: HOW DOES IT WORK?

12

3)How does it Work?

Kerberos operates by encrypting data with a symmetric key. A symmetric key is a type of authentication where both the client and server agree to use a single encryption/decryption key for sending or receiving data. When working with the encryption key, the details are actually sent to a key distribution center, or KDC, instead of sending the details directly between each computer. The entire process takes a total of eight steps, as shown below.

1. – The authentication service, or AS, receives the request by the client and verifies that the client is indeed the computer it claims to be. This is usually just a simple database lookup of the user’s ID.

2. – Upon verification, a timestamp is created. This puts the current time in a user session, along with an expiration date. The default expiration date of a timestamp is 8 hours. The encryption key is then created. The timestamp ensures that when 8 hours is up, the encryption key is useless. (This is used to make sure a hacker doesn’t intercept the data, and try to crack the key. Almost all keys are able to be cracked, but it will take a lot longer than 8 hours to do so)

3. – The key is sent back to the client in the form of a ticket-granting ticket, or TGT. This is a simple ticket that is issued by the authentication service. It is used for authenticating the client for future reference.

13

4. – The client submits the ticket-granting ticket to the ticket-granting server, or TGS, to get authenticated.

5. – The TGS creates an encrypted key with a timestamp, and grants the client a service ticket.

6. – The client decrypts the ticket, tells the TGS it has done so, and then sends its own encrypted key to the service.

14

7. – The service decrypts the key, and makes sure the timestamp is still valid. If it is, the service contacts the key distribution center to receive a session that is returned to the client.

8. – The client decrypts the ticket. If the keys are still valid, communication is initiated between client and server.

Is all that back-and-forth communication really necessary? When concerning speed and

reliability, it is entirely necessary. After the communication is made between the client and

server, no further need of transmitting logon information is needed. The client is authenticat

15

CHAPTER 4:ENCRYPTION

16

4. ENCRYPTION

Encryption is the process of changing text so that it is no longer easy to read. A very simple example is the following sentence:

Guvf vf n fvzcyr fhofgvghgvba pvcure.

.Commercial encryption uses methods which are a lot more secure than the one I used to produce that example. Almost all modern encryption methods rely on a key - a particular number or string of characters which are used to encrypt, decrypt, or both.

In the next sections, common encryption methods are presented. To illustrate how they work, ficticious characters named Bob and Alice will be introduced. Private key encryption and public key encryption are discussed, as are their limitations.

4.1. Private key encryption

Private key encryption is the standard form. Both parties share an encryption key, and the encryption key is also the one used to decrypt the message. The difficulty is sharing the key before you start encrypting the message - how do you safely transmit it?

Many private key encryption methods use public key encryption to transmit the private key for each data transfer session.

If Bob and Alice want to use private key encryption to share a secret message, they would each use a copy of the same key. Bob writes his message to Alice and uses their shared private key to encrypt the message. The message is then sent to Alice. Alice uses her copy of the private key to decrypt the message. Private key encryption is like making copies of a key. Anyone with a copy can open the lock. In the case of Bob and Alice, their keys would be guarded closely because they can both encrypt and decrypt messages.

4.2. Public Key encryption

Public key encryption uses two keys - one to encrypt, and one to decrypt. The sender asks the receiver for the encryption key, encrypts the message, and sends the encrypted message to the receiver. Only the receiver can then decrypt the message - even the sender cannot read the encrypted message.

When Bob wants to share a secret with Alice using public key encryption, he first asks Alice for her public key. Next, Bob uses Alice's public key to encrypt the message. In public key encryption, only Alice's private key can unlock the message encrypted with her public key. Bob sends his message to Alice. Alice uses her private key to decrypt Bob's message.

The things that make public key encryption work is that Alice very closely guards her private key and freely distributes her public key. She knows that it will unlock any message encrypted with her public key.

17

4.3. Limitations of encryption

Cryptanalysis, or the process of attempting to read the encrypted message without the key, is very much easier with modern computers than it has ever been before. Modern computers are fast enough to allow for 'brute force' methods of cryptanalysis - or using every possible key in turn until the 'plain text' version of the message is found.

The longer the key, the longer it takes to use the 'brute force' method of cryptanalysis - but it also makes the process of encrypting and decrypting the message slower. Key length is very important to the security of the encryption method - but the 'safe' key length changes every time CPU manufacturers bring out a new processor.

Encryption does not make your data secure. Not using encryption, however, means that any data in transit is as easy to read as the contents of a postcard, sent in regular mail. Encryption at least ensures that anyone who does read your messages has worked hard at it.

18

CHAPTER 5:KERBEROS AUTHENTICATION SYSTEM

19

5.The kerberos Authentication System

Kerberos is an authentication system based on private-key cryptography. In the Kerberos system, a trusted third-party issues session keys for interactions between users and services. It is mature technology which has been widely used, although it has known limitations. 

The Kerberos design is open-source, originating at MIT in the mid-1980's, and Kerberos is still freely available from MIT and other sources. Kerberos is also available in commercial software supported by vendors and has been incorporated into many widely-used products. For instance, Sun includes basic Kerberos functionality in Solaris, Cisco routers support Kerberos authentication for telnet connections, and Microsoft has announced it will use a version of the Kerberos protocol in Windows 2000. 

This paper will first list the goals and scope of the Kerberos system, followed by a brief review of concepts in private-key cryptography, and a description of the Kerberos "ticket-granting" approach. Appropriate applications, limitations, and competing technologies will be discussed, as well as the future of this technology. This brief overview of Kerberos is intended to highlight its main functionality, and does not exhaustively describe its features. For additional details on Kerberos, see the references listed at the end of this paper. 

5.1Goals and Scope of the Kerberos system

Kerberos is designed to provide authentication of user identity in a networked computing environment consisting of workstations (used directly by one or more users) and servers (providing services such as email and shared file systems). It is, in part, a response to the current standard approach to network security, authentication by assertion, wherein a client gains access to services simply by asserting that it is who it says it is (or is acting on behalf of the user that it claims it is). 

A basic assumption is that network traffic is highly susceptible to interception and is the weak link in system security, rather than direct access to servers, which can be protected by physical means. The more often a specific cryptographic key is reused, the more susceptible it becomes to decoding. For this reason, each session of interactions between a user and a specific service should be encrypted using a short-lived "session key". To make the system usable in practice, however, it must be convenient, and to the greatest extent possible, transparent to the user. 

Starting with those assumptions, the system's key goals can be summarized as follows: 

Never transmit unencrypted passwords over the network, i.e. "in the clear".  Protect against the misuse of intercepted credentials (also called "replay attacks").  Do not require the user to repeatedly enter a password to access routine services.

The Kerberos system attempts to address design tradeoffs between the level of protection provided and the user's convenience, while also considering the complexity of system administration and application development. 

20

Implementations of Kerberos are available from various vendors, and it is freely accessible in open-source form. The standard MIT distribution includes a basic set of applications, including telnet, POP email, and the Berkeley UNIX "R-commands" (such as rlogin). Other applications can be "Kerberized" by incorporating calls to Kerberos library functions. 

Encryption algorithms such as those used in Kerberos have long been considered munitions by the US government. The export status of Kerberos under newly liberalized regulations (October 2000) is unclear. For the time being, MIT is distributing its source only to US and Canadian citizens. Versions without encryption have been exported overseas, however. 

5.2.Private key cryptography and trusted third parties

The crypographic algorithm typically employed in Kerberos is Data Encryption Standard (DES), although the modular design of Kerberos allows alternative encryption libraries to be used. DES is a standard algorithm for "private-key" cryptography. 

The term "private key" cryptography (also called "secret key" or "symmetric key" cryptography) refers to an approach where the pair of entities exchanging messages share a single key used to encode and decode messages. This is in contrast to "public key" (or "asymmetric key") cryptography, where the encoding and decoding keys are separate and difficult to derive from each other, allowing one of the keys to be made publicly available. Private-key cryptography has the advantage of efficiency, but poses the fundamental problem of initially communicating the key to be used. For this reason, the two techniques are often combined. 

In both private-key and public-key cryptography, there is generally a practical need to rely on trusted third parties to certify identity. In Kerberos, a central authentication server certifies the identities of all entities (where an entity may be a user, a client application operating on behalf of a specific user, or a service provided by an application server). The functionality of Kerberos completely relies on the trustworthiness of the authentication server, which must know the password or key of every entity. It is therefore of paramount importance that the authentication server itself be completely secure. 

5.3Kerberos ticket-granting approach

An essential conflict exists between the need to communicate the encryption key, and the need to keep the key secret. There is also a trade-off between using a unique key for every message and re-using a single key for an extended session of interactions (this trade-off potentially impacts both efficiency and convenience, vs. the level of protection provided). 

The Kerberos system's approach involves several layers of messages. Although these multiple layers may seem overly elaborate at first glance, they represent a reasonable attempt to address the design trade-offs. 

The following is a simplified description of the Kerberos message scheme (illustrated in Figures 1-3). In this discussion, the term "client" refers to a user or to a client-side application program operating on behalf of a user. As noted above, the term "application" server refers to a remote computer which provides a shared service. The term "password" refers to the user's password or to a cryptographic key derived from it (since the process of deriving the key from the password

21

is transparent to the user). The term "session" key refers to a cryptographic key issued for use in communication between a client and an application server, which is valid for some defined interval of time. 

Two basic elements are used in Kerberos messages: a ticket and an authenticator. A ticket is acquired by a client from the authentication server, and sent to the application server as part of the request for a service. An authenticator is constructed by the client, is sent to the application server along with the ticket, and is used by the application server to verify that the request was sent by the client to whom the ticket was issued. 

As noted above, the goals of the system include 1) avoiding repeated re-entry of passwords and 2) sending unencrypted passwords over the network. To address these goals, the initial exchange with the Kerberos authentication server issues the user a "ticket-granting ticket" (TGT) containing a session key to be used for subsequent ticket requests. 

Each TGT is good for a fixed life span, typically set to 8 hours. The TGT effectively serves as a proxy for the user with the Ticket Granting Service over the life of the TGT. This prevents the user from having to authenticate themselves every time they wish to access a service on the network.     

Figure 1

The initial message from the client to the authentication server is typically sent automatically at the time of login. The initial message contains the user's name (but not password) and request for a TGT (Figure 1). 

The authentication server replies with a message encrypted with the user's password and containing a TGT (Figure 1). Because the TGT message is encrypted with the user's password, it is protected if intercepted. When received by the client, the TGT message can be decoded to obtain the session key to be used for subsequent ticket requests. This session key for ticket-granting requests is referred to below as the TG key. 

22

   

Figure 2

Once the client has a TG key, the subsequent requests for a specific service will take the form shown in Figure 2. 

The client sends a request to the Ticket Granting Service (TGS) to obtain a ticket for the service. The Ticket Granting Service can compare the client identification information embedded in the message with its record of issuing the TG key. The timestamp helps to protect against any attempt to re-use an intercepted message; typically, a request will be considered invalid if received more than 5 minutes after the embedded timestamp. This prevents messages from being intercepted, cracked offline, and then used at a later time. 

After confirming the client's identity, the Ticket Granting Service responds with a message containing a new session key. 

The ticket itself contains information identifying the client and the newly generated session key. Note that the client cannot decode or alter the ticket, only forward it to the application server.     

23

Figure 3

The client then sends a message to the application server containing the ticket and an authenticator (Figure 3). 

As noted above, the authenticator is constructed by the client, and contains identifying information and a timestamp. When this message is received by the application server, it can decode the ticket, because it is encrypted with the server's own key (known only to itself and the authentication server). The ticket contains the session key which is used to decode the authenticator. For the request to be considered valid, the data embedded in the authenticator must match that in the ticket. 

Subsequent messages between the client and the application server may be encrypted using the session key. 

5.4.Applications and Limitations of Kerberos

Kerberos is suitable for supporting authentication, authorization, and confidentiality within a network or small set of networks. However, it is not as well suited to some other functions, such as digital signatures (which provide both certification of identity and non-repudiation), for which public-key cryptography is often used. 

A fundamental issue is whether the Kerberos approach is scalable to the Internet. Features added in the current version of Kerberos are designed to allow inter-network authentication (in Kerberos terminology, referred to as "cross-realm" authentication). Recent proposals have included using public-key cryptography for both initial authentication of clients (TGT) and for cross-realm authentication. Such changes will make it more feasible for Kerberos to scale to larger sets of networks, but the question is far from resolved. 

One of the primary assumptions of the Kerberos protocol is that the hosts on the network can be trusted. Luckily, the extent of attacks that can occur if a host is compromised is limited. Tickets which remain in the hosts' cache can be used, but only until they expire. 

If users choose easily guessable passwords, the system is subject to a dictionary attack, where attackers simply try different passwords until the correct one is chosen. This can be overcome by

24

administrative rules requiring passwords that are not easily guessed by a dictionary algorithm. Timestamps also help to protect against this type of attack by limiting the amount of time an attacker has to guess a password. 

Since the system relies entirely on passwords for user authentication, if the passwords themselves are stolen, the possibility of system attack is unlimited. This points to the requirement that the Key Distribution Center be protected. If it is compromised, the entire system is unsafe. 

For long processes, limited duration tickets can present problems. Kerberos Version 5 addresses this problem with renewable tickets. 

A Tale of Two KeysPublic key encryption is a special case of encryption. It operates using a combination of two keys:

a private key and a public key,

which together form a pair of keys.

The private key is kept secret on your computer since it is used for decryption.

The public key, which is used for encryption, is given to anybody who wants to send encrypted mail to you.

Sending Public-Key Encrypted MailThe sender's encryption program uses your public key in combination with the sender's private key to encipher the message.

Receiving Public-Key Encrypted MailWhen you receive the encrypted message, you need to decipher it.

Decryption of a message enciphered with a public key can only be done with the matching private key. This is why the two keys form a pair, and it is also why it is so important to keep the private key safe and to make sure it never gets into the wrong hands (or in any hands other than yours).

Why the Integrity of the Public Key is EssentialAnother crucial point with public key encryption is the distribution of the public key.

Public key encryption is only safe and secure if the sender of an enciphered message can be sure that the public key used for encryption belongs to the recipient.

A third party can produce a public key with the recipient's name and give it to the sender, who uses the key to send important information in encrypted form. The enciphered message is intercepted by the third party, and since it was produced using their public key they have no problem deciphering it with their private key.

25

This is why it is mandatory that a public key is either given to you personally or authorized by a certificate authority.

Public Key EncryptionOne of the weaknesses some point out about symmetric key encryption is that two users attempting to communicate with each other need a secure way to do so; otherwise, an attacker can easily pluck the necessary data from the stream. In November 1976, a paper published in the journal IEEE Transactions on Information Theory, titled "New Directions in Cryptography," addressed this problem and offered up a solution: public-key encryption.

Also known as asymmetric-key encryption, public-key encryption uses two different keys at once -- a combination of a private key and a public key. The private key is known only to your computer, while the public key is given by your computer to any computer that wants to communicate securely with it. To decode an encrypted message, a computer must use the public key, provided by the originating computer, and its own private key. Although a message sent from one computer to another won't be secure since the public key used for encryption is published and available to anyone, anyone who picks it up can't read it without the private key. The key pair is based on prime numbers (numbers that only have divisors of itself and one, such as 2, 3, 5, 7, 11 and so on) of long length. This makes the system extremely secure, because there is essentially an infinite number of prime numbers available, meaning there are nearly infinite possibilities for keys. One very popular public-key encryption program is Pretty Good Privacy (PGP), which allows you to encrypt almost anything.

26

CHAPTER 6: KERBEROS USING PUBLIC KEY CRPTOGRAPHY

27

6. KERBEROS-USING PUBLIC KEY CRYPTOGRAPHY

The Kerberos V5 protocol involves use of a trusted third party known as the Key Distribution Center (KDC) to negotiate shared session keys between clients and services and provide mutual authentication between them.

The corner-stones of Kerberos V5 are the Ticket and the Authenticator. A Ticket encapsulates a symmetric key (the ticket session key) in an envelope (a public message) intended for a specific service. The contents of the Ticket are encrypted with a symmetric key shared between the service principal and the issuing KDC. The encrypted part of the Ticket contains the client principal name, among other items. An Authenticator is a record that can be shown to have been recently generated using the ticket session key in the associated Ticket. The ticket session key is known by the client who requested the ticket. The contents of the Authenticator are encrypted with the associated ticket session key. The encrypted part of an Authenticator contains a timestamp and the client principal name, among other items.

As shown in Figure 1, below, the Kerberos V5 protocol consists of the following message exchanges between the client and the KDC, and the client and the application service:

- The Authentication Service (AS) Exchange

The client obtains an "initial" ticket from the Kerberos authentication server (AS), typically a Ticket Granting Ticket (TGT). The AS-REQ message and the AS-REP message are the request and the reply message, respectively, between the client and the AS.

- The Ticket Granting Service (TGS) Exchange

The client subsequently uses the TGT to authenticate and request a service ticket for a particular service, from the Kerberos ticket-granting server (TGS). The TGS-REQ message and the TGS-REP message are the request and the reply message respectively between the client and the TGS.

28

- The Client/Server Authentication Protocol (AP) Exchange

The client then makes a request with an AP-REQ message, consisting of a service ticket and an authenticator that certifies the client's possession of the ticket session key. The server may optionally reply with an AP-REP message. AP exchanges typically negotiate session-specific symmetric keys.

Usually, the AS and TGS are integrated in a single device also known as the KDC.

+--------------+ +--------->| KDC | AS-REQ / +-------| | / / +--------------+ / / ^ | / |AS-REP / | | | / TGS-REQ + TGS-REP | | / / | | / / | | / +---------+ | | / / | | / / | | / / | v / v ++-------+------+ +-----------------+ | Client +------------>| Application | | | AP-REQ | Server | | |<------------| | +---------------+ AP-REP +-----------------+

Figure 1: The Message Exchanges in the Kerberos V5 Protocol

In the AS exchange, the KDC reply contains the ticket session key, among other items, that is encrypted using a key (the AS reply key) shared between the client and the KDC. The AS reply key is typically derived from the client's password for human users. Therefore, for human users, the attack resistance strength of the Kerberos protocol is no stronger than the strength of their passwords.

The use of asymmetric cryptography in the form of X.509 certificates is popular for facilitating data origin authentication and perfect secrecy. An established Public Key Infrastructure (PKI) provides key management and key distribution mechanisms that can be used to establish authentication and secure communication. Adding public-key cryptography to Kerberos provides a nice congruence to public-key protocols, obviates the human users' burden to manage strong passwords, and allows Kerberized applications to take advantage of existing key services and identity management.

29

The advantage afforded by the Kerberos TGT is that the client exposes his long-term secrets only once. The TGT and its associated session key can then be used for any subsequent service ticket requests. One result of this is that all further authentication is independent of the method by which the initial authentication was performed. Consequently, initial authentication provides a convenient place to integrate public-key cryptography into Kerberos authentication. In addition, the use of symmetric cryptography after the initial exchange is preferred for performance. This document describes the methods and data formats using which the client and the KDC can use public and private key pairs to mutually authenticate in the AS exchange and negotiate the AS reply key, known only by the client and the KDC, to encrypt the AS-REP sent by the KDC.

Conventions Used :

In this protocol, both the client and the KDC have a public-private key pair in order to prove their identities to each other over the open network. The term "signature key" is used to refer to the private key of the key pair being used.The encryption key used to encrypt the enc-part field of the KDC-REP in the AS-REP] is referred to as the AS reply key. An empty sequence in an optional field can be either included or omitted: both encodings are permitted and considered equivalent.The term "Modular Exponential Diffie-Hellman" is used to refer to the Diffie-Hellman key exchange, as described in in order to differentiate it from other equivalent representations of the same key agreement algorithm.

Extensions: This section describes extensions for supporting the use of public-key cryptography in the initial request for a ticket.

Briefly, this document defines the following extensions : 1. The client indicates the use of public-key authentication by including a special preauthenticator in the initial request. This preauthenticator contains the client's public-key data and a signature. 2. The KDC tests the client's request against its authentication policy and trusted Certification Authorities (CAs). 3. If the request passes the verification tests, the KDC replies as usual, but the reply is encrypted using either:

a.) a key generated through a Diffie-Hellman (DH) key exchange with the client, signed using the KDC'signature key; or

30

b.) a symmetric encryption key, signed using the KDC's signature key and encrypted using the client's public key.

Any keying material required by the client to obtain the encryption key for decrypting the KDC reply is returned in a pre- authentication field accompanying the usual reply.

4. The client validates the KDC's signature, obtains the encryption key, decrypts the reply, and then proceeds as usual.

31

CHAPTER 7:ALGORITHMS USED

32

7. ALGORITHMS USED

7.1. Required Algorithms

All PKINIT implementations MUST support the following algorithms:

o AS reply key enctypes: aes128-cts-hmac-sha1-96 and aes256-cts- hmac-sha1-96 .

o Signature algorithm: sha-1WithRSAEncryption

o AS reply key delivery method: the Diffie-Hellman key delivery method,

7.2. Recommended Algorithms

All PKINIT implementations SHOULD support the following algorithm:

o AS reply key delivery method: the public key encryption key delivery method

For implementations that support the public key encryption key delivery method, the following algorithms MUST be supported:

a) Key transport algorithms identified in the keyEncryptionAlgorithm field of the type KeyTransRecipientInfo for encrypting the temporary key in the encryptedKey field with a public key: rsaEncryption (this is the RSAES-PKCS1-v1_5 encryption scheme) b) Content encryption algorithms identified in the contentEncryptionAlgorithm field of the type EncryptedContentInf for encrypting the AS reply key with the temporary key contained in the encryptedKey field of the type KeyTransRecipientInfo des-ede3-cbc (three-key 3DES, CBC mode)

33

CHAPTER 8:CONCLUSION

34

8) ConclusionAuthentication is critical for the security of computer systems. Without knowledge of the

identity of a principal requesting an operation, it's difficult to decide whether the operation should be allowed. Traditional authentication methods are not suitable for use in computer networks where attackers monitor network traffic to intercept passwords. The use of strong authentication methods that do not disclose passwords is imperative. The Kerberos authentication system is well suited for authentication of users in such environments

35

CHAPTER 11:REFERENCES AND BIBLIOGRAPHY

36

9. References&Bibilography:

Books:

Network Security Essentials- William Stallings.

Websites:

http://java.sun.com/j2se/1.4.1/docs/

http://www.ietf.org/rfc/rfc2853.txt

http://www.windowsitlibrary.com/Content/617/06/3.html#5

http://mit.edu/kerberos/www/

http://www.labmice.net/Security/kerberos.htm

http://portal.acm.org/dl.cfm

37