This tutorial was written by Fulvio Ricciardi and is reprinted here with his permission. Mr. Ricciardi works at the National Institute of Nuclear Physics in Lecce, Italy. He is also the author of the Linux project zeroshell.net, where he originally published this tutorial. Thank you, Mr. Ricciardi!Document version:1.0.3 (11/27/2007)Author:Fulvio Ricciardi (Fulvio.Ricciardi@le.infn.it)INFN - the National Institute of Nuclear PhysicsComputing and Network Services - LECCE, Italy1Introduction2Aims3Definitions of components and terms3.1 Realm3.2 Principal3.3 Ticket3.4 Encryption3.4.1 Encryption type3.4.2 Encryption key3.4.3 Salt3.4.4 Key Version Number (kvno)3.5 Key Distribution Center (KDC)3.5.1 Database3.5.2 Authentication Server (AS)3.5.3 Ticket Granting Server (TGS)3.6 Session Key3.7 Authenticator3.8 Replay Cache3.9 Credential Cache4Kerberos Operation4.1 Authentication Server Request (AS_REQ)4.2 Authentication Server Reply (AS_REP)4.3 Ticket Granting Server Request (TGS_REQ)4.4 Ticket Granting Server Replay (TGS_REP)4.5 Application Server Request (AP_REQ)4.6 Pre-Authentication [4.6 ApplicationServer Replay (AP_REP) missing]5Tickets in-depth5.1 Initial tickets5.2 Renewable tickets5.3 Forwardable tickets6Cross Authentication6.1 Direct trust relationships6.2 Transitive trust relationships6.3 Hierarchical trust relationships1 Introduction
The Kerberos protocol is designed to provide reliable authentication over open and insecure networks where communications between the hosts belonging to it may be intercepted. However, one should be aware that Kerberos does not provide any guarantees if the computers being used are vulnerable: the authentication servers, application servers (imap, pop, smtp, telnet, ftp, ssh , AFS, lpr, ...) and clients must be kept constantly updated so that the authenticity of the requesting users and service providers can be guaranteed.
The above points justify the sentence: "Kerberos is an authentication protocol for trusted hosts on untrusted networks". By way of example, and to reiterate the concept: Kerberos' strategies are useless if someone who obtains privileged access to a server, can copy the file containing the secret key. Indeed, the intruder will put this key on another machine, and will only have to obtain a simple spoof DNS or IP address for that server to appear to clients as the authentic server. 2 Aims
Before describing the elements that make up the Kerberos authentication system and looking at its operation, some of the aims the protocol wishes to achieve are listed below: The user's password must never travel over the network; The user's password must never be stored in any form on the client machine: it must be immediately discarded after being used; The user's password should never be stored in an unencrypted form even in the authentication server database; The user is asked to enter a password only once per work session. Therefore users can transparently access all the services they are authorized for without having to re-enter the password during this session. This characteristic is known as Single Sign-On; Authentication information management is centralized and resides on the authentication server. The application servers must not contain the authentication information for their users. This is essential for obtaining the following results: The administrator can disable the account of any user by acting in a single location without having to act on the several application servers providing the various services; When a user changes its password, it is changed for all services at the same time; There is no redundancy of authentication information which would otherwise have to be safeguarded in various places; Not only do the users have to demonstrate that they are who they say, but, when requested, the application servers must prove their authenticity to the client as well. This characteristic is known as Mutual authentication; Following the completion of authentication and authorization, the client and server must be able to establish an encrypted connection, if required. For this purpose, Kerberos provides support for the generation and exchange of an encryption key to be used to encrypt data. 3 Definition of the components and terms
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.3.1 Realm
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. 3.2 Principal
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:
component1/component2/.../componentN@REALM
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:
pippo@EXAMPLE.COM admin/admin@EXAMPLE.COM pluto/admin@EXAMPLE.COM
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:
imap/mbox.example.com@EXAMPLE.COMhost/server.example.com@EXAMPLE.COMafs/example.com@EXAMPLE.COM
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:
pippo@EXAMPLE.COM pluto.admin@EXAMPLE.COM imap.mbox@EXAMPLE.COM3.3 Ticket