provides a centralized authentication server whose function is to authenticate
users to servers and servers to users. Kerberos relies exclusively on
conventional encryption, making no use of public-key encryption.
following are the 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.
Reliable: For all 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 a 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 numbers of clients and servers. This suggests a modular, distributed architecture.
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.
A Simple Authentication Dialogue
unprotected network environment, any client can apply to any server for
obvious security risk is that of impersonation. To counter this threat, servers
must be able to confirm the identities of clients who request service. But in
an open environment, this places a substantial burden on each server.
alternative is to use an authentication server (AS) that knows the passwords of
all users and stores these in a centralized database. In addition, the AS
shares a unique secret key with each server.
simple authentication dialogue is as follows:
>> AS: IDc||Pc||IDv
>> C: Ticket
C >> V: IDc||Ticket Ticket=
Authentication Server, V: Server,
IDv : ID
of the server, IDc : ID of the
of the client, ADc: Address of client,
secret key shared by AS and V, ||: concatenation.
2. A More Secure Authentication
two major problems associated with the previous approach:
transmission of the password.
a user has to enter the password.
these problems, we introduce a scheme for avoiding plaintext passwords, and
anew server, known as ticket granting server (TGS). The hypothetical scenario
is as follows: Once
per user logon session:
>> AS: IDc||IDtgs
>> C: Ekc (Tickettgs)
Once per type of service:
>> TGS: IDc||IDv||Tickettgs
>> C: ticketv
Once per service session:
>> V: IDc||ticketv
Client, AS: Authentication Server, V: Server, IDc : ID of the client,
Pc:Password of the client, ADc: Address of client, IDv : ID of the server, Kv:
secret key shared by AS and V, ||: concatenation, IDtgs: ID of the TGS server,
TS1, TS2: time stamps, lifetime: lifetime of the ticket.
service, TGS, issues tickets to users who have been authenticated to AS. Thus,
the user first requests a ticket-granting ticket (Tickettgs) from
the AS. The client module in the user
saves this ticket. Each time the user requires access to a new service, the
client applies to the TGS, using the ticket to authenticate itself. The TGS
then grants a ticket for the particular service. The client saves each
service-granting ticket and uses it to authenticate its user to a server each
time a particular service is requested. Let us look at the details of this
client requests a ticket-granting ticket on behalf of the user by sending its
user's ID and password to the AS, together with the TGS ID, indicating a
request to use the TGS service.
responds with a ticket that is encrypted with a key that is derived from the
response arrives at the client, the client prompts the user for his or her
password, generates the key, and attempts to decrypt the incoming message.
correct password is supplied, the ticket is successfully recovered.
only the correct user should know the password, only the correct user can
recover the ticket. Thus, we have used the password to obtain credentials from
Kerberos without having to transmit the password in plaintext.
the client has a ticket-granting ticket, access to any server can be obtained
with steps 3 and 4:
client requests a service-granting ticket on behalf of the user. For this
purpose, the client transmits a message to the TGS containing the user's ID,
the ID of the desired service, and the ticket-granting ticket.
decrypts the incoming ticket and verifies the success of the decryption by the
presence of its ID. It checks to make sure that the lifetime has not expired.
Then it compares the user ID and network address with the incoming information
to authenticate the user. If the user is permitted access to the server V, the TGS
issues a ticket to grant access to the requested service.
service-granting ticket has the same structure as the ticket-granting ticket.
Indeed, because the TGS is a server, we would expect that the same elements are
needed to authenticate a client to the TGS and to authenticate a client to an
application server. Again, the ticket contains a timestamp and lifetime. If the
user wants access to the same service at a later time, the client can simply
use the previously acquired service-granting ticket and need not bother the
user for a password. Note that the ticket is encrypted with a secret key (Kv)
known only to the TGS and the server, preventing alteration.
with a particular service-granting ticket, the client can gain access to the
corresponding service with step 5:
client requests access to a service on behalf of the user. For this purpose,
the client transmits a message to the server containing the user's ID and the
service-granting ticket. The server authenticates by using the contents of the
scenario satisfies the two requirements of only one password query per user
session and protection of the user password.