A client sent a Kerberos authentication request to the authentication server (AS) and received a response with an encrypted part containing the session key and ticket-granting ticket (TGT). Which of the following should the client use to decrypt the ciphertext?
A. The client’s secret key
B. The client’s private key
C. The authentication server’s public key
D. The session key shared by the client and the ticket-granting server (TGS)
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 client’s secret key.
Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication. Kerberos uses UDP port 88 by default. (Wikipedia)
- This question doesn’t mention anything about public-key cryptography, so option B and C can be ruled out.
- Option D is not possible because the session key is encrypted and needs another key to decrypt it.
The Authentication Service (AS) Exchange
The Authentication Service (AS) Exchange between the client and the Kerberos Authentication Server is initiated by a client when it wishes to obtain authentication credentials for a given server but currently holds no credentials. 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.
This exchange is also used to request credentials for services that must not be mediated through the Ticket-Granting Service, but rather require knowledge of a principal’s secret key, such as the password-changing service (the password-changing service denies requests unless the requester can demonstrate knowledge of the user’s old password; requiring this knowledge prevents unauthorized password changes by someone walking up to an unattended session).
This exchange does not by itself provide any assurance of the identity of the user. To authenticate a user logging on to a local system, the credentials obtained in the AS exchange may first be used in a TGS exchange to obtain credentials for a local server; those credentials must then be verified by a local server through successful completion of the Client/Server exchange.
The AS exchange consists of two messages: KRB_AS_REQ from the client to Kerberos, and KRB_AS_REP or KRB_ERROR in reply.
In the request, the client sends (in cleartext) its own identity and the identity of the server for which it is requesting credentials, other information about the credentials it is requesting, and a randomly generated nonce, which can be used to detect replays and to associate replies with the matching requests. This nonce MUST be generated randomly by the client and remembered for checking against the nonce in the expected reply.
The response, KRB_AS_REP, contains a ticket for the client to present to the server, and a session key that will be shared by the client and the server. The session key and additional information are encrypted in the client’s secret key. The encrypted part of the KRB_AS_REP message also contains the nonce that MUST be matched with the nonce from the KRB_AS_REQ message.
Without pre-authentication, the authentication server does not know whether the client is actually the principal named in the request. It simply sends a reply without knowing or caring whether they are the same. This is acceptable because nobody but the principal whose identity was given in the request will be able to use the reply. Its critical information is encrypted in that principal’s key. However, an attacker can send a KRB_AS_REQ message to get known plaintext in order to attack the principal’s key. Especially if the key is based on a password, this may create a security exposure. So the initial request supports an optional field that can be used to pass additional information that might be needed for the initial exchange. This field SHOULD be used for pre-authentication.
- Logging on to windows using Kerberos
- Kerberos and Windows Security Series
- Kerberos Wireshark Captures: A Windows Login Example
- Kerberos and Windows Security: Kerberos v5 Protocol
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 an 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.
客戶端向身份驗證服務器（AS）發送Kerberos身份驗證請求，收到的回應包含已加密的會話密鑰(session key)和票證授予票證(TGT)。 客戶端應使用以下哪個來解密密文？
A. 客戶端的秘密金鑰 (secret key)
B. 客戶端的私鑰 (private key)
C. 認證服務器(AS)的公鑰 (public key)
D. 客戶端和票證授予服務器(TGS)共享的會話密鑰 (session key)