You are viewing the documentation for Blueriq 15. Documentation for other versions is available in our documentation directory.
Table of contents
Introduction
This document aims to briefly describe the concepts and terms used in conjunction with Kerberos authentication. This is by no means a guide to Kerberos, its sole aim is to establish a common language among stakeholders and to define the many abbreviations used throughout the Kerberos Support documentation.
If you want an introduction to the Kerberos protocol, the Wikipedia page and this tutorial are much better starting points. Also, a much more detailed sequence diagram can be found here.
Kerberos Interactions
The general use case where Kerberos authentication is involved is the following: a client wishes to interact with a service and they require mutual authentication. Mutual authentication means that not only the service needs to know who the client is, but the client also wants to know that it is indeed talking to the service it thinks it's talking to. In order to circumvent man-in-the-middle types of attacks, the Kerberos protocol uses a trusted third party. The trusted third party issues tickets encrypted with a symmetric-key algorithm (typically RC4 or AES) which are then used to perform mutual authentication. Each party involved in the Kerberos system has a secret key. This key is known only to the respective party and to the trusted third party.
# | Description |
1.0 | The client contacts the trusted 3rd party and requests a ticket for the service |
1.1 | The trusted 3rd party generates a random session key and a service ticket. The session key is going to be used to encrypt authentication messages between the client and the service and is encrypted with the client's secret key, so that the client may decrypt it. The service ticket contains among other things the client's identity and the session key (again), and it is encrypted with the service's secret key, so only the service may decrypt it. |
1.2 | The client decrypts the service session key using its own secret key. It then generates an authenticator containing among other things a timestamp, and encrypts it with the session key. It then contacts the service and sends the service ticket and the authenticator. |
1.3 | The service decrypts the service ticket using its own private key and obtains among other things the session key and client identity. After validating the client identity, it decrypts the authenticator with the session key and obtains the timestamp sent by the client. It then generates its own authenticator containing the timestamp sent by the client, encrypts it with the session key and sends it to the client. |
1.4 | Although not apparent in the diagram, upon receipt of the service authenticator, the client decrypts it with the session key and validates the timestamp sent by the service. In this way, the service proves to the client that it had access to the service's secret key, was able to decrypt the service ticket and obtain the session key, and was able to decrypt the authenticator sent by the client. In short, the service authenticates with the client. |
Note: the above steps are an over-simplification, there are many other pieces of information and validations involved that were omitted.
Kerberos Terms and Abbreviations
Before describing Kerberos in more detail, this section aims to define the many terms and abbreviations used.
Term | Abbreviation | Description |
Authenticator |
| A record containing information that can be shown to have been recently generated using the session key known only to the Client and the Service. |
Application Service | AP | See Service. Sometimes called Application Server. |
Authentication Service | AS | Maintains a database of principals (users, servers) and their secret keys. Sometimes called Authentication Server. Authenticates principals (eg. based on username+password) and issues Ticket Granting Tickets (TGT). |
Client |
| A process that makes use of a network service on behalf of a user. |
Credentials |
| A service ticket + a session key |
Encryption Type | etype | Identifies the encryption algorithm used to encrypt a piece of data. See encryption algorithms for a list of supported encryption algorithms and their etypes. |
Key Distribution Center | KDC | A network service which issues tickets and temporary session keys. It issues both Ticket Granting Tickets (TGT) and Service Tickets. The part of the service which issues TGTs is also called Authentication Service (AS). The part of the service which issues Service Tickets is also called Ticket Granting Service (TGS). So KDC = AS + TGS. |
Key Version Number | kvno | Identifies which secret key was used for encrypting a piece of data. Used during the transition from one long term secret key to another (for example when a user changes his password) |
Principal |
| A named client, server/service which participates in network communication with one name which is considered canonical (the principal identifier) |
Seal |
| To encipher a record containing several fields in such a way that the fields cannot be individually replaced without knowledge of the encryption key or leaving evidence of tampering. |
Secret Key |
| An encryption key shared by a principal and the KDC. May be derived from a password. |
Service |
| A particular Principal that provides a resource to network clients. The service is sometimes referred to as the Application Server (Note: what this document refers to as "Service" is called a "Server" in the in the RFC; we adopt the term Service to distinguish the process offering the service from the physical host on which it runs). |
Service Ticket |
| see Ticket. |
Session Key |
| A temporary encryption key generated by the KDC and used between two principals (typically a Client and a Service) |
Ticket |
| A record that helps a client authenticate itself to a service; it contains the client's identity, a session key, a timestamp, and other information, all sealed using the service's secret key. It only serves to authenticate a client when presented along with a fresh Authenticator. |
Ticket Granting Service | TGS | A network service which issues Service Tickets. In order to issue a Service Ticket to a client, the TGS requires that client authenticates using a Ticket Granting Ticket (TGT) |
Ticket Granting Ticket | TGT | A ticket issued by the AS to a client for authenticating with TGS. |
Active Directory Terms and Abbreviations
This section briefly defines the terms and abbreviations used in conjunction with Microsoft Active Directory.
Term | Abbreviation | Description |
Active Directory | AD | A directory service developed by Microsoft for Windows domains. Makes use of LDAP, Kerberos and DNS. |
Domain |
| A logical division of an AD. Objects in a domain are stored in a single database and are identified by their DNS name |
Domain Controller | DC | A server which responds to security authentication requests in a domain. |
Forest |
| A collection of one ore more domains and/or trees. |
Forest Root |
| The first domain created in a forest is called the forest root. |
Generic Security Service Application Program Interface | GSS-API | An IETF standard API for programs that wish to access security services |
Service Principal Name | SPN | A name by which a client uniquely identifies an instance of a service |
Simple and Protected GSSAPI Negotiation Mechanism | SPNego | A pseudo-mechanism used to negotiate a concrete authentication mechanism between a client and a service. |
Tree |
| A collection of domains organized in a tree structure and linked by two-way transitive trust. |
User Principal Name | UPN | An Internet-style login name for a user based on RFC 822. A UPN is unique across a forest. |
Kerberos Interactions in More Detail
This section describes in a bit more detail the actors involved in Kerberos authentication and the interactions between them, in the context of Microsoft AD. This section can be used when debugging during implementation or when inspecting logs from Service Desk issues in order to better understand what messages are exchanged and what the potential problems might be.
The trusted third party presented in Kerberos interactions is the KDC. The KDC is composed of two services, the AS and TGS. In order to use the Kerberos system, a client needs to authenticate with the AS and obtain a TGT. In the context of a Microsoft Active Directory, the KDC is the Domain Controller (DC). When a user logs in using his domain account, he is issued a TGT. The TGT can be displayed by running the following command: klist tgt
When the client needs to authenticate with another service on the network, it contacts the TGS, authenticates using the TGT and requests a ticket for that service. In an AD, the TGS uses the krbtgt/DOMAIN@DOMAIN SPN. All service tickets issued to the current user (including the TGT) can be displayed by running the following command: klist tickets
In an AD, the KDC accepts requests using UDP on port 88.
1.0 AS-REQ. The client contacts the AS in order to obtain a TGT. In a Windows environment withint an AD, this happens when the user logs in. This interaction can also be started by running the kinit tool distributed with the JDK. Contained within the request are the following items:
- req-body: this item contains the request body
- cname: the client name; this item in turn contains the following sub-items
- name-type: the type of the cname (eg. in case of a user this is KRB5-NT-PRINCIPAL)
- name-string: the name of the client (eg, the username)
- realm: the realm of the user (e.g. the AD domain name)
- sname: the service name for which a ticket is requested. this item contains similar sub-items as the cname, but with different values. The name-string usually contains krbtgt.
- etype: a list of encryption algorithms supported by the client
- cname: the client name; this item in turn contains the following sub-items
1.1 KRB-ERROR. The AS responds with an error message stating that pre-authentication is required. The message contains the following items:
- sname: same as in the AS-REQ
- e-data: contains information about how to pre-authenticate; this item is a collection of pa-data subitems:
- pa-enctype-info2 (19): this specifies a list of encryption algorithms and a salt for each one
- pa-enc-timestamp (2): this specifies that the client should encrypt a timestamp using its secret key to prove his identity
- other methods by which the client can prove his identity, in decreasing order of preference (e.g. pkinit)
1.2 AS-REQ. The client sends another AS-REQ message to the AS, this time containing the requested pre-authentication data:
- padata: a collection of authentication methods selected from the ones offered in the KRB-ERROR message at 1.1. Usually, this will be an encrypted timestamp (2).
- req-body: same request body as the original request at 1.0
1.3 AS-REP. Since the AS knows the client's secret key, it decrypts the timestamp sent by the client at 1.2 and thus validates his identity. It then generates a session key and a ticket for the TGS. The response contains the following items:
- padata: a collection of pa-enctype-info2 sub-items (usually just 1), which specify the encryption algorithm used to encrypt the session key (the strongest encryption algorithm supported by the client). If the encryption algorithms use an HMAC, then a salt is also sent in the pa-enctype-info2 item.
- ticket: the service ticket with the following sub-items
- sname: the name of the service for which the ticket was issued
- enc-part: the actual ticket, encrypted with the secret key of the service
- enc-part: the session key, encrypted with the algorithm specified in the padata item above
Note that the ticket (the ticket item) and session key (the enc-part item) may be encrypted with different algorithms. For example if the best algorithm supported by the client is AES128 and the best algorithm supported by the TGS (krbtgt) is AES256, then the ticket will be encrypted with AES256 and the session key with AES128.
1.4. HTTP POST. In this example, the service is a HTTP service, and the client sends an HTTP POST request
1.5. HTTP 401 Unauthorized. The service requires authentication, so it replies with status 401 Unauthorized and a WWW-Authenticate header. In an AD environment with Kerberos authentication, the WWW-Authenticate header has the value Negotiate, which means that the SPNEGO protocol should be used to negotiate another authentication protocol. Authentication protocols supported by SPNEGO may include Basic, Digest, NTLM and Kerberos. For our purposes, we are interested in authenticating with Kerberos.
1.6 TGS-REQ. The client wants to authenticate using Kerberos. In order to do this, it needs a service ticket for the Service (note that at 1.0 - 1.3 the obtained ticket is the TGT, which is used when communicating with the TGS). It contacts the TGS and requests a service ticket for Service. The message contains the following items:
- padata: in a series of nested items, this item contains the TGT and an Authenticator (encrypted with the session key received at 1.3).
- req-body: the request body, composed of the following sub-items
- sname: the name of the service for which a ticket is requested
- etype: a collection of encryption algorithms supported by the client
1.7 TGS-REP. The TGS decrypts the TGT to obtain the session key. Then it uses the session key to decrypt the Authenticator and authenticate the client. It then generates a new session key and service ticket for Service. The response contains the following items:
- cname: the name of the client which requested the ticket
- ticket: the service ticket for Service (has similar structure as the ticket at 1.3, but with sname = the name of Service, instead of the name of the TGS)
- enc-part: the encrypted session key (this is the session key shared by the Client and the Service)
1.8 HTTP POST. The Client resends the request at 1.4, this time with the header Authorization: Negotiate <base64-encoded data structure>. The data structure has the following items, which can be used to verify that authentication is done using Kerberos and not some other protocol (NTLM for instance):
- GSS-API
- OID: <oid> (SPNEGO): identifies that this is a SPNEGO structure
- Simple Protected Negotiation
- negTokenInit: the initial negotiation token
- mechTypes: lists the supported authentication mechanisms. This should contain a single item - Kerberos
- reqFlags: flags which indicate which Kerberos features are requested (e.g. delegation, mutual authentication, replay protection, integrity, etc.)
- krb5_blob: in a series of nested items, this contains the ticket obtained at 1.7 and an Authenticator
- negTokenInit: the initial negotiation token
1.9 HTTP 200 OK. The Service decrypts the ticket, validates it and obtains the session key. It the uses the session key to decrypt the authenticator and verify the client's identity. It then serves the resource requested by the client and returns it with a HTTP 200 OK response. The response also contains a WWW-Authenticate: <base64-encoded string> header. The value of this header is used by the Client to authenticate the Service. In an AD environment, the value of this header is non-standard and can't be interpreted by traffic monitoring tools such as Wireshark. The presence of this header and the absence of an exception on the Client is assumed to mean a successful authentication of the Service by the Client.