# Kerberos

## Summary


Kerberos is a network authentication protocol for client-server applications based on cryptographic keys. It's used in Windows 2000, Windows XP and Windows Server 2003 and later systems. Because it's an open standard, it can also used by non-Windows systems. 

Unlike password-based authentication systems, passwords are never sent over the network. Kerberos authenticates by verifying identities of users and servers within a trusted environment. As such, Kerberos is inaccessible for outsiders. Once authenticated, the user or client can access multiple services without needing to authenticate again for each service. Encrypted tickets are used instead of passwords. 

Security aspects covered by Kerberos include authentication, access control, and key exchange.

## Discussion

### What are some essential Kerberos terms that a beginner should know?

Here are some essential Kerberos terms: 

    + **Principal**: This is a unique identity. Because Kerberos supports mutual authentication, both users and network resources have principals.
    + **Realm**: Called *domain* in Windows, this is a logical grouping of resources and identities.
    + **Ticket**: Ticket is an encrypted block of data that authenticates the user. Because of tickets, we don't need to transmit clear passwords over the Kerberos infrastructure. Tickets come with a configurable time expiry.For example, `jdoe@SALES.WIDGET.COM` is a principal for user `jdoe` within the realm `SALES.WIDGET.COM`. It's quite possible for users to have multiple principals in different realms with different access rights. Another example is users enter the system in one realm and access resources in other realms. 


### Could you give an overview of the Kerberos' authentication flow?

Central to Kerberos is the **Key Distribution Center (KDC)** that has a **database** of trusted principals, the **Authentication Service (AS)**, and the **Ticket-Granting Service (TGS)**.

When a user logs into a client machine, she supplies a password. To gain access to network services, Kerberos protocol is invoked to authenticate the user. However, network services don't do the authentication on their own. KDC (and its AS) is the trusted third party that does this. The user's principal, and not the password, is sent to the KDC. KDC checks this against its database, authenticates the user and sends back the Ticket-Granting Ticket (TGT). All this happens transparent to the user when she logs in or invokes the `kinit` command. 

When the client wants to access a service, it presents the TGT to the TGS, which generates service session key and a service ticket containing this key. Whenever client wants, it presents the service ticket to the service. The client and the service can now start communicating, with all communication encrypted with service session key. 


### What are the different tickets used in Kerberos?

Kerberos has essentially two tickets. One is issued by the AS during authentication. The other is issued by the TGS when a service is requested.

AS issues the **Ticket Granting Ticket (TGT)**. TGT is a ticket to tell the TGS that the client has already been authenticated. 

TGS issues the **Service Ticket** after validating the TGT. This enables the client to access a service. Service ticket contains client's IP address, timestamp, and the service session key. 

Both tickets are encrypted. Although the client is in possession of these tickets, it can't read them. The TGT is meant for the TGS. The service ticket is meant for the service provider. 


### What are the different keys used in Kerberos?

The following keys are used in Kerberos: 

    + **Principal Key**: Based on the principal's password, this encrypts the TGT and the session key between client and AS.
    + **Session Key**: This is generated by the KDC during authentication and sent to the client. This is used to encrypt communication between client and TGS. In particular, TGT, service ticket request, service ticket, and service session key are encrypted using this.
    + **Ticket Granting Service (TGS) Key**: This encrypts the TGT. The TGS uses this key to decrypt the TGT. TGS then checks that TGT hasn't expired and generates the service ticket and service session key.
    + **Service Key**: This encrypts the service ticket. It's available within the KDC and also with the service provider.
    + **Service Session Key**: This is used to encrypt all communication between the client and the service. This is generated in the TGS.

### What are the main advantages of using Kerberos?

Here are some advantages of Kerberos:

    + **Mutual Authentication**: Client and server authenticate each other. This protects clients from connecting to a bogus server.
    + **Open Standard**: It's based on RFC 4120. Non-Windows systems that implement this RFC can also use Kerberos.
    + **Delegation**: Also called *authentication forwarding*, a service can access remote resources on behalf of the client using the client's identity.
    + **Smart Card Logon**: Beyond password logon, two-factor authentication using a smart card and PIN is possible.
    + **Passwords & Keys**: User passwords are never sent over communication links. Eavesdroppers can't get hold of passwords. Secret keys are sent only in encrypted form. There's support for both symmetric and asymmetric keys.
    + **Encrypted Sessions**: Service session key shared between the client and a service can be used to encrypt all conversation pertaining to the service.
    + **Integrated Sessions**: Once authenticated, client can access a service without having to re-authenticate, until the ticket expires.
    + **Renewable Sessions**: After the first session, subsequent sessions are setup faster. Server authenticates the client immediately without involving the KDC.

### What's the difference between Kerberos impersonation and delegation?

Clients are authorized to access certain services but the services themselves run in a different security context, such as on a different thread, process or machine. Services acquire client credentials (such as service tickets) and use these to obtain resources on behalf of the clients. In some sense, services therefore impersonate the clients they serve.

