Tech Stuff - Survival Guide - Kerberos

This is a survival guide to Kerberos and specifically Kerberos V (or even Kerberos 5) which was designed by M.I.T.. The previous version - Kerberos IV (Kerberos 4) - is significantly different and is not described here.

Overview

Kerberos 5 (hereafter called Kerberos only) is a network Authentication system defined by RFC 4120 (augmented by RFC 4537 and RFC 5021 both of which add negotiation capabilities but do not change the base protocol).

In addition RFC 4121 defines a method - called GSSAPI (General Security System Application Program Interface) - by which Kerberos aware applications may directly invoke a Kerberos service. GSSAPI has morphed to support other - non Kerberos - security systems.

Kerberos may also be used to transport Authorization information but this is considered to be application specific and is not is defined by the RFCs though generic fields are provided for the carriage of this information (RFC 4120 Section 5.2.6).

Kerberos is widely used throughout the LAN and wide-area networking world and perhaps most notably by MS since Windows 2000. Kerberos makes extensive use of symmetric encryption. You may already feel a headache coming on.

And for the insatiably curious: The name Kerberos is a corruption of Cerberus which was a 3-headed dog in ancient Greek Mythology that guarded the gates of Hades - mostly to stop people leaving when they discovered it was not too much fun after all.

Kerberos Overview

Kerberos provides both network Authentication and a secure method by which Authorization may take place without having to re-enter password or other credentials. It is therefore used to provide what is typically called Single Sign-on (SSO). First, some basic definitions:

Authentication	The process or procedures used to verify that data or information asserting that it originates from a source (person) can only have come from that source (person).
Authorization	When a user has Authenticated they may be Authorized to access, or be denied access to, system/network resources such as files, applications, the ability to send email, browse the Internet and so on. The Authentication process typically provides access to a set of records in a security database that will contain specific access information and/or additional access information based on the accounts membership of one or more groups. The term privilege is sometimes used synonymously for Authorization, thus a user may have enough privileges to access resource X but not resource Y. They are Authorized to access X but not Authorized to access Y.
Credentials	A fancy name for what most of us would call a password (though it can take other forms such as a hardware token or biometric details). Your credentials are a way of proving that you are who you say you are. Since you should be the only person (or group of persons in some cases) who know or have access to your credentials. When you present them to a system or or network and they are the same as those previously securely entered and stored in some form of security database it proves that you are who you say you are. After some form of exchange which will include presenting your credentials (for instance, typing in a password) you will be Authenticated. Once Authenticated you may still need to be Authorized to access resources or information.

Kerberos makes no assumptions about, in fact it generally distrusts, the security of the underlying network. It does, however, assume that application hosts and especially hosts used in the operation of the Kerberos Key Distribution Center (the KDC) are secure. Specifically Kerberos:

Never sends passwords or credentials across the network. It assumes that network traffic can be sniffed, messages injected and all manner of nefarious behaviors can occur.
It mandates that password/credential information is stored only in a single secure location (the Kerberos Key Distribution Center). The corollary is that credentials are never stored on the host that the user uses to sign-on/login. Once the initial Authentication exchange takes place the password must be discarded by that host.
Application hosts/servers must be able to prove their identity to anyone requesting such proof.
All communication between authenticated users (clients) and application services must be capable of being encrypted. Various bulk cipher algorithms (all symmetric) are supported and may be negotiated.

Kerberos Terminology

Like all serious systems Kerberos has both its own unique terminology and uses some other terminology in a specific way. The plain-speaking guide to all this stuff:

Realm

Realm simply means the set of users and application servers that the Key Distribution Center (KDC) covers - or has information about. Thus, for a user to join, or login, to a Realm the Authentication Server for that Realm must have knowledge of the users credentials (and other information) which are maintained in some form of secure database (not defined within the RFCs). In MS terminology this would be called a Domain. Realms may trust other Realms (in this case the peer Realms will have Cross-Authenticated).

