adam's notes

Kerberos

Kerberos is a single sign-on authentication and authorization service that is based on a time-sensitive ticket-granting system.

  • provides SSO authentication to Active Directory
    • compatible with other, non-Windows operating systems
  • allows a user account to authenticate to a domain controller (DC) over a trusted local cabled segment
  • named after the three-headed guard dog of Hades (Cerberus) because it consists of three parts:
    • Client
      • requests services
    • Server
      • from which the service is requested
    • Key Distribution Center (KDC)
      • component of Kerberos that authenticates users and issues tickets (tokens)
      • vouch for their identity

Key Distribution Center

  • two services that make up a KDC:

    • Authentication Service (AS)

      • responsible for authenticating user logon requests
      • users and services can be authenticated
        • collectively referred to as principals
        • e.g., when Windows domain workstation logs on to the domain, first step is to authenticate with a KDC server (implemented as a domain controller)

    • Ticket Granting Service (TGS)

      • when authenticated, KDC server presents the user with a Ticket Granting Ticket
        • to access resources within the domain
        • client requests a service ticket by supplying the Ticket Granting Ticket to the Ticket Granting Service
          • a token that grants access to a target application server

Process

SSO Authentication

  1. The principal sends the authentication service (AS) a request for a Ticket Granting Ticket (TGT)
    • is composed by encrypting the date and time on the local computer with the user’s password hash as the key

Info

The password hash itself is not transmitted over the network. Although we refer to passwords for simplicity, the system can use other authenticators, such as smart card login.

  1. The AS checks that
    • user account is present
    • it can decode the request by matching the user’s password hash with the one in the Active Directory database
    • and the request has not expired
    • If the request is valid, the AS responds with the following data:
      • Ticket Granting Ticket (TGT)
        • contains information about the client (name and IP address) plus a time stamp and validity period
        • is encrypted using the KDC’s secret key
      • TGS session key
        • communicates between the client and the Ticket Granting Service (TGS)
        • is encrypted using a hash of the user’s password
  • The TGT is an example of a logical token
    • All TGT does is identify who you are and confirm that you have been authenticated
      • does not provide you with access to any domain resources

SSO Authorization

  • Presuming
    • user enters password correctly
    • client can decrypt the TGS session key, but not the TGT
  • this establishes that
    • the client and KDC know the same shared secret
    • the client cannot interfere with the TGT

How it Works

  1. To access resources within the domain
    • principal requests a service ticket
      • token that grants access to a target application server
    • process of granting service tickets is handled by the TGS
  2. principal sends the TGS:
    • copy of its TGT
    • the name of the application server it wishes to access
    • an authenticator
      • consisting of a time-stamped client ID encrypted using the TGS session key
    • TGS decrypts both messages
      • using KDC’s secret key for the first
      • using TGS session key for the second
      • this confirms request is genuine
      • checks that the ticket is not expired and has not been used before
  3. TGS service responds with:
    • server session key
      • used between the client and the application server
      • is encrypted with the TGS session key
    • service ticket
      • contains information about the principal
        • such as a time stamp
        • system IP address
        • Security Identifier (SID)
        • the SIDs of groups to which it belongs
        • the service session key
      • encrypted using the application server’s secret key
  4. principal forwards the service ticket, which it cannot decrypt, to the application server
    • and adds another time-stamped authenticator
      • which is encrypted using the service session key
  5. application server decrypts the service ticket to obtain the service session key using its secret key
    • confirming that the principal has sent it an untampered message
    • then decrypts the authenticator using the service session key
  6. Optionally, the application server responds to the principal with the time stamp used in the authenticator
    • is encrypted by using the service session key
    • principal decrypts the time stamp and verifies that it matches the value already sent
      • concludes that the application server is trustworthy
    • This means that the server is authenticated to the principal
      • referred to as mutual authentication
      • prevents an on-path attack
  7. server now responds to access requests
    • assuming they conform to the server’s access control list

Drawbacks of Kerberos

  • the KDC represents a single point-of-failure for the network
    • backup KDC servers can be implemented
    • e.g.,
      • Active Directory supports multiple domain controllers
      • each of which are running the KDC service

Graph View

Backlinks