There are four impersonation levels: anonymous, identify, impersonation and delegation. If the service is on the same computer as the client process, it can impersonate the client to access network resources. If the service is on a remote computer, it can impersonate the client for accessing resources on the service's computer. With delegation, the service can impersonate the client even when accessing resources on another computer. 

Let's assume that a user requests data via a web server but the data resides on a different database server. The web server delegates to the database server to obtain necessary data from the database. Within the security context of the database server, which accesses the database on the same machine, we can say that impersonation happens.  


### How is Kerberos related to GSSAPI?

**Generic Security Service API (GSSAPI)** is a standard interface, defined by RFC 2743, that provides a generic authentication and secure messaging interface. Multiple security mechanisms can be plugged in so long as they conform to GSSAPI. IETF has defined two mechanisms: **Kerberos V5** via RFC 1964 and **Simple Public Key Mechanism (SPKM)** via RFC 2025. 

GSSAPI is an abstraction that must be accompanied by a security mechanism. The advantage is that applications are not tied to a particular mechanism. Migration is possible, such as, from SPKM to Kerberos V5. In fact, an implementation might support multiple mechanisms and applications can choose the mechanism at runtime. However, both client and server must negotiate to use the same mechanism. 

GSSAPI was designed with the following goals: 

    + **Mechanism independence**: Applications need not concern with the security mechanism such as the type of cryptographic keys used.
    + **Protocol environment independence**: API is not tied to particular communications protocol.
    + **Protocol association independence**: A single API implementation can be used by different application modules that possibly use different communications protocols.

### What are some limitations of Kerberos?

Kerberos is only as secure as the passwords being used. Weak passwords make the system vulnerable to brute force attacks. During protocol use, encryption keys are stored in memory in unencrypted form. Kerberos can't do anything about compromised user endpoints, authentication servers or KDC. If the authentication server is down, new users can't login. *Pass the Ticket* attack involves getting access to a ticket, moving laterally within the network and gaining access to critical systems. 

Kerberos has strict timing requirements. Usually Network Time Protocol (NTP) daemons are used for clock synchronization. NTP therefore becomes a dependency. 

If each service requires a different host name, each must use its own keys. This complicates deployment of virtual hosting and clusters. Kerberos works in a trusted environment and therefore hard to use on the public Internet where untrusted or unknown clients may want to connect. 

Kerberos has worked well within the enterprise but hasn't been adopted in the cloud. A Kerberos ticket contains an encrypted key that could be hacked. Cloud services prefer to use SAML 2.0, OAuth 2.0 or OpenID Connect. In fact, cloud services have been poor in adopting identity federation standards. 

## Milestones

1978

Researchers Roger Needham and Michael Schroeder invent a protocol based on symmetric keys. This protocol aims to securely establish session keys between two parties to protect further communication.  The **Needham–Schroeder symmetric key protocol** forms the basis for Kerberos. 

1983

At MIT, Project Athena is launched with the goal of creating a distributed computing environment for educational purposes. The idea is to have thin clients and let servers do the demanding computations. As part of this project, **Kerberos** is invented for authentication and single sign-on. 

1988

At the Usenex conference, the Kerberos v4 protocol is described for the first time. This makes Kerberos one of the oldest authentication protocols since many others come years later: SAML (2002), WS-Federation (2003), OAuth2 (2010) and OpenID Connect (2014). Versions 1-3 of the protocol remained internal to MIT. 

Jan  
1989

**Kerberos v4** is released. It uses DES for encryption. Due to export restrictions, Kerberos can't be used outside the U.S. An alternative implementation from Sweden called **KTH-KRB** is released years later for non-U.S. markets. However, v4 has limitations: weak DES encryption, misuse of PCBC mode of DES, ticket lifetime can't be longer than about 21 hours, delegation not supported. 

1993

**Kerberos v5** is released and standardized by IETF as RFC 1510. It overcomes many limitations of v4. It uses ASN.1 syntax. It adds new modes for DES. AES encryption is supported. Ticket lifetimes are much longer. Delegation is supported. It allows for unkeyed checksums (CRC, MD5, SHA-1) and keyed checksums (HMAC with MD5 or SHA-1). This is also the year when Microsoft decides to adopt Kerberos in its products. 

1999

Microsoft releases Windows Server 2000 with Kerberos as the default authentication protocol, thus replacing NTLM. There's no separate KDC database. Instead, information comes from Active Directory (AD). With the subsequent growth of AD and AD-enabled apps, use of Kerberos grows.

2005

**RFC 4120** clarifies many aspects of the v5 protocol and obsoletes the earlier RFC 1510 of 1993. **GSS-API** specification is also released as RFC 4121. 

2007

**MIT Kerberos Consortium** is formed for the continued development and promotion of Kerberos in a more open manner rather than being internal to MIT. For some time, this is renamed to MIT Kerberos & Internet Trust Consortium or MIT-KIT, but later this name is retired.