CS406: Information Security

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

Here are some essential Kerberos terms:

Term	Name	Description
UPN	User principal name	A principal that identifies a user in a given realm, name with the format <shortname><@REALM> or <shortname>/admin@<REALM>
SPN	Server principal name	A principal that identifies a service on a specific host in a given realm, with the format <shortname>/<hostname>@<REALM>
TGT	Ticket-granting ticket	A special ticket type granted to a user after success fully authenticating to the AS
KDC	Key distribution center	A Kerberos server that contains three components: Kerberos database, AS, and TGS
AS	Authentication service	A KDC service that issues TGTs
TGS	Ticket-granting service	A KDC service that validates TGTs and grants service tickets

Important abbreviations in Kerberos. Source: Echeverria and Spivey 2015, table 4-1.

• 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).

Kerberos architecture. Source: IBM 2015.

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:

Kerberos protocol flow showing the use of keys. Source: Oracle 2014, fig. 21.5

• 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:

	NTLM	Kerberos
Cryptography	Symmetric	Symmetric and/or Asymmetric
Trusted 3rd Party	Domain Controller	Domain Controller with KDC Domain Controller and Enterprise CA
Supported Clients	Windows 9x, Me, NT4, 2000 and above	Windows 2000 and above
Features	Slow auth (pass thru)	Ticketing
	No mutual AuthN	Mutual AuthN
	No delegation	Delegation
	Proprietary	Open Standard
	Lamer data protection	Cryptographic data protection

Comparing Kerberos with NTLM. Source: Harbar 2009, slide 12.

• 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.

Kerberos impersonation and delegation. Source: Kaushal 2010, slide 5.

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.

A multi-mechanism GSSAPI implementation. Source: Oracle 2018, fig. 7-1.

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.