Kerberos Tutorial

This tutorial is not yet complete and I haven't checked the details for absolute accuracy. If you are really interested mail me: kim [@] domain name

Table of contents

Kerberos is not trivial. This tutorial is aimed at three groups:
  • those who want to understand Kerberos at a high level — just look at the pretty pictures ;-)
  • those who have to set up Kerberos
  • those unlucky enough to have to debug Kerberos down to the network packet level.

There are other documents out there, but my head hurt after reading pages of sentences like:
TGS_REP is the reply of the Ticket Granting Server to the previous request. Located inside is the requested service ticket (encrypted with the secret key of the service) and a service session key generated by TGS and encrypted using the previous session key generated by the AS.


The Authentication and Ticket acquisition process

An authorisation to do something.
Ticket Granting Ticket (TGT)
An initial Ticket that confirms to the Realm that you have provided adequate proof of who you claim to be. The actual ticket name is typically
(Designated R below.) An administrative grouping for network services, that typically (but not always) coincides with a network domain or sub-domain (eg Realms are often named the same as the domain but in UPPER CASE (eg DFUSION.COM.AU) (mostly for sanity in troubleshooting AFAIK, although som software seems to assume/enforce upper case).
Authentication Service (AS)
The service that confirms a user's identity.
Ticket Granting Service (TGS)
The service that hands out the TGT once authentication is complete.

Kerberos process in a nutshell
Although the process looks complex, well it is complex, the request/reply pairs (AS: 1 and 2) , (TGS: 3 and 4) are actually very similar, their function is to obtain Tickets. In the first case the Ticket is the master ticket (TGT), in the second it is a ticket for the right-to-use a specific service (eg nfs). The third transaction (AP:5 and 6) is to initiate the required service. Simple!

The numbers here match those in the diagram.

  1. A user initiates the Kerberos authentication client either by logging in to an appropriately configured client machine or by explicitly using a Kerberos client application like "kinit". The user provides their Kerberos username and password and asks to be authenticated for a particular Kerberos Realm (R). kinit sends this initial request (AS_REQ) to the Authentication Service (AS) (Note 0).
  2. The Authentication Service (AS) looks up the user in its database (or it can connect to LDAP). If user is valid the AS generates a random session encryption key (Notes 1,2). The session key (GREEN) is encrypted with the user's password (BLUE) (kept in an encrypted database - KDB) and then sent back to the user along with an "Authenticated User" pass, called the Ticket Granting Ticket (TGT) (YELLOW) (Note 3) that is used to get access to other services. It works on the principle of authenticate once, then trust the user in the local realm for the next few hours at least.
    If the user is who they claim to be then the BLUE password they entered at the client will decrypt the GREEN session key (encrypted with their BLUE password). This means both Client and KDC now both have a shared secret session key and can pass secured data to each other without fear of evesdroppers. Note the password stays within kinit and is NEVER transmitted across the network during a normal Kerberos session.
    The Kerberos authentication process is now complete. The user has a TGT (may be shown as krbtgt/R@R where R is the realm, eg DFUSION.COM.AU).
  3. The user now wants to access a Kerberised service like nfs (eg to mount a Kerberos secured NFS share). The mount client sends a TGS_REQ request asking for access to the service (eg "nfs/hostS.domain@R" for the nfs service on hostS in realm R) (Note 4). The request include a copy of the TGT and a piece of "Authorisation" data encrypted with the GREEN session key (the important bit is that it has the GREEN session key because the user proved they knew a valid password).
  4. The TGS (having approved the request) sends back a Ticket for the requested service (RED). The ticket is encrypted with the service's private key so again the client just treats it as an opaque blob. A NEW random, transient session key (PINK) is created for the future communication between the Client and hostS (ie they both know this key). It is protected from eavesdropping by encrypting it with the GREEN session key.
  5. Finally the client connects to the machine actually providing the service and sends (AP_REQ) the opaque service ticket as well as some "Authentication" data encrypted with the new service session (PINK) key. The service host needs to know this service session key but rather than having it contact the KDC directly a more efficient approach is taken - the (PINK) key is stored inside the encrypted service ticket supplied to the client in the TGS_REP. (Thus the client actually receives two copies of the service session (PINK) key but of course can't access the one locked in the service ticket.) The service host decrypts the service ticket, extracts the service session key and uses it to decrypt the auth token also sent in AP_REQ. (The auth token timestamp is also checked to ensure it is acceptably recent.)
  6. The last stage (AP_REP) many not occur, it is only needed if mutual authentication is required (ie client wants the server to prove it is who it claims to be). If this happens the server just sends back some verification data encrypted with the PINK session key. (If it was an interloper service it would not have been able to obtain the PINK session key from the KDC.

0) There may be an initial AS_REQ/AS_REP "preauth" stage which is not shown here. Packet examples are included below.
1) A random session key is used and then discarded making it harder to do cryptographic attacks based on gathering large samples encrypted with the same key over a long period of time. By the time any current computer could crack the session key it will be useless.
2) A "session" typically lasts up to the order of hours.
3) The TGT is encrypted with the Ticket Granting Server (TGS) private key. The key itself is not sent across the network, and the client cannot decrypt it, so it remains an opaque token as far as the client is concerned.
4) The service names are just conventions, however software tends to assume things about the different components H/D@R so conform to the structure.
5) Don't go talking about yellow and pink keys to others, they'll just look at you strangely. I made up the colours to simplify the description.

