Kerberos

The Kerberos protocol was first developed by engineers at the Massachusetts Institute of Technology (MIT) in the late 1980s as part of MIT's project Athena [3]. Kerberos is a security system that provides authentication and message protection and is appropriately named after the three-headed dog that guards the entrance of the underworld in Greek mythology. The current version of Kerberos is version 5. Kerberos v5 is RFC 1510 compliant, interoperable with other Kerberos v5 realms that are RFC 1510 compliant, and has some extensions for public key authentication. The primary mechanism for delivering authentication in the Active Directory is the Kerberos protocol. Kerberos v5 is the default authentication protocol for Windows 2000 Active Directory, Windows Server 2003 Active Directory, Windows 2000, and Windows XP clients. Whenever a Windows 2000 or later client authenticates to the Active Directory, the client will always try to use Kerberos. The other protocol that can be used to authenticate to the Active Directory is NTLM, which is supported primarily for backward compatibility with older clients. Kerberos provides both user authentication and encryption key management to guard networks from all forms of attacks on data in transit, including interruption, interception, modification, and fabrication. Kerberos applies a three-pronged security approach: the client, the server, and the trusted intermediary (the Key Distribution Center [KDC]). Kerberos is designed to enable two parties to exchange private information across an otherwise open network.

Kerberos provides the following benefits:

Mutual authentication. The client can verify the server's identity, ensuring that the server that is responding to the client request is the correct server. One server can verify the identity of another. The client can validate its identity to the server.
Trust management. Kerberos trusts are automatically configured and maintained between all of the domains in an Active Directory forest and are transitive and two way. Trusts can also be configured between forests and between Windows Server 2003 Kerberos domains and other Kerberos implementations.
Secure transmission. Messages are encrypted with a variety of encryption keys to ensure that no one can tamper with the client's ticket or with other data in a Kerberos message. Kerberos also prevents the actual password, or any derivation of it, from being sent across the network.
Prevention of replay of authentication packets. Timestamps are used as an authenticator to minimize the risk of someone obtaining and reusing a Kerberos authentication packet. Windows 2000 default clock synchronization requires each packet to be synchronized within 5 minutes of each other. Kerberos authentication will not function if this rule is violated.
Delegated authentication. Delegation refers to a service's ability to impersonate an authenticated user so the user does not need to authenticate to multiple services. Kerberos includes a proxy mechanism that allows a service to impersonate its client when connecting to other services. Delegation is commonly used to effect Internet transactions through intermediary servers. For instance, a client can access e-mail using a browser. In this case, the Web server is delegated the authority of passing the user's credentials to the back-end e-mail server. Kerberos can support delegation because of its unique ticketing mechanism. When sending a ticket to a server, the Kerberos client can add information that the server can reuse to request other tickets on the user's behalf from the Kerberos KDC.

Four components of the Kerberos system allow Kerberos v5 to conduct authentication between the clients and domain controllers in the windows environment. These include the KDC, ticket-granting ticket (TGT), service ticket, and the referral ticket:

KDC. The KDC is the network service that supplies both TGTs and service tickets to users and computers on the network. The authentication and exchange of shared secrets between a user and a server is managed by the KDC. Two services are provided by the KDC: the Authentication Service (AS) [4] and the Ticket-Granting Service (TGS) [5]. This AS issues TGTs for connection to the TGS. The TGS then provides the user with a service ticket for authentication with the target network service. The AS returns a TGT for the TGS, which can be reused until it expires [6].
TGT. The TGT is provided to users the first time they authenticate with the KDC and is issued by the AS. Once the user receives the TGT, the user can present it to the TGS to request a service ticket. For security purposes, Windows 2000 will verify that the user account has not been disabled. If it has, the KDC will not issue new service tickets to the user.
Service ticket. The service ticket is issued to a user by the TGS in response to the user submitting a TGT. Once the user has a service ticket, the user can present this to a network service in order to authenticate with the service and establish a session. The service ticket is encrypted using the key that is shared between the KDC. This ensures that the target server is authenticated because only the target server can decrypt the session.
Referral ticket. The referral ticket is actually a TGT to the domain where the resource is located and is issued any time a user attempts to connect to a target server that is a member of a different domain. The AS and TGS functions are separate within the KDC, permitting the user to use the TGT obtained from an AS in their domain to obtain service tickets from a TGS in other domains through the use of referral tickets. The referral ticket is encrypted using an interdomain key between the initial domain and the target domain that is exchanged as part of the establishment of transitive trust relationships.

