Home

The KerberosV Network Authentication Scheme

Kerberos is a network authentication protocol designed at MIT in the mid-eighties.

The overall idea behind Kerberos is to introduce a trusted third party onto the network that can serve to provide trust between users, servers, and services without passing credentials and duplicating authentication on the network. It is also an effective way of protecting the network from the bad guys on the inside of the network. This trusted third party is the Kerberos server.

Kerberos was designed during a time when a lot of cleartext protocols were in wide use, such as Telnet, rlogin, rsh, and so on. These protocols typically passed login information over the network in such a way that unintended recipients of the information could intercept it. Despite the fact that today many of these protocols are replaced by SSH or protected using SSL, Kerberos is still a strong candidate for a network authentication solution because user account information for multiple systems can be centralized in one database.

Like a temp badge

From a high level, the security architecture of Kerberos is similar to obtaining a temporary badge to gain access to an organization's facilities.

The key concept is authentication, or validation of a user's identity. Say someone comes to a company's building and they need to go somewhere to attend a meeting, and then to another location in the building to see someone else, and then to another location to inspect something else. This user should (hopefully) be stopped by the security guard and have their identity validated. To do this, they may present their driver's license and sign a form. By seeing their driver's license, and their signature, the security guard can be reasonably sure that they are who they say they are and grant them access to the building.

So the user finishes their meeting, and needs to go to another location at the facility to talk to someone else. They would once again provide their driver's license and signature to the security guard at that part of the facility. Now say they needed to go to another part of the building to inspect something over there; they would once again provide their driver's license and signature to get access.

2 problems exist with this scenario.

  • It is a pain in the behind for the guy to dig out his wallet and driver's license every time his identity needs to be validated.
  • Every time he produces his wallet and/or driver's license, and signature, it carries a risk of him dropping it and losing it or having it stolen.

A resourceful way to solve these problems is for the security guard to validate the user's identity once, and give the visitor a visitor's badge that lists this person as identified. Then, posessing this badge, our visitor can show up at each of the locations in the building and simply show his badge to get the access that he needs. Two problems are solved:

  • He doesn't have to prove his identity with official credentials to 3 individuals at different times.
  • He doesn't run the risk of losing his wallet or driver's license or having his signature forged at 3 different locations.

As long as our visitor carries his temporary badge with him, he can illustrate to others that his identity has been validated and he can then be further authorized to other locations within the facility. Furthermore, if the badge is tagged with a date it is good for the current date only; meaning no one can swipe the badge and gain access to the facilities at a later date.

Terminology

Realm
A network that uses Kerberos, composed of one or more servers called KDCs and a potentially large number of clients. Kerberos realms are notated in all upper case to differentiate them from a DNS domain name. Oftentimes, the Kerberos realm is just the uppercase version of the DNS domain.

  • DNS domain: example.com
  • Kerberos realm: EXAMPLE.COM
Principal
The unique name of a user or service allowed to authenticate using Kerberos.
Ticket
A temporary set of electronic credentials that verify the identity of a client for a particular service.
Key
A cryptographic key used for encryption and decryption of data. All principals in a realm have their own key, which for users is derived from a password or is randomly set for services.
KDC
Key Distribution Center. Issues Kerberos tickets to clients.
TGS
Ticket Granting Server. A server that issues tickets for a desired service which are in turn given to users for access to the service.
TGT
Ticket Granting Ticket. A special ticket that allows the client to obtain additional tickets without applying for them from the KDC.
AS
Authentication Service. Validates a user's ID and password and issues the TGT to the user.
Client
An entity on the network (a user, a host, or an application) that can receive a ticket from Kerberos.
Services
A program accessed over the network. FTP, SSH, and Telnet are common services.
Kerberize
Refers to configuring a network service to aupport authentication within a Kerberos realm.

Process overview

  1. A Kerberos server is established on the network. The term "Kerberos server" usually indicates a server providing the roles of the KDC, TGS, and AS.
  2. A principal database is configured on the KDC and a set of credentials are created within the database. User principles will have a user name and key in the form of a passphrase. Service and host principles will be given a service or host name and usually a random key. Microsoft Active Directory is used as the authentication and storage backend for the Kerberos functionality on a Windows domain.
  3. A user contacts the AS on the KDC and authenticates as a valid user in order to receive a TGT. This TGT is a token given to the user to validate that the user has been verified and is able to use services within the realm. The TGT carries no privileges to access services within the realm. It only permits the user to request service tickets from the TGS in order to access services.
  4. When the user wishes to access a network service, they present their TGT to the TGS, who verifies that the ticket is valid and returns to them a service ticket.
  5. The user sends the service ticket to the destination service, where the service validates that the ticket is current and issued to the user by the Kerberos server. Upon validation, the user is authenticated and can be authorized to access the desired service.