Kerberos_Diagram.png (258 Kb)

Encryption Types

To encrypt data one needs both a KEY and an encryption ALGORITHM (referred to here as "encryption type").
Kerberos implementations typically support a number of encryption types whose names include:
  • des-cbc-crc
  • des-cbc-md5
  • aes256-cts-hmac-sha1-96
  • etc.
However encryption technology is constantly evolving and thus client and server cannot afford to support just one technology. Some of the lowest common denominator encryption types are much less secure than the top of the line versions.
At the same time however the client and server are likely to be upgraded at widely varying intervals and it is not practical to upgrade all servers and clients at exactly the same time. So part of the Kerberos protocol is to negotiate encryption algorithms between client and server for the two session keys (which are the only keys they both have to share).

There is one more piece to this puzzle. The KDC keeps all the service keys encrypted ...

The negotiation goes as follows:
  • Client sends a list of encryption types in order of preference that it can handle in the AS_REQ.
  • The KDC looks up a preferentially ordered list of encryption types that it can handle for the relevant session ticket.
  • The KDC then chooses the first encryption type that they both support (ie first match in an the intersection of both sets) (Note A)
  • The session key is now encrypted with the client's private key using the selected encryption type (Algorithm).

Kerberos allows the lists of preferred encryption types to be configured. This is actually necessary in some cases to get Kerberos clients to talk to the servers successfully (because of implementation differences).

The CLIENT has two configuration items:
  • It can specify the TGT encryption type using the krb5.conf property: ++default_tkt_enctypes = ...++
  • It can specify the TGS encryption type using the krb5.conf property: ++default_tgs_enctypes = ...++

The SERVER has several configuration options:
  • permitted_enctypes = This restricts ALL encryption types, TGT, TGS and Principal encryption types.
  • supported_enctypes =

Note A: The intersection is further subset by the list of permitted_enctypes.