Three exchanges are involved when the client initially accesses a server resource:

AS exchange. Used by the KDC to provide a user with a logon session key and a TGT for future service ticket requests. Once the user is successfully authenticated, a TGT that is valid for the local domain is granted. The TGT has a default lifetime of 10 hours and may be renewed throughout the user's logon session without requiring the user to reenter a password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network.

TGS exchange. Used by the KDC to distribute service session keys and service tickets. The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine. The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The service ticket that is returned is encrypted using the master key shared by the KDC and the target server so only the target server can decrypt the service ticket. The client reads its portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server authentication exchange, which is described next.

Client/server authentication exchange. Used by a user when presenting a service ticket to a target service on the network. Once the client user has the client/server service ticket, a session can be established with the server. The server can decrypt the information coming indirectly from the TGS using its own long-term key obtained from the KDC. The service ticket is then used to authenticate the client user and establish a service session between the server and client. After the ticket's lifetime is exceeded, the service ticket must be renewed to use the service.

Let's look at a three-staged, high-level, step-by-step process of how Kerberos authentication obtains a network service to get a better understanding of how all this works together:

Obtaining the Kerberos TGT

The username, domain name, TGT request, and preauthenticated data are encrypted with the secret key and sent from the workstation to the KDC server.

The KDC server checks the username, extracts the user's secret key, decrypts the preauthentication data, and checks the timestamp.

A message encrypted with the user's secret key is sent to the workstation from the KDC server. The message includes the session key and the TGT that is encrypted with the KDC's long-term key.

The workstation decrypts the message and caches the session key, and the TGT deletes the secret key.

Acquiring a Kerberos session ticket for a network resource