More detailed overview

See section 2.1 at http://www.pdc.kth.se/heimdal/heimdal.html.

Kerberos implementations

KerberosIV vs. KerberosV

  • v4 = outdated, evil and insecure (DES)
  • v5 = modern, IETF standardized, extensible, better security

Microsoft Windows

Microsoft's implementation of Kerberos was introduced as the default authentication mechanism beginning with Windows 2000. It tends to follow the standards track closely and the implementation mimics MIT Kerberos. Two important differences exist between MS Kerberos and the others:

  • MS Kerberos defaults to backending against Active Directory LDAP.
  • MS has extended their Kerberos to support extensions such as public key authentication using certificates and smart cards.
  • MS only implements DES-CBC-MD5 and DES-CBC-CRC encryption types for MIT interoperability.

Upon logon to a workstation, the user is issued their TGT and a host ticket for the local workstation. Additional tickets are gained transparently as the user attempts to access other services.

Verify Kerberos operation with the Kerberos Ticket Tool (kerbtray.exe) or klist.exe. Both tools are found in the Windows Resource Kit tools.

MIT KRB5

The original Kerberos implementors. MIT KRB5 is the popular implementation for many Linux distributions.

Heimdal KRB5

Mostly written in Sweden, important when the project was started, less so now. Still a robust and popular implementation. Shipped under a BSD-style license, non-export encumbered. Heimdal is implemented by default in most (if not all) BSD flavors.

Implementing and utilizing a Heimdal Kerberos realm

Create a Kerberos 5 realm using Heimdal

  1. Create a Kerberos configuration file that is used for both client and server operations (krb5.conf(5)).
  2. Create a "master" key to be used to encrypt all of the principles in the database (kstash).
  3. Launch the Kerberos database administration utility (kadmin(8)) to operate in local mode: kadmin -l.
  4. From kadmin, initialize the realm database by typing init MY.REALM, where MY.REALM is the actual Kerberos realm name. You are prompted to input values for realm-wide maximum ticket lifetime and maximum renewable time.
  5. 6 new principles are created as the database is initialized. View with list -s *.
  6. Add a user principal to the Kerberos database by typing add principal_name, where principal_name is the principal to add. Set a strong password for this principal.
  7. Start the KDC using kdc(8).

Authenticate to Kerberos and retrieve a TGT

  1. Retrieve a TGT from the KDC using kinit(1).
  2. View your Kerberos cache using klist(1).

Create a Kerberized SSH service

  1. Create a host principal for the SSH server in the Kerberos database. (add --random-key --use-defaults host/server.example.com)
  2. Extract this ticket to the keytab file for the host (ext_keytab --keytab=/etc/kerberosV/krb5.keytab host/server.example.com)
  3. Enable GSSAPIAuthentication in the sshd_config file and restart sshd(8).

Connect to the Kerberized SSH service from a client

  1. Create a .ssh/config enabling GSSAPIAuthentication and specifying a PreferredAuthentications list containing gssapi-with-mic.
  2. SSH to the host and verify that GSSAPI authentication works (ssh -v hostname.domain.tld).

Heimdal utility suite

The following list of applications are part of the Heimdal KerberosV package:

  • kdc(8): Kerberos 5 server
  • kadmind(8): Kerberos DB admin service
  • kpasswdd(8): Password changing service
  • kstash(8): Creates KDC master password
  • kinit(1): Acquires TGT
  • klist(1): Lists Kerberos tickets
  • kpasswd(1): Modifies Kerberos password
  • passwd(1): Same as kpasswd(1) (OpenBSD)
  • kadmin(8): Kerberos administration utility for local and/or remote administration o the Kerberos database

Security notes

  • The user's password is never transferred over the network. It is only required when the user authenticates against the KDC to receive a TGT. The TGT is good for the duration of a login session and serves as the authentication token for future contact with the KDC. The password is never required again until the user renews their TGT or begins a new session.
  • Time synchronization is critical in a Kerberos setting. Timestamps are used in tickets to prevent replay attacks and limit ticket validity timeframes. Tickets are generally issued for finite lengths of time after which they expire and become invalid. Keeping clocks in the Kerberos realm in sync is critical. The use of NTP is recommended.
  • As always, weak user passwords present a potential vulnerability. A guessed password allows an attacker to acquire a TGT issued to another user. A dictionary attack can be run against captured Kerberos communication packets containing data encrypted with a user's key (password.) Kerberos will not defend against keyloggers to steal the user's password, although it essentially lessens the number of times a user has to enter their password into the keyboard.
  • Kerberos uses symmetric encryption - no public keys exist in the architecture.
  • Compromise of the KDC = Game Over.

Documentation/References

| |