The Realm name form is ...@REALM (case sensitive). For example, a Realm could be called JOE in which case its Realm name is @JOE (which is not the same as the Realm @joe) or it could be EXAMPLE.COM in which case its Realm name would be @EXAMPLE.COM. (Note: The current recommendation (RFC 4120 Section 6.1) is that REALMs using a domain name format - increasingly common - are converted to Upper Case.) While this latter form may look like an email name it has absolutely no relationship to email. Think REALM, not email.

Principal

A Principal is the string that fully identifies a user of the Kerberos service and has the form thing@REALM. The Principal can be the name of a service (which runs on a host which we will call a Service-Principal or a user (which we will call a User-Principal) and forms an index to the information stored about the entity in the Kerberos security database (in the Key Distribution Center or KDC). The format of the Principal differs for users and services.

The User-Principal name is the rough equivalent of a username or an account name and has the format principal-name[/instance-name]@REALM (where /instance-name is optional). For example if the User-Principal name is alice and the Realm is joe then the full Principal would be alice@joe. The instance-name extension allows any user to have more than one principal, thus if alice were an administrator for the joe Realm her principal name would be alice/admin@joe where this instance would have different rights (and credentials).

When used to describe a Service-Principal the form becomes service-name/QDN@REALM, where QDN is the domain name of the host (without the trailing dot demanded by an FQDN) on which the service runs and service-name is an application specific string which identifies the service on the host. Certain service types uses the keyword host. Thus, a service-name of ftp running on a host with a name fileserver.example.com in the Realm @EXAMPLE.COM would have a Service-Principal name of ftp/fileserver.example.com@EXAMPLE.COM.

Ticket

A Ticket is a data structure whose content is known only to the issuer of the Ticket and any party or parties to which the ticket is relevant. Intermediate hosts, such as client, treat the tickets as lumps of bits and simply pass them on to the final destination. Tickets within Kerberos may be either Ticket Granting Tickets (TGT - essentially proof of successful authentication) or Service Tickets (ST - issued by a Ticket Granting Service(TGS)) enabling the user to access a desired Application Service.

Figure 1: Kerberos Usage Overview

The 10 cent tour of Kerberos goes like this:

The user performs a logon at a client host (1) involving presentation of a User-Principal and the required Service-Principal which is sent (7) to the Authentication Server (AS) (2) of the Kerberos Key Distribution Center (KDC) (5).
Assuming the Service-Principal exists in the security database (6) the AS (2) sends (8) a Ticket Granting Ticket (TGT) which is treated as a lump of bits by the client and a unique session key encrypted with the credentials of the User-Principal.
On receipt of the message the client (1) asks for the users credentials and if it can decrypt the message (8) using these credentials they are assumed to be correct and the user is Authenticated.
When an Authenticated user wishes to access a service the client (1) sends a message (9) to the Ticket Granting Service (TGS) (3) of the KDC (5) containing the TGT (obtained in (8)) and the required Service-Principal name.
The TGS (3) responds (10) with a Service Ticket (ST), treated as a lump of bits by the client, authorizing use of the requested service.
The client (1) sends(11) the Service Ticket (ST) to the relevant Application Server (4)
The Application Server(4) uses the Service Ticket (ST) to verify that the requester has been authorized to use this service. It responds (12) only if the client (1) requests Mutual Authentication otherwise message (11) is assumed to have completed the process and service usage may commence.

Kerberos encodes all messages using Abstract Syntax Notation - 1 (ASN.1) using Distinguished Encoding Rules (DER) defined by ITU X.690.

Kerberos - Logon

This section defines the various dialogs in a bit more - but not exhaustive - detail. The gruesome minutiae of message formats is contained in RFC 4120 and the appropriate section references are included for each message type. The numbers in the following descriptions relate to Figure 2 below:

The client (1) sends an KRB_AS_REQ (7) (a.k.a Initial Authentication Request) to an Authentication Server (AS) (2) which is logically part of the KDC (5). This message is sent in the clear (it is not encrypted in any way). The message contains the User-Principal name, the name of the Service-Principal it wishes to connect to (normally the Ticket Granting Service (TGS) called krbtgt/REALM@REALM), an optional list of IP addresses the user wants to use and an optional lifetime for the login duration together with a nonce (a random message number) used both to identify responses and to mitigate replay attacks.
The KRB_AS_REQ message is defined in RFC 4120 Sections 3.1.2 and 5.4.1.
On receipt of this message the AS (2) verifies that both the User-Principal and the Service-Principal exist in the security database (6) and issues a failure message if they are not found. Note: The security database format is left as a implementation issue by the Kerberos RFCs but in the Windows world it is Active Directory (an LDAP based structure).
The AS (2) responds with a single KRB_AS_REP message (8) that consists of:
1. A randomly generated session key, the key's lifetime, a timestamp and a copy of the nonce (the random message number) sent by the client(1). This information is encrypted using the credentials of the User-Principal.
2. A Ticket Granting Ticket (TGT) encrypted using the key of the service requested by the client (typically the Ticket Granting Service). The TGT is, as far as the client is concerned, a lump of bits which it simply passes to the TGS (3) when it requests access to a specific Application Service (4). The client cannot interpret the contents of the TGT since it does not have, and does not need, a key by which it can decrypt it.
3. The KRB_AS_REP message is defined in RFC 4120 Sections 3.1.3 and 5.4.2.
On receipt of this message(8) the client (1) can now ask for the users credentials and using these as the key if it can successfully decrypt and verify the nonce they must be correct. The credentials can now be immediately discarded. While systems may request the credentials at the same time they offer any login prompt they are not required to do so since the Kerberos protocol allows credential request to be postponed until this step to minimize exposure in what may be an unsecure host system or PC.
Assuming the credentials were correct the user is now Authenticated by the KDC and has a TGT (a lump of bits) and a session key so can now proceed to request network services from the appropriate Application Server (4) which is described next.

Figure 2: Kerberos Operation

Note: While the dialog color coding above indicates a single encryption key this is an oversimplification (see detailed message descriptions in the RFCs for more precise detail). The color coding and the associated legend signifies the key used by the receiver of the message to decrypt and verify the data. Some parts of every message will be in cleartext and other parts will use different keys which, in all cases, are not known to the receiver. The receiver treats these parts of the message as lumps of bits.

Kerberos - Application Service Requests

The numbers in the following descriptions relate to Figure 2 above:

When the user wishes to use a network service it must first obtain a Service Ticket from the TGS (3) of the KDC (5). The client (1) constructs a KRB_TGS_REQ message (9) to the Ticket Granting Service (TGS) (3) to obtain a Service Ticket (ST) for the target Application Service. The KRB_TGS_REQ message has the following contents:
1. The User-Principal, the required Service-Principal, the required service lifetime and sundry other fields. This data is unencrypted and used by the TGS (3) to obtain the relevant keys for other parts of the message from the security database (6).
2. The TGT (lump of bits) that was obtained during the logon sequence. This is already encrypted using a key unknown to the client but which the TGS (3) can obtain from the security database (6) using the User-Principal.
3. An Authenticator structure which essentially comprises: The Client-Principal, , a nonce (a random message number) and other data. The Authenticator is encrypted with the session key obtained from the logon sequence. Optionally within the Authenticator the client can offer a sub-key (essentially a replacement session key) which, if present, must be used by the TGS (3) to encrypt the response.
4. This KRB_TGS_REQ message (9) is sent to the Ticket Granting Service (TGS) (3) of the KDC (5) and is defined in RFC 4120 Sections 3.2.2 and 5.4.1.
The TGS (3) responds with a KRB_TGS_REP message (10) consisting of:
1. A randomly generated Application-Service session key (that will be used to encrypt subsequent messages between the client(1) and the Application Service (4)) , the key's lifetime, a timestamp, the Service-Principal that was requested and a copy of the nonce (the random message number) sent by the client(1). This information is encrypted using either the session key obtained during the Authentication sequence or the sub-key (replacement session key) offered by the client in the KRB_TGS_REQ message.
2. A Service Ticket (ST) encrypted using the key of the Application Server hosting the service requested by the client and which contains a bunch of information useful to the Application-Service. The ST is, as far as the client is concerned, a lump of bits which it passes on to Applications Server when it requests access. The client cannot interpret the contents of the ST since it does not have, and does not need, any keys by which it can decrypt it. The ST importantly contains a copy of the TGS generated Application-Service session key sent to the client in (a) above. Note: Application Servers also Authenticate to the KDC (5) using a process similar to that described for the user above.
3. The KRB_TGS_REP message is defined in RFC 4120 Sections 3.2.4 and 5.4.2.
The client (1) unwraps its part of the structure using either the session key or its offered sub-key and extracts and compares the nonce. It also extracts the new Application-Service session key.
The client(1) finally sends a KRB_AP_REQ message (11) to the Application Server (4) to request access. This message consists of:
1. The user's Authenticator structure as defined for the KRB_TGS_REQ message above. This Authenticator is encrypted with the Application-Service session key obtained from the previous KRB_TGS_REP message (10).
2. The Service Ticket obtained with the previous response (10).
3. The client may request (using a flag field in the message) that it requires mutual authentication. In this case the Application Server (4) will respond with a KRB_AP_REP message containing the requested information. If mutual authentication is not requested then the service is is assumed to be immediately available and in some implementations application specific data may be sent within the same message.
4. The KRB_AP_REQ message is defined in RFC 4120 Sections 3.3.1 and 5.5.1.
The Application Server (4) responds (12) with a KRB_AP_REP message only if mutual authentication was requested otherwise it assumes the service is available and awaits the arrival of client data.
The KRB_AP_REP message is defined in RFC 4120 Sections 3.3.3 and 5.5.2.

Notes:

Tickets (both TGTs and STs) may optionally carry Authorization data (RFC 4120 Section 5.2.6). The precise content of the fields are deemed to be application specific. Microsoft uses these Authorization data fields to carry Privilege Attribute Certificates (PACs).

Kerberos - Useful RFCs

An incomplete list of Kerberos related RFCs. You can get the RFCs from the IETF.

RFC	Description/Status
RFC 4120	The Kerberos Network Authentication Service (V5). C. Neuman, T. Yu, S. Hartman, K. Raeburn. July 2005. (Format: TXT=340314 bytes) (Obsoletes RFC1510) (Updated by RFC4537, RFC5021, RFC5896, RFC6111, RFC6112, RFC6113) (Status: PROPOSED STANDARD)
RFC 4121	The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2. L. Zhu, K. Jaganathan, S. Hartman. July 2005. (Format: TXT=340314 bytes) (Updates RFC1964) (Updated by RFC6112) (Status: PROPOSED STANDARD)
RFC 6111	Additional Kerberos Naming Constraints. L. Zhu. April 2011. (Format: TXT=14113 bytes) (Updates RFC4120) (Status: PROPOSED STANDARD)
RFC 6112	Anonymity Support for Kerberos. L. Zhu, P. Leach, S. Hartman. April 2011. (Format: TXT=37858 bytes) (Updates RFC4120, RFC4121, RFC4556) (Status: PROPOSED STANDARD)
RFC 6113	A Generalized Framework for Kerberos Pre-Authentication. S. Hartman, L. Zhu. April 2011. (Format: TXT=121122 bytes) (Updates RFC4120) (Status: PROPOSED STANDARD)
RFC 6251	Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol. S. Josefsson. May 2011. (Format: TXT=17051 bytes) (Status: INFORMATIONAL)

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.