This section provides the definition of the objects and terms, knowledge of which is essential for the subsequent description of the Kerberos protocol. Since many definitions are based on others, wherever possible I have tried to put them in order so that the meaning of a term is not given before defining it. However, it may be necessary to read this section twice to fully understand all the terms.
The term realm indicates an authentication administrative domain. Its intention is to establish the boundaries within which an authentication server has the authority to authenticate a user, host or service. This does not mean that the authentication between a user and a service that they must belong to the same realm: if the two objects are part of different realms and there is a trust relationship between them, then the authentication can take place. This characteristic, known as Cross-Authentication will be described below.
Basically, a user/service belongs to a realm if and only if he/it shares a secret (password/key) with the authentication server of that realm.
The name of a realm is case sensitive, i.e. there is a difference between upper and lower case letters, but normally realms always appear in upper case letters. It is also good practice, in an organization, to make the realm name the same as the DNS domain (in upper case letters though). Following these tips when selecting the realm name significantly simplifies the configuration of Kerberos clients, above all when it is desired to establish trust relationships with subdomains. By way of example, if an organization belongs to the DNS domain example.com, it is appropriate that the related Kerberos realm is EXAMPLE.COM.
A principal is the name used to refer to the entries in the authentication server database. A principal is associated with each user, host or service of a given realm. A principal in Kerberos 5 is of the following type:
However, in practice a maximum of two components are used. For an entry referring to a user the principal is the following type:
The instance is optional and is normally used to better qualify the type of user. For example administrator users normally have the admin instance. The following are examples of principals referred to users:
If, instead, the entries refer to services, the principals assume the following form:
The first component is the name of the service, for example imap, AFS, ftp. Often it is the word host which is used to indicate generic access to the machine (telnet, rsh, ssh). The second component is the complete hostname (FQDN) of the machine providing the requested service. It is important that this component exactly matches (in lower case letters) the DNS reverse resolution of the application server’s IP address. The following are valid examples of principals referring to services:
It should be noted that the last case is an exception because the second component is not a hostname but the name of the AFS cell that the principal refers to. Lastly, there are principals which do not refer to users or services but play a role in the operation of the authentication system. An overall example is krbtgt/REALM@REALM with its associated key is used to encrypt the Ticket Granting Ticket (we’ll look at this later).
In Kerberos 4 there can never be more than two components and they are separated by the character “.” instead of “/” while the hostname in the principals referring to services is the short one, i.e. not the FQDN. The following are valid examples:
A ticket is something a client presents to an application server to demonstrate the authenticity of its identity. Tickets are issued by the authentication server and are encrypted using the secret key of the service they are intended for. Since this key is a secret shared only between the authentication server and the server providing the service, not even the client which requested the ticket can know it or change its contents. The main information contained in a ticket includes:
- The requesting user’s principal (generally the username);
- The principal of the service it is intended for;
- The IP address of the client machine from which the ticket can be used. In Kerberos 5 this field is optional and may also be multiple in order to be able to run clients under NAT or multihomed.
- The date and time (in timestamp format) when the tickets validity commences;
- The ticket’s maximum lifetime
- The session key (this has a fundamental role which is described below);
Each ticket has an expiration (generally 10 hours). This is essential since the authentication server no longer has any control over an already issued ticket. Even though the realm administrator can prevent the issuing of new tickets for a certain user at any time, it cannot prevent users from using the tickets they already possess. This is the reason for limiting the lifetime of the tickets in order to limit any abuse over time.
Tickets contain a lot of other information and flags which characterize their behavior, but we won’t go into that here. We’ll discuss tickets and flags again after seeing how the authentication system works.
As you can see Kerberos often needs to encrypt and decrypt the messages (tickets and authenticators) passing between the various participants in the authentication. It is important to note that Kerberos uses only symmetrical key encryption (in other words the same key is used to encrypt and decrypt). Certain projects (e.g. pkinit) are active for introducing a public key system in order to obtain the initial user authentication through the presentation of a private key corresponding to a certified public key, but since there is no standard we’ll skip this discussion for now.
Kerberos 4 implements a single type of encryption which is DES at 56 bits. The weakness of this encryption plus other protocol vulnerabilities have made Kerberos 4 obsolete. Version 5 of Kerberos, however, does not predetermine the number or type of encryption methodologies supported. It is the task of each specific implementation to support and best negotiate the various types of encryption. However, this flexibility and expandability of the protocol has accentuated interoperability problems between the various implementations of Kerberos 5. In order for clients and application and authentication servers using different implementations to interoperate, they must have at least one encryption type in common. The difficulty related to the interoperability between Unix implementations of Kerberos 5 and the one present in the Active Directory of Windows is a classic example of this. Indeed, Windows Active Directory supports a limited number of encryptions and only had DES at 56 bits in common with Unix. This required keeping the latter enabled, despite the risks being well known, if interoperability had to be guaranteed. The problem was subsequently solved with version 1.3 of MIT Kerberos 5. This version introduced RC4-HMAC support, which is also present in Windows and is more secure than DES. Among the supported encryptions (but not by Windows) the triple DES (3DES) and newer AES128 and AES256 are worth mentioning.
As stated above, one of the aims of the Kerberos protocol is to prevent the user’s password from being stored in its unencrypted form, even in the authentication server database. Considering that each encryption algorithm uses its own key length, it is clear that, if the user is not to be forced to use a different password of a fixed size for each encryption method supported, the encryption keys cannot be the passwords. For these reasons the string2key function has been introduced, which transforms an unencrypted password into an encryption key suitable for the type of encryption to be used. This function is called each time a user changes password or enters it for authentication. The string2key is called a hash function, meaning that it is irreversible: given that an encryption key cannot determine the password which generated it (unless by brute force). Famous hashing algorithms are MD5 and CRC32.
In Kerberos 5, unlike version 4, the concept of password salt has been introduced. This is a string to be concatenated to the unencrypted password before applying the string2key function to obtain the key. Kerberos 5 uses the same principal of the user as salt:
Kpippo is the encryption key of the user pippo and Ppippo is the unencrypted password of the user.
This type of salt has the following advantages:
- Two principals belonging to the same realm and having the same unencrypted password, still have different keys. For example, imagine an administrator having a principal for everyday work (pippo@EXAMPLE.COM) and one for administrative work (pippo/admin@EXAMPLE.COM). It is very likely that this user has set the same password for both principals for reasons of convenience. The presence of the salt guarantees that the related keys are different.
- If a user has two accounts in different realms, it is fairly frequent that the unencrypted password is the same for both realms: thanks to the presence of the salt, a possible compromise of an account in one realm, will not automatically cause the other to be compromised.
A null salt can be configured for compatibility with Kerberos 4. Vice versa, for compatibility with AFS, it is possible to configure a salt which is not the complete name of the principal, but simply the name of the cell.
Having discussed the concepts of encryption type, string2key and salt, it is possible to check the accuracy of the following observation: in order that there is interoperability between the various Kerberos implementations, it is not sufficient to negotiate a common type of encryption, but the same types of string2key and salt need to be used as well.
It is also important to note that, in explaining the concepts of string2key and salt, reference was only made to the user principals and never to those of servers. The reason is clear: a service, even if it shares a secret with the authentication server, is not an unencrypted password (who would enter it?), but a key which, once generated by the administrator on the Kerberos server, is memorized as it is on the server providing the service.
When a user changes a password or an administrator updates the secret key for an application server, this change is logged by advancing a counter. The current value of the counter identifying the key version, is known as the Key Version Number or more briefly kvno.
We have spoken generically about the authentication server. Since it is the fundamental object involved in the authentication of users and services, we will now take a more in-depth look at it without going into all the details of its operation, which are instead the topic of the section dedicated to protocol operation.
The authentication server in a Kerberos environment, based on its ticket distribution function for access to the services, is called Key Distribution Center or more briefly KDC. Since it resides entirely on a single physical server (it often coincides with a single process) it can be logically considered divided into three parts: Database, Authentication Server (AS) and Ticket Granting Server (TGS). Let’s take a brief look at them.
Note: it is possible to make the server redundant within the realm in a Master/Slave (MIT and Heimdal) or Multimaster structure (Windows Active Directory). How to obtain redundancy is not described by the protocol, but depends on the implementation being used and will not be discussed here.
The database is the container for entries associated with users and services. We refer to an entry by using the principal (i.e. the name of the entry) even if often the term principal is used as a synonym for entry. Each entry contains the following information:
- The principal to which the entry is associated;
- The encryption key and related kvno;
- The maximum validity duration for a ticket associated to the principal;
- The maximum time a ticket associated to the principal may be renewed (only Kerberos 5);
- The attributes or flags characterizing the behavior of the tickets;
- The password expiration date;
- The expiration date of the principal, after which no tickets will be issued.
In order to make it more difficult to steal the keys present in the database, the implementations encrypt the database using the master key, which is associated with the principal K/M@REALM. Even any database dumps, used as backups or for propagation from the KDC master towards the slave, are encrypted using this key, which it is necessary to know in order to reload them.
The Authentication Server is the part of the KDC which replies to the initial authentication request from the client, when the user, not yet authenticated, must enter the password. In response to an authentication request, the AS issues a special ticket known as the Ticket Granting Ticket, or more briefly TGT, the principal associated with which is krbtgt/REALM@REALM. If the users are actually who they say they are (and we’ll see later how they demonstrate this) they can use the TGT to obtain other service tickets, without having to re-enter their password.
The Ticket Granting Server is the KDC component which distributes service tickets to clients with a valid TGT, guaranteeing the authenticity of the identity for obtaining the requested resource on the application servers. The TGS can be considered as an application server (given that to access it it is necessary to present the TGT) which provides the issuing of service tickets as a service. It is important not to confuse the abbreviations TGT and TGS: the first indicates a ticket and the second a service.
As we have seen, the users and services share a secret with the KDC. For users, this secret is the key derived from their password, while for services, it is their secret key (set by the administrator). These keys are called long term, since they do not change when the work session changes.
However, it is necessary that the user also shares a secret with the service, at least for the time in which a client has a work session open on a server: this key, generated by the KDC when a ticket is issued, is called the Session Key. The copy intended for the service is enveloped by the KDC in the ticket (in any case their application server knows the long term key and can decode it and extract the session key), while the copy intended for the user is encapsulated in an encrypted packet with the user long term key. The session key plays a fundamental role in demonstrating the authenticity of the user which we will see in the following paragraph.
Even if the user principal is present in a ticket and only the application server can extract and possibly manage such information (since the ticket is encrypted with the secret key of the service), this is not enough to guarantee the authenticity of the client. An impostor could capture (remember the hypothesis of an open and insecure network) the ticket when it is sent by a legitimate client to the application server, and at an opportune time, send it to illegitimately obtain the service. On the other hand, including the IP addresses of the machine from where it is possible to use it is not very useful: it is known that in an open and insecure network addresses are easily falsified. To solve the problem, one has to exploit the fact that the client and server, at least during a session have the session key in common that only they know (also the KDC knows it since it generated it, but it is trusted by definition!!!). Thus the following strategy is applied: along with the request containing the ticket, the client adds another packet (the authenticator) where the user principal and time stamp (its at that time) are included and encrypts it with the session key; the server which must offer the service, upon receiving this request, unpacks the first ticket, extracts the session key and, if the user is actually who he/she says, the server is able to unencrypt the authenticator extracting the timestamp. If the latter differs from the server time by less than 2 minutes (but the tolerance can be configured) then the authentication is successful. This underlines the criticality of synchronization between machines belonging to the same realm.
The possibility exists for an impostor to simultaneously steal both the ticket and the authenticator and use them during the 2 minutes the authenticator is valid. This is very difficult but not impossible. To solve this problem with Kerberos 5, Replay Cache has been introduced. In application servers (but also in TGS), there exists the capacity to remember authenticators which have arrived within the last 2 minutes, and to reject them if they are replicas. With this the problem is resolved as long as the impostor is not smart enough to copy the ticket and authenticator and make them arrive at the application server before the legitimate request arrives. This really would be a hoax, since the authentic user would be rejected while the impostor would have access to the service.
The client never keeps the user’s password, nor does it memorise the secret key obtained by applying string2key: they are used to decrypt the replies from KDC and immediately discarded. However, on the other hand, to implement the single sign-on (SSO) characteristic, where the user is asked to enter the password just once per work session, it is necessary to memorise the tickets and related session key. The place where this data is stored is called the “Credential Cache”. Where this cache needs to be located does not depend on the protocol, but varies from one implementation to another. Often for portability purposes they are located in the filesystem (MIT and Heimdal). In other implementations (AFS and Active Directory), in order to increase security in the event of vulnerable clients, the credential cache is placed in an area of the memory accessible only to kernels and not swappable on the disk.