07-08-2012, 04:29 PM
The Kerberos Authentication Protocol
kerberos.pdf (Size: 137 KB / Downloads: 143)
Introduction
In May of 1983, a five-year research program was started at the Michigan Institute
of Technology to explore how to use computers in the curriculum. This
project was called Project Athena, and it received major funding from IBM and
DEC. Project Athena led to the development of many things now taken for
granted in Information Technology. This included things such as a graphical
windowing system (that gave birth to the X Window system for Unix) and the
idea of networking personal computers, which was unusual at that time. In 1999,
it was estimated that 96% of MIT undergraduate and 94% of graduate students
students have Project Athena accounts, and that on a typical day, some 6000
different users use the system to access their files and various software packages.
Because the existing system of a time-shared mainframe would allow users to
access their personal files regardless of the workstation they were using, as well
as the constrained resources of personal computers (it was impossible to place all
used applications on local hard drives, nor could every computer be equipped
with for instance a printer), Project Athena would use dedicated application
servers that would provide for instance file, print or e-mail services to the rest
of the network.
Basic design
Kerberos endeavours to meet the requirements listed above by using a trusted
third party authentication system. In this system, the network has one authentication
server, officially called the Key Distribution Center (KDC), which
knows all the secret keys (passwords) used by all the principals of the network.
In this system, not only the users, but also the servers, have such a secret key.
The KDC distributes tickets to clients, together with a temporary encryption
key, called the session key. A client then sends the ticket to a server to prove
its identity and establish the session key, and and authenticator to prove that
they are in fact the principal whom that session key was assigned to. The
authenticator is used to prevent another principal from replaying the ticket, as
per the requirements listed above.
In order to meet the requirement that the secret key is never sent across
the network, instead various parts of messages are encrypted using the secret
key. The ticket is encrypted using the secret key of the server it is for, so
that only that server can read the information in the ticket. The session key is
encrypted using the client’s secret key when it is sent to the client. The ticket
also contains a copy of the session key. By encrypting the authenticator using
the session key, the following is achieved: the server knows that the client is
the principal it claims to be, because otherwise it could not know the session
key since that was encrypted using the client’s key in the KDC’s response. The
server can now also send a response back to the client, and encrypt it using the
session key. This proves that the server is who it says it is, since it can only
know the session key if it could decrypt the ticket.
Kerberos in detail
When authenticating using Kerberos a series of messages is exchanged between
principals and the authentication server, as well as between the principals themselves
( the client and server). Tickets must be obtained from the authentication
server and then exchanged between the client and server to perform authentication.
Will not look at these messages in greater detail.
The Authentication Service (AS) Exchange
The first exchange of messages is an exchange between a client and the Authentication
Service (KDC). The exchange is used to obtain a ticket and session
key for use with a server when no credentials were previously obtained. This
exchange is typically initiated by a client, usually at the start of a login session,
to obtain credentials for the Ticket Granting Service, which can then be used to
obtain tickets for other servers. In the case of a server whose credentials cannot
or may not be negotiated using the TGS, this exchange is also used to obtain a
ticket for such a server.
The Ticket Granting Service (TGS) Exchange
As mentioned previously, the AS Exchange is used primarily to get a ticket for a
special server, the Ticket Granting Server (TGS), which can be used to obtain
additional tickets without having to use the client’s secret key anywhere in the
process. This protects the secrecy of the client’s secret, and makes Kerberos
more transparent to the user. If this had not been done, then any time a ticket
needs to be requested the client’s secret key would be needed. This would mean
that either the user has to enter their password every time (which is a nuisance),
or the client’s workstation needs to cache the secret key. Since Kerberos does
not assume that the workstations are secure, this compromises the security of
the secret key. Therefore, this additional ticket exchange is used.
The TGS itself needs to have the access to all the secret keys. Although it
does not encrypt the reply using the client’s secret key, it still needs to encrypt
the ticket using the server’s secret key. Therefore, the TGS is often the same
physical system as the KDC.