In the Kerberos network authentication system, clients, the KDC, and application servers are the well-known three-headed architectural components. Which of the following best describes the operations of Kerberos? (Source: Wentz QOTD)
A. The KDC manages all the keys and is resistant to denial-of-service attacks.
B. Clients on the network interact with the KDC and servers asynchronously.
C. Realms must be organized hierarchically to support cross-realm authentication.
D. Initial ticket requests from clients are handled by the authentication service (AS).
Kindly be reminded that the suggested answer is for your reference only. It doesn’t matter whether you have the right or wrong answer. What really matters is your reasoning process and justifications.
My suggested answer is D. Initial ticket requests from clients are handled by the authentication service (AS).
DoS attacks are not solved with Kerberos
The Key Distribution Center for each realm is trusted by all principals registered in that realm to store a secret key in confidence. Proof of knowledge of this secret key is used to verify the authenticity of a principal.
“Denial of service” attacks are not solved with Kerberos. There are places in the protocols where an intruder can prevent an application from participating in the proper authentication steps. Detection and solution of such attacks (some of which can appear to be not-uncommon “normal” failure modes for the system) are usually best left to the human administrators and users. (RFC 4120)
The Clock Must be Loosely Synchronized
Each host on the network must have a clock that is loosely synchronized to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. The degree of “looseness” can be configured on a per-server basis, but it is typically on the order of 5 minutes. If the clocks are synchronized over the network, the clock synchronization protocol MUST itself be secured from network attackers. (RFC 4120)
Hierarchical Realms and Shortcut
Microsoft Active Directory is a good example of Kerberos implementation. AD Domains (Kerberos Realms) are organized hierarchically, but non-hierarchical shortcuts between domains can be established as well.
KDC and Tickets
Key Distribution Center. A network service that supplies tickets and temporary session keys; or an instance of that service or the host on which it runs. The KDC services both initial ticket and ticket-granting ticket requests. The initial ticket portion is sometimes referred to as the Authentication Server (or service). The ticket-granting ticket portion is sometimes referred to as the ticket-granting server (or service). (RFC 4120)
Authentication ticket, ticket
- A record of authentication issued by a Kerberos authentication server to a client system as proof of that client’s user being authentic.
- A service which is only provided to users who have authenticated themselves via Kerberos and whose clients can present valid authentication tickets as proof of authentication.
- The authenticated service for which a client is requesting a ticket or to which the client is presenting a ticket.
Initial ticketing service
- The service (provided by the Kerberos KDC) by which clients receive their initial (ticket-granting) tickets.
- The service (provided by the Kerberos KDC) by which clients receive tickets to specific target services (service tickets).
- A ticket provided on demand by the initial ticketing service which must be presented to the ticket-granting service in order to request a service ticket.
- An initial ticket is a ticket that is issued directly, not based on a ticket-granting ticket. Some services, such as applications that change passwords, can require tickets to be marked initial in order to assure themselves that the client can demonstrate a knowledge of its secret key. An initial ticket indicates that the client has recently authenticated itself, instead of relying on a ticket-granting ticket, which might have been around for a long time.
AS and TGS
The Kerberos protocol consists of several sub-protocols (or exchanges). There are two basic methods by which a client can ask a Kerberos server for credentials.
- In the first approach, the client sends a cleartext request for a ticket for the desired server to the AS. The reply is sent encrypted in the client’s secret key. Usually this request is for a ticket-granting ticket (TGT), which can later be used with the ticket-granting server (TGS).
- In the second method, the client sends a request to the TGS. The client uses the TGT to authenticate itself to the TGS in the same manner as if it were contacting any other application server that requires Kerberos authentication. The reply is encrypted in the session key from the TGT.
Though the protocol specification describes the AS and the TGS as separate servers, in practice they are implemented as different protocol entry points within a single Kerberos server.
Once obtained, credentials may be used:
- to verify the identity of the principals in a transaction,
- to ensure the integrity of messages exchanged between them, or
- to preserve privacy of the messages.
The application is free to choose whatever protection may be necessary.
Authentication servers maintain a database of principals (i.e., users and servers) and their secret keys. The security of the authentication server machines is critical. The breach of security of an authentication server will compromise the security of all servers that rely upon the compromised KDC, and will compromise the authentication of any principals registered in the realm of the compromised KDC.
Replay and Mutual Authentication
To verify the identities of the principals in a transaction, the client transmits the ticket to the application server. Because the ticket is sent “in the clear” (parts of it are encrypted, but this encryption doesn’t thwart replay) and might be intercepted and reused by an attacker, additional information is sent to prove that the message originated with the principal to whom the ticket was issued.
- This information (called the authenticator) is encrypted in the session key and includes a timestamp. The timestamp proves that the message was recently generated and is not a replay.
- Encrypting the authenticator in the session key proves that it was generated by a party possessing the session key. Since no one except the requesting principal and the server know the session key (it is never sent over the network in the clear), this guarantees the identity of the client.
As an authentication service, Kerberos provides a means of verifying the identity of principals on a network. By itself, Kerberos does not provide authorization. Applications should not accept the issuance of a service ticket by the Kerberos server as granting authority to use the service, since such applications may become vulnerable to the bypass of this authorization check in an environment where they inter-operate with other KDCs or where other options for application authentication are provided.
- RFC 4210, The Kerberos Network Authentication Service (V5)
- Introduction to Kerberos Authentication
- Types of Tickets
- Viewing Kerberos Tickets
- Kerberos Authentication Model: Definitions and Notational Conventions
A BLUEPRINT FOR YOUR SUCCESS IN CISSP
My new book, The Effective CISSP: Security and Risk Management, helps CISSP aspirants build a solid conceptual security model. It is not only a tutorial for information security but also a study guide for the CISSP exam and informative reference for security professionals.
- It is available on Amazon.
- Readers from countries or regions not supported by Amazon can get your copy from the author’s web site.