See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/251915684

An Optimized Kerberos Authentication Protocol

Article · December 2009

DOI: 10.1109/ICCES.2009.5383213

CITATIONS READS
15 2,893

4 authors:

Eman El-Emam Magdy Koutb

National Authority for Remote Sensing and Space Sciences Menoufia University
5 PUBLICATIONS 48 CITATIONS 21 PUBLICATIONS 207 CITATIONS

SEE PROFILE SEE PROFILE

Hamdy M. Kelash Osama S. Faragallah

46 PUBLICATIONS 328 CITATIONS

Menoufia University
240 PUBLICATIONS 3,824 CITATIONS
SEE PROFILE
SEE PROFILE

All content following this page was uploaded by Eman El-Emam on 26 March 2015.

The user has requested enhancement of the downloaded file.

195
An Optimized Kerberos Authentication Protocol
Eman El-Emam, Magdy Koutb, Hamdy Kelash, and Osama Farag Allah
Abstract— This paper will introduce simple modifications to
the database of the widely deployed Kerberos authentication
protocol. The principle’s long-term secret key will be
independent of the user password with the aim to overcome the
weak passwords chosen by the network principal that are
susceptible to password guessing attacks, the main drawback of
the Kerberos protocol. Instead, the Kerberos Distribution Center
will save a profile for every instance in the realm that it mange
and the secret key will be generated based on that profile. This
profile will be hashed and then, the output digest will be
encrypted to generate the secret key. Besides, the lifetime of the
secret key will be controlled using the system lifetime. We will
use Triple-Des as an encryption algorithm, SHA-256 as a hashing
algorithm, and Blum Blum Shub as a random number generator
algorithm.
Index Terms— Access control, authentication protocols,
authorization, computer network security, Kerberos.
I. INTRODUCTION
M odern computer systems provide service to multiple
users and require the ability to accurately identify the
user making a request. The process of verifying the user's
identity is called authentication. Authentication is a
fundamental building block for a secure networked
environment. Access control and authorization can be built on
top of authentication resulting in the required security to the
computer network system.
The authentication service in a networked environment can
be achieved by using Kerberos. It is one of the most widely
used authentication protocols. The overall scheme of Kerberos
is that of a trusted third party that uses a protocol based on
that proposed by Needham and Schroeder [1]. It is trusted in
the sense that clients and servers trust Kerberos to mediate
their mutual authentication. Kerberos provides a centralized
authentication server (the KDC: Kerberos distribution Center)
whose function is to authenticate users to servers and servers
to users. Kerberos relies exclusively on symmetric encryption,
Manuscript received August 9, 2009.
E. El-Emam is with the Egyptian Space Program, National Authority for
Remote Sensing and Space Sciences, Cairo, Egypt (phone: +202-26251279;
fax: +202-26225800; e-mail: eman.elemam@gmail.com).
M. Koutb is with the Department of Industrial Electronics & Control,
Faculty of Electronic Engineering, Menouf, Egypt (e-mail:
magdykoutb@yahoo.com).
H. Kelash is with the Department of Computer Science & Engineering,
Faculty of Electronic Engineering, Menouf, Egypt (e-mail:
hmk3947@yahoo.com).
O. Farag Allah is with the Department of Computer Science &
Engineering, Faculty of Electronic Engineering, Menouf, Egypt (e-mail:
osam_sal@yahoo.com).
1
making no use of public-key encryption. Most of the secure
routing protocols rely on public key infrastructures (PKI) to
authenticate communicating nodes. Although PKI is secure, it
is based on asymmetric cryptography and hence requires
excessive processing and communication resources [2]. This
resource hungry feature makes PKI based systems more
susceptible to Denial of Service attacks. In contrast, Kerberos
[3] is a symmetric key based authentication mechanism.
We will begin with presenting a brief overview of the
related work. Then, we will outline the Kerberos messages
exchange. After that, we will discuss the Kerberos drawbacks.
Then, we will examine the details used in our proposed
implementation, address its associated database, and describe
our testing environment. Finally, we will summarize our
conclusions and our future work.
II. PREVIOUS WORK
A. Kerberos History
Kerberos was developped at the Massachusetts Institute of
Technology (MIT) to protect network services provided by
Project Athena. Versions 1–3 occurred only internally at MIT.
Despite of that Steve Miller and Clifford Neuman are the
primary designers of Kerberos 4, many members of Project
Athena contributed to the design and implementation of
Kerberos [4]. Kerberos 4 was published in the late 1980s.
Although it was targeted primarily for Project Athena, it has
grown to be used in modern computer networks. Version 5
was designed by John Kohl and Clifford Neuman. It appeared
as RFC 1510 in 1993 [3] (made obsolete by RFC 4120 in
2005 [5]), with the intention of overcoming the limitations and
security problems of version 4. There is a dialogue in [6] that
was written in 1988 to help to understand the fundamental
reasons for why Kerberos 4 was the way it was. This dialogue
is still applicable for Kerberos 5 where the basic core ideas of
the protocol have remained the same.
MIT formed the Kerberos Consortium along with some of
the major vendors and users of Kerberos such as Sun
Microsystems, Apple, Google, Microsoft, etc. The MIT
Kerberos Consortium was created at 2007 to maintain a
continued development for the protocol and to establish
Kerberos as the universal authentication platform for the
world's computer networks.
B. Kerberos Security
Security of Kerberos has been analyzed in many works,
e.g., [7]-[11]. These analyses identify certain Kerberos
limitations and sometimes propose fixes. By this way, the
195 2

