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.

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.

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.

Active Directory Terms and Abbreviations

This section briefly defines the terms and abbreviations used in conjunction with Microsoft Active Directory.

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

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

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.