- User JOHNDOE enters his password on a client machine.
- The client performs a one-way hash function on the entered password, which becomes the secret key of JOHNDOE.
- The client sends a message (AS-REQ) to the AS portion of the KDC, requesting a TGT on behalf of user JOHNDOE. The message contains the following:
- (Cleartext) Client Principal Name : JOHNDOE
- (Cleartext) Realm : MYREALM1.COM
- (Cleartext) Server Principal name : krbtgt/MYREALM1.COM
- (Encrypted) PA-ENC-TIMESTAMP -> A time stamp encrypted with the secret key obtained from (2). The purpose of preauthentication is to force JOHNDOE to prove that he really is JOHNDOE (As he is the only one that knows the password) and to prevent a replay attack. Without preauthentication, the KDC will send the AS-REQ message to anyone claiming to be JOHNDOE. As a result, a offline brute force attack on JOHNDOE's password could be done. Preauthenication alleviates this.
- When receiving the AS-REQ message from the client, the AS will first check if client principal JOHNDOE is known in the KDC database. If not, the AS will return the error KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN in the AS-REP message. If JOHNDOE exists, the AS will collect his password in the KDC database and perform the same one-way hash function as in (2). This secret key will be used to decrypt the PA-ENC-TIMESTAMP from the AS-REQ. If it can be decrypted successfully, the AS will send an AS-REP message back to the client, containing the following:
- (Encrypted) (A) A session key for client/TGS communication, encrypted with the secret key of JOHNDOE.
- (Encrypted) (B) A TGT which includes the client ID (JOHNDOE), client network address, ticket validity period and the client/TGS session key. The TGT is encrypted using the secret key of the TGS.
- Once the client receives the AS-REP message, it will decrypt message A to obtain the client/TGS session key. This session key is used for further communication with the TGS. The client also caches the TGT, which it cannot decrypt as it encrypted with the secret key of the TGS.
- hen requesting service myservice/abc.realm1.com@REALM1.COM, the client sends the following TGS-REQ message to the TGS:
- (Cleartext) Server Principal name : myservice/abc.realm1.com@REALM1.COM
- (Encrypted) The cached TGT
- (Encrypted) An authenticator, which is composed of the client ID (JOHNDOE) and a timestamp, encrypted using the client/TGS session key.
- When receiving the TGS-REP message from the client, the TGS will decrypt the TGT using its secrey key and will extract the client/TGS session key from it. Subsequently, the TGS will decrypt the authenticator. If the decryption is successful, it proves JOHNDOE's identity to the TGS. The TGS will send a TGS-REP message to the client containing the following:
- (Encrypted) (C) A client/server ticket which includes the client ID (JOHNDOE), client network address, ticket validity period and the client/server session key. The client/server ticket is encrypted using the service's secret key.
- (Encrypted) (D) A client/server session key encrypted with the client/TGS session key.
zaterdag 2 oktober 2010
Kerberos : Authentication flow
When initially logging on to a network, users must negotiate access by providing a log-in name and password in order to be verified by the Authentication Server (AS) portion of a Key Distribution Center (KDC) within their domain. Once successfully authenticated, the user is granted a Ticket Granting Ticket (TGT) that is valid for the local domain. The TGT has a default lifetime of 10 hours and may be renewed throughout the user's session without requiring the user to re-enter his password. The TGT is cached on the local machine and is used to request sessions with services throughout the network. The following example explains the TGT/TGS retrieval process (assume user JOHNDOE belongs to Kerberos realm MYREALM1.COM):