evolution of the protocol is achieved. Kerberos 5 is being
revised and extended in many work, e.g., [5], [12], and [13].
F. Butler, I. Cervesato, A. Jaggard, and A. Scedrov have
analyzed portions of Kerberos 5 and have formally verified
that the design of Kerberos’ current version meets the desired
goals for the most parts [14]. A. Boldyreva and V. Kumar at
2007 take a close look at Kerberos’ encryption and confirm
that most of the options in the current version provably
provide privacy and authenticity [15].
C. Kerberos Applications
Kerberos is also introduced to be used in wireless networks.
M. Erdem proposed a wireless authentication systems based
on Kerberos in [16]. He used DES, 3DES and AES as secret-
key encryption algorithms. Additionally, he used SHA-1
message digest algorithm to hash the message blocks. Besides,
A. Pirzada and Chris McDonald discuss in [17] how Kerberos
is used for authentication in mobile ad-hoc networks.
Kerberos is also used in IPv6 networks. S. Sakane, N.
Okabey, K. Kamadaz, and H. Esakix present in [18] a method
to establish secure communication using Kerberos in IPv6
networks. They used Kerberos to achieve access control and
introduced a simple modification to Kerberos to deal with
address resolution.
Nitin et al. used Kerberos in [19] to present an image based
authentication system 2008. That paper is a comprehensive
study on the subject of using images as a password and the
implementation of Jaypee University of Information
Technology (JUIT) Image Based Authentication (IBA) system
called as JUIT-IBA using Kerberos protocol.
Kerberos has grown to become the most widely deployed
system for authentication and authorization in modern
computer networks. It is currently shipped with all major
computer operating systems and is uniquely positioned to
become a universal solution to the distributed authentication
and authorization problem of communicating parties [20].
session key is contained in the Ticket granting ticket and is
encrypted using the long-term secret key of the TGS which
is shared between the TGS and the Kerberos infrastructure
(the AS can access the database of the Kerberos
infrastructure). The information directed to the client is
encrypted under the client’s long-term secret key.
• In the second phase, the client forwards the ticket granting
ticket, along with an authenticator encrypted with the
session key obtained in the first phase, to the TGS,
requesting a service ticket to be used in the third phase with
the application server. The TGS is expected to reply with a
message consisting of the application server ticket and an
encrypted component containing a fresh session key to be
shared between the client and the application server.
Another copy of this session key is contained in the
application server ticket and is encrypted using the long-
term secret key of the application server which is shared
between the application server and the Kerberos
infrastructure (the TGS can access the database of the
Kerberos infrastructure). The information directed to the
client is encrypted with the session key of the first stage.
• In the third phase, the client forwards the application server
ticket, along with a new authenticator encrypted with the
session key obtained in the second phase, the application
server, requesting certain service. The application server
ticket plus the secret session key are the client’s credentials
to be authenticated to a specific application server. If all
credentials are valid, the application server will authenticate
the client and provide the service. The acknowledgement
message from the application server is optional and used
only when the system requires mutual-authentication by the
application server.

