In the Kerberos network authentication system, a client initiates authentication requests to the authentication service (AS) to obtain authentication credentials for a given server. Which of the following is not true? (Source: Wentz QOTD)
A. The AS is subject to the chosen-ciphertext attack.
B. The client sends its own identity to the AS in cleartext when logging in.
C. The AS doesn’t know whether the client sends a genuine identity or not.
D. The client doesn’t send its password or secret key to the AS when logging in.
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 A. The AS is subject to the chosen-ciphertext attack.
If a client doesn’t have any credentials to communicate with any given server (e.g., the Ticket-Granting Server (TGS) or other application servers), it authenticates to the Authentication Server (AS) following the protocol called the Authentication Service Exchange, or AS Exchange, as depicted in Step 1 and 2 in the above diagram.
The client sends an initial Kerberos Authentication Service Request (KRB_AS_REQ) to the AS. It sends the following data items in clear text:
- Its own identity
- The identity of the server for which it is requesting credentials
- Other information about the credentials it is requesting
- A nonce to detect replays and to match responses to its requests
In its basic form, the client’s secret key is used for encryption and decryption. This exchange is typically used at the initiation of a login session to obtain credentials for a Ticket-Granting Server, which will subsequently be used to obtain credentials for other servers without requiring further use of the client’s secret key.
The previous Kerberos 4 was vulnerable because the KDC responds to any client with an encrypted TGT for any principal registered in the Kerberos database. It can suffer from the chosen-plaintext attack because the attacker can select or choose a plaintext and send it to the KDC for encryption.
Kerberos Pre-Authentication is defined in RFC 6113 and an IANA Registry for Pre-authentication and Typed Data.
Kerberos Pre-Authentication is a security feature which offers protection against password-guessing attacks. The AS request identifies the client to the KDC in Plaintext.
- If Kerberos Pre-Authentication is enabled, a Timestamp will be encrypted using the user’s password hash as an encryption key. If the KDC reads a valid time when using the user’s password hash, which is available in the Microsoft Active Directory, to decrypt the Timestamp, the KDC knows that request isn’t a replay of a previous request.
- Without Kerberos Pre-Authentication a malicious attacker can directly send a dummy request for authentication. The KDC will return an encrypted TGT and the attacker can brute force it offline. Upon checking the KDC logs, nothing will be seen except a single request for a TGT. When Kerberos timestamp Kerberos Pre-Authentication is enforced, the attacker cannot directly ask the KDCs for the encrypted material to Brute-Force offline.
The original Kerberos 4 protocol was susceptible to offline dictionary and brute-force attacks, as we’ll see in Chapter 6. This vulnerability stems from the fact that the KDC issues an encrypted TGT to any client for any principal (given that the requested principal exists in the Kerberos database). Since the KDC happily provides a ticket encrypted with the principals’ secret key to any requestor, an offline attack can be mounted to determine the principal’s secret key. This vulnerability is exacerbated by the fact that users typically choose poor passwords.
To make this attack more difficult, Kerberos 5 introduces pre-authentication (see Figure 3-11). Pre-authentication requires that requestors prove their identity before the KDC will issue a ticket for a particular principal. There are several types of pre-authentication defined by the Kerberos Clarifications document. However, only the encrypted timestamp (PA-ENC-TIMESTAMP) pre-authentication method is commonly implemented.
Pre-authentication is controlled by KDC policy. If a user attempts to acquire initial tickets through the AS exchange, but the KDC requires pre-authentication, then the KDC will send a KRB_ERROR message instead of an AS_REP in reply to the client’s AS request. This KRB_ERROR message tells the client that pre-authentication is required.
- 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
- Kerberos: The Definitive Guide by Jason Garman
- Kerberos Authentication 101: Understanding the Essentials of the Kerberos Security Protocol
- How does Kerberos’ preauthentication increase security?
- Kerberos Pre-Authentication: Why It Should Not Be Disabled
- Kerberos Pre-Authentication
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.