In addition the encryption types used to encode the service keys can be specified at creation time (kadmin's ktadd command etc)
GREEN Session Key Encryption type chosen is the 1st match of an intersection between Client Preferred Encryption Type list and the Server Preferred Encryption Types

There's also a complexity to do with highest value keys numbers (KVNO) being used before lower values. The higher value keys effecticvely expire/replace the earlier keys. A simple installation should be able to ignore this complexity.

Setting up Kerberos

This section provides an overview of the initial admin processes with an emphasis on keys and config files. It tries to be system independent but the examples rely on the fact that many implementations are based on the MIT version. It does not detail a step-by-step process but seeks to give an overview so that step-by-step processes documented elsewhere make sense.

There are a number of files to setup. This sections assumes three logical types of server: KDC server, service host, client.
A service host provides a service such as NFS shares or permits ssh login. A client is a user of these services.
A single physical machine may be all three: KDC, service provider, client in which case the various configuration files and databases will be a combination of the requirements for each host type.

Note: This overview does not include a slave KDC which would add unnecessary complexity for an overview. References to kiprop and kpropd (used for master/slave replication) have been omitted.

Kerberos_Config.png (150 Kb)

First we must create the KDB and configuration files.

Note: There are a number of commands and scripts to do this so it is system specific. A script utility kdcmgr or similar may exist on your system that asks questions then creates the kdc.conf, krb5.conf configuration files and runs kdb5_util and kadmin to create the database and add the standard principals.
There are two kadmin commands: kadmin and kadmin.local, the latter is used early in the setup process and can only be run on the KDC.

In the diagram the KDB is shown being created via the kdcmgr create command run on the KDC. It asks a number of questions and performs the following functions:
  • creates kdc.conf, krb5.conf and kadm5.acl files on the KDC.
  • creates an empty Kerberos Database (KDB) and encrypts it with the requested master key (black key in diagram).
  • creates krb5.keytab (and kadm5.keytab ?) databases on KDC.
  • creates a random TGT key (yellow in diagram)
  • may add various other principals including:
    • host/hostK.domain... (host authentication, used by a number of clients/services)
    • kiprop/hostK.domain... (optionally needed for kerberos master/slave replication)
    • kadmin/hostK.domain... (used by kadmind)
    • kadmin/changepw (used by kadmind)
    • kadmin/history (used by kadmind)

The kdcmgr script can be examined to see what it does. Most of the actions reduce to some text editing and a few kadmin commands which can be entered by hand if better understanding of the processes is desired.

KDC configuration files and databases

After creation (either manually or automagically) they should looks something like these (my version is from Solaris):

	kdc_ports = 88,750

		profile = /etc/krb5/krb5.conf
		database_name = /var/krb5/principal
#               admin_keytab = /etc/krb5/kadm5.keytab
		master_key_type = aes128-cts-hmac-sha1-96
		acl_file = /etc/krb5/kadm5.acl
		kadmind_port = 749
		max_life = 8h 0m 0s
		max_renewable_life = 7d 0h 0m 0s
		default_principal_flags = +preauth
		sunw_dbprop_enable = true
		sunw_dbprop_master_ulogsize = 1000

	default_realm = DFUSION.COM.AU
		kdc =
		admin_server =
                kpasswd =

[domain_realm] = DFUSION.COM.AU
# Next line is optional, but doesn't hurt to include even if not used.
# Needed if there is a server named the same as the domain ie rather than
# the more common case of servers named

	default = FILE:/var/krb5/kdc.log
	kdc = FILE:/var/krb5/kdc.log
	kdc_rotate = {
		period = 1d
		versions = 10

	kinit = {
		renewable = true
		forwardable = true

KDB (via kadmin: listprincs)

To view the keytab files use:
  • klist - simple list tool (eg klist -ke)
  • ktutil - keytable editor tool
Refer to man pages for usage.
KDC krb5.keytab (via ktutil)
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3 host/ (AES-256 CTS mode with 96-bit SHA-1 HMAC) 
   2    3 host/ (AES-128 CTS mode with 96-bit SHA-1 HMAC) 
   3    3 host/ (Triple DES cbc mode with HMAC/sha1) 
   4    3 host/ (ArcFour with HMAC/md5) 
   5    3 host/ (DES cbc mode with RSA-MD5)

kadm5.keytab (via ktutil)
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3 kadmin/ (AES-256 CTS mode with 96-bit SHA-1 HMAC) 
   2    3 kadmin/ (AES-128 CTS mode with 96-bit SHA-1 HMAC) 
   3    3 kadmin/ (Triple DES cbc mode with HMAC/sha1) 
   4    3 kadmin/ (ArcFour with HMAC/md5) 
   5    3 kadmin/ (DES cbc mode with RSA-MD5) 
   6    3 changepw/ (AES-256 CTS mode with 96-bit SHA-1 HMAC) 
   7    3 changepw/ (AES-128 CTS mode with 96-bit SHA-1 HMAC) 
   8    3 changepw/ (Triple DES cbc mode with HMAC/sha1) 
   9    3 changepw/ (ArcFour with HMAC/md5) 
  10    3 changepw/ (DES cbc mode with RSA-MD5) 
  11    3           kadmin/changepw@DFUSION.COM.AU (AES-256 CTS mode with 96-bit SHA-1 HMAC) 
  12    3           kadmin/changepw@DFUSION.COM.AU (AES-128 CTS mode with 96-bit SHA-1 HMAC) 
  13    3           kadmin/changepw@DFUSION.COM.AU (Triple DES cbc mode with HMAC/sha1) 
  14    3           kadmin/changepw@DFUSION.COM.AU (ArcFour with HMAC/md5) 
  15    3           kadmin/changepw@DFUSION.COM.AU (DES cbc mode with RSA-MD5)

Although the above KDB and keytab files appear complex they reduce to some relatively simple concepts.
The keytab files store local, multiply encrypted copies of the named keys. Each key is encrypted using all the publicly supported encryption types (encryption algorithms - see previous section). This is done so that the key itself does not have to be known at "runtime" for encryption using an encryption type supported by a particular client/service (encrypted keys are sent around the network).

The kadm5.keytab contains various keys (kadmin/host..., changepw/host... and kadmin/changepw used by the kadmin/kadmind utilities to manage remote password changes etc. These are not further discussed.

This leaves us with several keys of interest:
  • K/M@DFUSION.COM.AU — the Kerberos master key (black key in diagram)
  • krbtgt/DFUSION.COM.AU@DFUSION.COM.AU — the TGT key (it is a randomly generated key and lives in the KDB)
  • host/ — a key representing the KDC host itself. Used by various services for authentication. Encrypted copies of this key are stored in the krb5.keytab file on the KDC host as they may be sent across the network.
  • kim @DFUSION.COM.AU — a user principal. There will be one per human kerberos user. The password is stored in the KDB only. It is never sent across the network.
  • kim/admin@DFUSION.COM.AU — an admin user principal. By convention it is in the form username/admin. The password is stored in the KDB only. It is never sent across the network.

Note “kim” is different to “kim/admin”. Administration is kept separate from normal user authentication by convention to minimise accidents.

Note: Random keys are used in some cases to save humans thinking up secure passwords which they won't ever need to use.

To help understand the commands that produce the files above it helps to group the principals into roughly two classes:
  • principals that have passwords created by humans (eg for user principals or special system principals). These passwords are typically not sent across the network.
    • These are created using: kadmin: addprinc principal[/instance] and the password is then entered manually. Eg: addprinc kim
  • principals with randomly generated passwords (that never need be known by a human) and are typically sent over the network
    • These are created using: kadmin: addprinc -randkey principal[/instance] . The password is randomly generated.
    • These passwords need to be added to the keytab file using: '-+kadmin: ktadd [-k keytab_file] principal[/instance]. Eg ktadd host/
The remaining keys are managed directly by the kerberos daemons and remain in the KDB.

Service Host configuration files and databases

To configure and administer a service host, the first thing to do is copy the krb5.conf file over to it. It does not normally need any other file or database copied over.

The krb5.conf file tells any host how to contact the KDC. It may also be possible to configure some service hosts to obtain their configuration information via DNS (using SRV and TXT records), however an explicit file seems safer.

Before continuing there is something important to understand that can be summarised as follows:
ONLY perform kadmin: addprinc -randkey service/host.domain on the server that IS host.domain.
The addprinc -randkey command does two things:
  1. adds the named identity into the master Kerberos DataBase (KDB) on whatever (remote) server the KDC is located.
  2. adds the identities (random) secret password into the local keytab file (typically /etc/krb5/krb5.keytab )
Only the server providing the specified service should have its secret password encrypted in the local keytab database.
Note: It is important on which server the addprinc -randkey commands are typed.

So for example:
  • host/myhost.... should only be created on myhost (so the secret password gets put into myhost:/etc/krb5/krb5.keytab)
  • nfs/nfshost.... should only be created on nfshost (so the secret password gets put into nfshost:/etc/krb5/krb5.keytab)

Thus on each server you probably ought to create a:
  • host/myhost.... should only be created on myhost (so the secret password gets put into myhost:/etc/krb5/krb5.keytab)
On the NFS server:
  • nfs/nfshost.... (the secret password gets put into nfshost:/etc/krb5/krb5.keytab)

If the KDC and NFS host happen to be the same machine then of course they will just be done together.

At some stage you may also need to create machine specific root identities just as you did for host/*. The distinction between use of host/ and root/ within applications is unclear (to me at least):
  • root/myhost.... [-randkey] - representing the machine root (or root user). Human password or machine ???

To do the above on each server, login to the relevant server and do:
$ kadmin -p kim/admin
kadmin: addprinc ...
kadmin: ktadd ...
kadmin: quit

The admin tool reads the krb5.conf file to find out how to contact the kdc.

If kadmin cannot be run on the relevant server for some reason, there are fiddly ways around creating a server specific keytab file on the kdc (using ktadd -k tmpfile) and then moving it to the server.

Client configuration files

A pure client only needs a krb5.conf file. It generally does not need any other configuration files or databases.

The krb5.conf file tells any host how to contact the KDC. Although it probably doesn't hurt to use the exact same config file as used on the KDC, a more minimal file may be used for simple clients. It may also be possible to configure some clients to obtain their configuration information via DNS (using SRV and TXT records).

An example of one minimal client file (from Apple OS X 10.5 (Leopard)) is:
minimal krb5.conf file
        default_realm = DFUSION.COM.AU
        dns_fallback = yes

[domain_realm] = DFUSION.COM.AU

        DFUSION.COM.AU = {
                kdc =
                admin_server =
                kpasswd =

This example happens to list the (default) port numbers explicitly.

Network Packet Dumps

If you are interested in the data actually going over the network then click on the [+] to expand the following sections.

Client <-> KDC Packets


Client <-> Service Host: AP_REQ/AP_REP examples using NFSv4


Client <-> Service Host: AP_REQ/AP_REP examples using NFSv4 (decrypted)

  • + : A leading plus sign indicates that this word must be present in every object returned.
  • - : A leading minus sign indicates that this word must not be present in any row returned.
  • By default (when neither plus nor minus is specified) the word is optional, but the object that contain it will be rated higher.
  • < > : These two operators are used to change a word's contribution to the relevance value that is assigned to a row.
  • ( ) : Parentheses are used to group words into subexpressions.
  • ~ : A leading tilde acts as a negation operator, causing the word's contribution to the object relevance to be negative. It's useful for marking noise words. An object that contains such a word will be rated lower than others, but will not be excluded altogether, as it would be with the - operator.
  • * : An asterisk is the truncation operator. Unlike the other operators, it should be appended to the word, not prepended.
  • " : The phrase, that is enclosed in double quotes ", matches only objects that contain this phrase literally, as it was typed.


Related Sites