III. OVERVIEW OF THE KERBEROS PROTOCOL

The Kerberos protocol allows a client to repeatedly
authenticate herself to multiple servers assuming that there is a
long-term secret key shared between the client and the
Kerberos infrastructure. The client long-term secret key was
generated using the client’s password ([21] describes the
password to key transformation technique that is presented by
the standard specification). If a client wishes to authenticate
herself to an application server, the standard run of Kerberos
will accomplish this through three successive phases; the
expected messages flow in these phases is shown in Fig 1 and
proceeds as follows:
• In the first phase, the client sends a request to the Kerberos
Authentication Server (AS) requesting a ticket granting
ticket to be used in the second phase with the Ticket
Granting Server (TGS). The AS is expected to reply with a
message consisting of the ticket granting ticket and an
encrypted component containing a fresh session key to be
shared between the client and the TGS. Another copy of this Fig 1. Overview of the Kerberos actions.
195 3

The second phase which represents the exchange between Principle

Profile Principle
the client and the Kerberos TGS in messages 3 and 4 are used Hashing Encryption Secret
Algorithm Algorithm Key
whenever a user authenticates to a new application server. KDC
While, message 5 is used each time the user authenticates System Time

itself to the application server. Fig 2. Sceret key generation block diagram.

IV. KERBEROS WEAKNESSES B. Proposed Implementation