The username, network service name, TGT (that is still encrypted with the KDC's long-term key), and the timestamp encrypted with the session key are sent from the workstation to the KDC server.
The KDC server decrypts the TGT with its long-term key, extracts the session key, decrypts the timestamp, and prepares the session ticket for network service. The session key is sent to the workstation.
The session ticket includes a session key for the client that is encrypted with the client session's key. The session key for network service is encrypted with the network service's long-term key.
The workstation receives and caches the session ticket.

Accessing the network service

The session ticket is sent from the workstation to the network service.
The network service decrypts the network service session key, examines the user access token, and if it is acceptable, grants access.

Now, let's see how the same process would work in a wireless environment to request network service, in this case, e-mail service:

Obtaining the Kerberos TGT

The client associates to the AP.
The AP blocks network access.
The client passes authentication credentials to the AP.

Acquiring of a Kerberos session ticket for a network resource

The AP passes user credentials to the KDC.

The client mutually authenticates with the KDC through the AP. Traffic is encrypted.

The client receives a Kerberos ticket/credentials, enabling it to communicate securely with the AP.

The client provides credentials to and mutually authenticates with the AP.

The AP provides unicast and broadcast WEP keys to the trusted client.

The client is allowed unrestricted access to the network.

Accessing the network service

The client sends a TGT request to the TGS service on the KDC.
The KDC grants a TGT to the client encrypted with the client's password hash.
The client sends a TGT to the TGS, requesting a ticket for the e-mail service.
The TGS sends an e-mail service ticket to the client.

A typical Kerberos implementation in a wireless environment includes several key features and benefits [7]:

Encryption-key distribution is dynamic, and the keys can be changed and securely distributed whenever desired. Key lifetimes can be set from minutes to infinity.
Keys are generated at the start of every session and are allocated on a per-client basis. No sharing of keys among clients is allowed. Key generation also works seamlessly with roaming between APs: new keys are generated when a user begins roaming or when a load-balancing operation is performed.
Mutual authentication ensures that rogue APs cannot capture user data, and encryption prevents a wireless node from operating in RF monitor (sometimes called promiscuous) mode and seeing any user data sent in cleartext format.
Kerberos can scale to support very large networks, and the Kerberos server can be located anywhere on the network. Although the details can be complex, the structure of Kerberos is actually quite elegant and designed for general application in a wired or wireless network. Kerberos is particularly well suited to authentication, encryption, and key distribution on a WLAN.

Some vendors have introduced Kerberos-enabled APs where the AP and the KDC establish reciprocal trust at boot-up. Wireless users associating to the AP mutually authenticate with the KDC and the AP to join the network. By using Kerberos, wireless devices and users fall under the enforcement of existing policies and security procedures many large IT departments have already deployed.

Symbol Technologies is a wireless vendor that supports Kerberos on wireless APs. Symbol calls their proprietary Kerberos KDC appliance the Spectrum24 Mobility Server [8]. The Spectrum24 Mobility Server authenticates usernames and passwords and supports dynamic key distribution, issuing a unique key per session per client and a new key at regular time intervals and on every instance of a roam. Symbol allows two methods of AP integration with Kerberos: with the Kerberos Setup Service (KSS) and without the KSS. The KSS is an optional application provided by Symbol that runs on the KDC server. The KSS is used to administer Symbol's authorized Spectrum24 APs in a Kerberos authentication environment. The KSS has two databases. One database stores valid AP information (AP Setup Account) using each AP's MAC address as the primary identifier. The second database (Kerberos Entry Account) stores Kerberos account information for each AP using the SSID as the primary identifier (all APs with the same SSID are grouped together). Kerberos support is available for Symbol's AP-4131 product [9] without the use of the KSS software. Because the Spectrum 24 Mobility Server is inexpensive in comparison with a large Kerberos infrastructure, it enables the deployment of authentication services at WLAN sites without the high costs associated with a centralized solution across a wide area network.

Kerberos addresses the confidentiality and integrity of information using cryptographic keys, encryption processes, and access control to resources. It does not directly address service availability and attacks. Furthermore, because all of the secret keys are privately held and authentication is performed by the Kerberos TGS and the authentication servers, these servers are vulnerable to both physical attacks and attacks from malicious code. Some of the weaknesses and vulnerabilities of Kerberos are as follows:

A client's secret key is stored temporarily on the client workstation and can be compromised along with the session keys that are also stored on the client's computer and the Kerberos server [10].
Session keys are decrypted and reside on the user's workstation, either in a cache or in a key table. This makes the session key vulnerable to capture.
Kerberos is vulnerable to password guessing. Because a client's password is used in the initiation of the Kerberos request for the service protocol, password guessing through dictionary attacks can be used to impersonate a client. The KDC does not know if a dictionary attack is taking place. Kerberos is vulnerable to a dictionary attack because components of some messages are encrypted with the user's permanent secret key (the one derived from the user's current password) that can, in combination with components of other messages, be correctly deciphered if a correct guess at the user's password is applied to them [11].
Tickets passed between clients and servers in the Kerberos authentication model include timestamp and lifetime information. This allows Kerberos clients and Kerberized servers to limit the duration of their user's authentication. The specific length of time for which a user's authentication remains valid after an initial ticket is issued is implementation dependent. Replay attacks can be accomplished on Kerberos if the compromised tickets are used within an allotted time window. Kerberos systems typically use a short enough ticket lifetime to prevent brute force and replay attacks. In general, an authentication ticket should have as short a lifetime as is reasonable. Ideally, the authentication ticket's lifetime should be no longer than the expected time required to crack the encryption of the ticket [12].
If encryption is not enabled, network traffic is not protected by Kerberos.
If a user changes a password, the secret key is also changed, and the KDC database needs to be updated.
The KDC can become a single point of failure if it becomes inoperable. In this case, no one would be able to access needed resources, which would result in a DoS condition for the users.

Despite some shortcomings, a Kerberos-based approach to wireless security is an efficient, proven, standards-based implementation that supports user roaming while addressing all of the known security deficiencies in the current 802.11 standard [13]. The 802.11i standard, when approved, is expected to provide an extensible framework, allowing a variety of techniques, including Kerberos, to be included for any specific security solution implemented at a given site [14]. Although Kerberos has exceptionally low overhead, making it well suited for WLAN applications, Kerberos is complex and requires training and experience to implement correctly.