The protocol drawbacks can be stated as follows: The messages exchange of our proposed protocol are
1. "Password guessing" attacks are not solved by Kerberos. If introduces in Fig 3 and the elements of each message is
a user chooses a poor password, it is possible for an attacker simply explained in TABLE I
to successfully mount an offline dictionary attack by (the details can be found in [21]). At the end of this process,
repeatedly attempting to decrypt messages obtained which the client and the server share a secret session key Kc,v.
are encrypted under a key derived from the user's password
by a publicly-known algorithm.
2. Kerberos requires continuous availability of the KDC.
When the KDC is down, the system will suffer from the
single point of failure problem. This can be mitigated by
using multiple Kerberos servers.
3. The system clocks of the hosts that are involved in the
protocol should be synchronized. The tickets have a time
availability period and if the host clock is not synchronized
with the Kerberos server clock, the authentication will fail.
In practice, Network Time Protocol daemons are usually
used to keep the host clocks synchronized.
4. There are no standards to explain the administration of the
Kerberos protocol. This will differ between server
implementations. Fig 3. Messages exchange for the proposed modified Kerberos.
TABLE I
V. PROPOSED MODIFICATION TO THE KERBEROS THE ELEMENTS OF EACH MESSAGE OF FIG 3.
Message (1) Client requests ticket-granting ticket
A. Proposed Idea
Options Requests that certain flags be set in the returned TGS ticket.
Since the long-term secret key of the network principle is IDC Tells AS the identity of the client.
generated from the principle’s password, Kerberos is IDtgs Tells AS the TGS identity that the client requests access to.
vulnerable to password guessing attacks. We introduce a Requests certain time settings in the returned TGS ticket
Times
(from, till, renew_till).
simple practical modification to the KDC database to Random value to be repeated in message (2) to avoid replay
Nonce1
overcome these attacks. In our modified version of Kerberos, attack.
the long-term secret key of the network principle will be Message (2) AS returns ticket-granting ticket
independent of the principle’s password. Instead, the KDC IDC The identity of the client.
will save a profile for every instance in the realm that it KC
Encryption by the client’s long-term secret key (based on
client's profile).
manages. The type of profile data contents may be audio,
Copy of session key accessible to client created by AS to
video, image, or simply text data. The KDC database may Kc,tgs
permit secure exchange between client and TGS.
have mixed types of profiles. The network principle may be a The times settings of the returned TGS ticket (from, till,
Times
client or a server. Every principle in the network is registered renew_till).
in the KDC database by the principle ID. Then the KDC maps Nonce1 Repeat for the random value of message 1.
this ID to the proper profile where the profile is named with IDtgs Confirms that this ticket is for the TGS.
the principle’s ID that belongs to that profile. In order to Tickettgs Reusable ticket to be used by client to access TGS.
generate the principle’s secret key, we apply a hashing Ktgs
Ticket is encrypted with key known only to AS and TGS, to
algorithm to the principle’s profile and then encrypt the output prevent tampering.
Flags The flags of the returned TGS ticket.
digest. We control the lifetime of the secret key using the
Copy of session key accessible to TGS used to decrypt
current KDC system time that is appended to the principle’s Kc,tgs
authenticator, thereby authenticating ticket.
profile every predefined period (this period is a design IDC Indicates the rightful owner of this ticket.
parameter, i.e. a site constant). By this way, we change the Prevents use of ticket from workstation other than one that
ADC
input to the hashing function, and consequently, the output of initially requested the ticket.
Times The times settings of the TGS ticket (from, till, renew_till).
the hashing function and the secret key will change too. The
Message (3) Client requests service-granting ticket
block diagram of Fig 2 illustrates our proposed scheme.
195 4

Options
Requests that certain flags be set in the returned application C. Comparison between Our Implementation and Previous
server ticket. Versions
Tells TGS the application server identity that the client
IDV Our implementation complies with Kerberos 5 in almost all
requests access to.
Times
Requests certain time settings in the returned server ticket parts except that the principle’s long-term secret key is
(from, till, renew_till). independent of its password. A comparison between Kerberos
Random value to be repeated in message (4) to avoid replay
Nonce2
attack. 4, Kerberos 5 and our proposed implementation is depicted in
Tickettgs Assures TGS that this user has been authenticated by AS. TABLE II:
Generated by client to validate ticket. It assures TGS that the 1. Both Kerberos 4 and Kerberos 5 are vulnerable to password
AuthenticatorC1 ticket presenter is the same as the client for whom the ticket
guessing attack as described in section IV but our
was issued; has very short lifetime to prevent replay.
Authenticator is encrypted with key known only to client implementation overcomes this problem and that is the main
Kc,tgs
and TGS, to prevent tampering. contribution of our work.
IDC Must match ID in the TGS ticket to authenticate ticket. 2. In both Kerberos 5 and our implementation, the client
ADC Must match address in the TGS ticket to authenticate ticket.
Informs TGS of time this authenticator was generated to
requests certain time settings from the server by the
TS1 message element “Times” which is subdivided into three
check the authenticator’s validity.
Message (4) TGS returns service-granting ticket subelements (from: the desired start time for the requested
IDC The identity of the client. ticket, till: the requested expiration time for the requested
Kc,tgs Key shared only by the client and the TGS. ticket, and renew_till: this field is only present in tickets that
Copy of session key accessible to client created by TGS to
have the RENEWABLE flag set in the flags field. It
KC,V permit secure exchange between the client and the
application server. indicates the maximum end-time that may be included in a
Times
The times settings of the returned server ticket (from, till, renewal). The “Times” message element is absent in
renew_till). Kerberos 4.
Nonce2 Repeat for the random value of message 3.
Confirms that this ticket is for the application server which 3. Version 4 requires the use of DES. In version 5, ciphertext
IDV
identity is V. is tagged with an encryption type identifier so that any
Reusable so that client does not need to request a new ticket encryption technique may be used. We used the DES
TicketV
from TGS for each access to the same server.
Ticket is encrypted with key known only to TGS and server, encryption technique in our implementation.
KV 4. Besides, encryption in version 4 makes use of a nonstandard
to prevent tampering.
Flags The flags of the returned server ticket. mode of DES known as Propagating Cipher Block Chaining
Copy of session key accessible to client; used to decrypt
KC,V
authenticator, thereby authenticating ticket.
(PCBC) ([21] describes this mode of operation). Security
IDC Indicates the rightful owner of this ticket. problems have been demonstrated in that mode [7]. Version
ADC
Prevents use of ticket from workstation other than one that 5 makes use of the standard CBC mode for encryption and
initially requested the ticket. our implementation used that mode too.
Times The times settings of the server ticket (from, till, renew_till).
5. Each ticket includes a session key that is used by the client
Message (5) Client requests service
to encrypt the authenticator sent to the service associated
Options Requests mutual authentication from the server.
TicketV Assures server that this user has been authenticated by TGS. with that ticket. In addition, the session key may
Generated by client to validate ticket. It assures server that subsequently be used by the client and the server to protect
AuthenticatorC2 the ticket presenter is the same as the client for whom the messages passed during that session. However, because the
ticket was issued; has very short lifetime to prevent replay.
Authenticator is encrypted with key known only to the client
same ticket may be used repeatedly to gain service from a
KC,V particular server, there is the risk that an opponent will
and the application server.
IDC Must match ID in the server ticket to authenticate ticket. replay messages from an old session to the client or the
ADC Must match address in the server ticket to authenticate ticket.
server. In both version 5 and our implementation, it is
Informs server of time this authenticator was generated and
TS2 possible for a client and server to negotiate a subsession
used to check the authenticator’s validity.
The client's choice for an encryption key to be used to key, which is to be used only for that one connection. A
Subkey protect this specific application session. If this field is new access by the client would result in the use of a new
omitted, the session key from the ticket Kc,v is used.
An optional field that specifies the starting sequence number subsession key.
Seq. # to be used by the application server for messages sent to the 6. Version 4 requires the use of Internet Protocol (IPv4)
client during this session to detect replays. addresses. In version 5, network address is tagged with type
Message (6) Optional authentication of application server to client and length. This allows any network address type to be
KC,V
Assures the client that this message is from the application used. Our implementation makes use of the IPv4 network
server which identity is V. address.
TS2 Assures the client that this is not a replay of an old reply.
The server's choice for an encryption key to be used to 7. The ticket lifetime in version 4 is encoded in an 8-bits
Subkey protect this specific application session. If this subkey quantity in units of five minutes. Thus, the maximum
present, it overrides the subkey field of message (5). lifetime that can be expressed is 256 x 5 = 1280 minutes.
An optional field that specifies the starting sequence number
Seq. # to be used by the client for messages sent to the application
In version 5 and in our implementation, the ticket
server during this session to detect replays. includes an explicit start and end times (the “from” and
the “till” of the message element “Times”), allowing
tickets with arbitrary lifetimes.
195 5

TABLE II algorithm. In our design, the lifetime of the long-term

COMPARISON BETWEEN KERBEROS 4, KERBEROS 5, AND OUR PROPOSED
IMPLEMENTATION principle’s secret key is 1 week, the lifetime of the TGS ticket
Our Proposed is 1 day, the lifetime of the application server ticket is 8 hours,
Comparison Item Kerberos 4 Kerberos 5
Implementation
Keys are
and the lifetime of the authenticator is 5 minutes.
Password attack Vulnerable Vulnerable independent of We used different scenarios to test our implementation. Fig
password 5 illustrates a screen shot for one of our testing scenarios. It
From, till, From, till, has four main sections. They could be explained as follows:
Times No times
renew_till renew_till
1. The first section in the upper left corner of the figure
Encryption key
Encryption
DES is tagged with Triple-DES corresponds to the first communication phase during which
technique an exchange between the client and the AS is happened. In
type & length
DES mode of PCBC (not The standard The standard that section the client enters some inputs. They are as
operation standard) CBC mode CBC mode follows:
Client & server Client & server • The IP address and the communication port of the AS.
may negotiate may negotiate
Session key 1/lifetime for subsession for subsession • The client’s ID.
key key • The TGS ID.
(1/connection) (1/connection) • If the client requests that a ticket granting ticket may
Any (network postdated, the ticket may postdate option should be
address is
Network address IPv4 IPv4 chosen. It is not chosen in our example.
tagged with
type) • The requested times parameters for the ticket granting
Arbitrary Arbitrary ticket. They are from date, from time, till date, and till
1280 minutes (determined by (determined by time.
Ticket lifetime
maximum start & end start & end
times) times) 2. The second section in the upper right corner of the figure
corresponds to the second communication phase during
which an exchange between the client and the TGS is
D. Testing Environment
happened. In that section the client enters some inputs. They
Our testing LAN is presented in Fig 4 where the KDC is are as follows:
logically divided into the AS and the TGS. We have two • The IP address and the communication port of the TGS.
application servers (server A and server B) and four clients
• The application server ID to which the ticket is requested.
(client1, client2, client3, and client4). We used a mixed
• Some options in the requested application server ticket.
profiles KDC database with 4 profiles corresponding to the
Here we request a valid renewable application server
four clients (1 audio + 1 video + 1 image + 1 text profiles).
ticket. Note that we can not chose the “Ticket postdate”
option since the “Ticket may postdate” option is not
selected in the AS exchange during the first
communication stage.
• The requested times parameters for the application server
ticket. They are from date, from time, till date, till time,
renew_till date, and renew_till time. Note that if the
“Ticket renewable” option is not selected, the renew_till
date and the renew_till time will be absent in the times
parameters.
3. The third section in the lower left corner of the figure
corresponds to the third communication phase during which
an exchange between the client and the application server is
happened. In that section the client enters some inputs. They
are as follows:
• The IP address and the communication port of the
application server.
• A mutual option is chosen to indicate that mutual
authentication is requested from the server.
4. The fourth section in the lower right corner of the figure
corresponds to the error message section. If an error
Fig 4. A schematic for the testing LAN. occurred during any communication phase, an error is
displayed in that section.
In our implementation, we use Triple-DES in CBC mode as
an encryption algorithm, SHA-256 as a hashing algorithm,
and Blum Blum Shub as a random number generator
195
Fig 5. A screen shot for one of our testing scenarios.
VI. CONCLUSIONS
Since the principle’s secret key will be independent of the
principle’s password in our proposed modification to the KDC
database, we can overcome the weak passwords chosen by the
network principle that are susceptible to password guessing
attack, the main drawback of the Kerberos protocol. We
present our testing environment. We tested our
implementation on a small LAN and we are looking forward
to extend our implementation such that it could cover cross-
realm operations.
REFERENCES
[1] R. Needham, and M. Schroeder, “Using encryption for authentication in
large networks of computers,” Communications of the ACM, December
1978.
[2] Y-C Hu, A. Perrig, and D. B. Johnson, “SEAD: secure efficient distance
vector routing for mobile wireless ad hoc networks,” Proc of IEEE
Workshop on Mobile Computing Systems and Applications, 2003.
[3] J. Kohl, and C. Neuman, “The Kerberos network authentication service
(V5),” RFC 1510. September 1993. Available at
http://www.ietf.org/rfc/rfc1510.txt, 2005.
[4] C. Neuman and Ts'o. Theodore, “Kerberos: an authentication service for
computer networks,” IEEE Communications Magazine. September 1994.
[5] C. Neuman, T. Yu, S. Hartman, and K. Raeburn, “The Kerberos network
authentication service (V5),” Network Working Group. Request for
Comments: 4120. Available at http: //www.ietf.org/rfc/rfc4120.txt, 2005.
[6] B. Bryant, “Designing an authentication system: a dialogue in four
scenes,” Project Athena document (February 1988). Available at
http://web.mit.edu/Kerberos/dialogue.html
[7] J. Kohl, “The use of encryption in Kerberos for network authentication,”
In CRYPTO ’89. Springer, 1989.
[8] S. Stubblebine and V. Gligor, “On message integrity in cryptographic
protocols,” In Symposium on Security and Privacy ’92. IEEE, 1992.
[9] G. Bella and E. Riccobene, “Formal analysis of the Kerberos
authentication system,” Journal of Universal Computer Science,
3(12):1337–1381, 1997.
[10] F. Butler, I. Cervesato, A. D. Jaggard, and A. Scedrov, “A formal
analysis of some properties of Kerberos 5 using MSR,” University of
Pennsylvania, Department of Computer & Information Science,
Philadelphia, USA, Technical Report MS-CIS-04-04, April 2004.
[11] Qin Li, Fan Yang, Huibiao Zhu, and Longfei Zhu, “Formal modeling
and analyzing Kerberos protocol,” IEEE World Congress on Computer
Science and Information Engineering (CSIE), 2009.
View publication stats
6
[12] K. Raeburn, “Encryption and checksum specifications for Kerberos 5,”
Network Working Group. Request for Comments: 3961. Available at
http://www.ietf.org/rfc/rfc3961.txt, 2005.
[13] K. Raeburn, “Advanced encryption standard (AES) encryption for
Kerberos 5,” Network Working Group. Request for Comments: 3962.
Available at http://www.ietf.org/rfc/rfc3962.txt, 2005.
[14] F. Butler, I. Cervesato, A. Jaggard, and A. Scedrov, “A formal analysis
of some properties of Kerberos 5 using MSR,” In CSFW ’02. IEEE,
2002.
[15] A. Boldyreva and V. Kumar, “Provable-security analysis of
authenticated encryption in Kerberos,” IEEE Symposium on Security
and Privacy (SP'07). May 2007.
[16] M. Erdem, “High-speed ECC based Kerberos authentication protocol for
wireless applications,” Global Telecommunications Conference.
GLOBECOM. IEEE Volume 3, Dec 2003.
[17] A. Pirzada and C. McDonald, “Kerberos assisted authentication in
mobile ad-hoc networks,” The 27th Australasian Computer Science
Conference, conferences in Research and Practice in Information
Technology, 2004.
[18] S. Sakane et al., “Applying Kerberos to the communication environment
for information appliances,” Symposium on Applications and the
Internet Workshops (IEEE SAINT-w’03), 2003.
[19] Nitin et al., “Security analysis and implementation of JUIT—image
based authentication system using Kerberos protocol,” Proceedings of
the 7th IEEE/ACIS International Conference on Computer and
Information Science, (ICIS 2008).
[20] http://www.kerberos.org/index.html
[21] William Stallings, “Cryptography and network security principles and
practices,” 4th ed., Pearson Prentice Hall, 2006, pp. 401-419, pp. 433-
435.
Eman M. El-Emam received the BSc in Electronics & Communication
engineering from Ain Shams University, Cairo, Egypt in 2000. She received a
Diploma in Computer Networking from the ITI (Information Technology
Institute), Giza, Egypt in 2001. She has been a communication engineer in the
ESP (Egyptian Space Program) at NARSS (National Authority for Remote
Sensing and Space Sciences), Cairo, Egypt since 2001 till now. Her research
interest includes channel coding, network protocols, and network security.
Magdy A. Koutb received the Eng. Degree from the University of Menofiya,
Egypt, in 1977, M.Sc.degree in 1981 from the university of Al-Azhar, Egypt,
and the Ph.D. degree from the University of Silesia, Poland in 1985. He has
been a Professor since 1997 at the Faculty of Electronic Engineering,
Menoufiya University. In 2003 he was appointed as Vice-Dean of Post-
Graduate Studies and Cultural affairs of the same faculty. He has extensive
experience in Computer Engineering and Industrial Electronics. His main
research interests include distributed systems, network security and intelligent
control systems.
Hamdy M. Kelash received the Eng. Degree from the Institute of Electronic
Engineering, Egypt in 1971, MSc degree from Faculty of Engineering
Technology, Helwan University, Egypt, in 1979 and the PhD degree from
Institute National Polytechnique (INP), France in 1984. He has been head of
Computer Sciences and Engineering department, Faculty of Electronic
Engineering, Menoufia University from 2001 to 2007. His main research
interests include artificial intelligence, network security, and image
processing.
Osama S. Farag Allah received his BSc in 1997, MSc in 2002, and PhD in
2007, all in computer science and engineering, from Menoufia University,
Faculty of Electronic Engineering, Egypt. He was a demonstrator at the
Department of Computer Science and Engineering, at Menoufia University,
from 1997 to 2002, became an assistant lecturer in 2002, and was promoted to
a lecturer in 2007. His research interests cover computer networks, network
security, cryptography, Internet security, multimedia security, image
encryption, watermarking, steganography, data hiding, and chaos theory.