Kerberos, or Cerberus, is a three-headed dog in Roman mythology that guards the gates of the underworld, preventing inhabitants there from escaping. The Kerberos protocol prevents the bad guys from getting in. There are three components to Kerberos: the client, a service and a third-party that both client and service trust.

The Shared Secret
A key feature is the shared secret and a password that doesn’t travel on the network. Thus the service (on the server) and the client (workstation) both know the password. The following scenario describes how this works:

  1. An account is created on the domain controller, or DC (the Kerberos Key Distribution Center or KDC) and given a password.
  2. The Kerberos client adds a text string (SALT) to the unencrypted password, along with a Kerberos version number (kvno), and runs those things through the “string2Key” conversion application. The “shared secret” is created. The SALT string is the username. That means  password_key = string2key(username + userpassword)
  3. At the workstation, the user enters the account name and password and requests certain services. The Kerberos client generates the secret key on the client. Because Kerberos uses the same algorithm to generate this secret key as was used on the KDC, the two secret keys will match as long as the username and password entered are the same.
  4. The user and the Authentication Service (AS) running on the KDC communicate using the shared secret.

Serve side components. On server side, there is two components, Key Distribution Centner (KDC) and Application Server. Key Distribution Center is further consist of 3 entities:

  1. Authentication Server:
  2. Ticket Granting Server (TGS):
  3. Database.

On server side, Ticket Granting Server and Application Server will have their own secret/key. The key idea of Kerberos protocol is that in each step, the server side ticket is generated and encrypted into two messages (A and B), one using the common key known by both the client and the server, and the other use the key only know by server. After receive the ticket, client need forward B in next server authentication step, so that server in next step can validate it the user is a valid one.

Here is the authentication/authorization step describe in Wikipedia:

User Client-based Logon

  1. A user enters a username and password on the client machines. Other credential mechanisms like pkinit (RFC4556) allow for the use of public keys in place of a password.
  2. The client transforms the password into the key of a symmetric cipher. This either uses the built in key scheduling or a one-way hash depending on the cipher-suite used.

Client Authentication[edit]

  1. The client sends a cleartext message of the user ID to the AS (Authentication Server) requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The AS generates the secret key by hashing the password of the user found at the database (e.g., Active Directory in Windows Server).
  2. The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:
    • Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
    • Message B: Ticket-Granting-Ticket (TGT,which includes the client ID, client network address, ticket validity period, and theclient/TGS session key) encrypted using the secret key of the TGS.
  3. Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client’s secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain theClient/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS’s secret key.) At this point, the client has enough information to authenticate itself to the TGS.

Client Service Authorization[edit]

  1. When requesting services, the client sends the following messages to the TGS:
    • Message C: Composed of the TGT from message B and the ID of the requested service.
    • Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.
  2. Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the “client/TGS session key”. Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client:
    • Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service’s secret key.
    • Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Client Service Request[edit]

  1. Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages:
    • Message E from the previous step (the client-to-server ticket, encrypted using service’s secret key).
    • Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.
  2. The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:
    • Message H: the timestamp found in client’s Authenticator (plus 1 in version 4, but not necessary in version 5[2][3]), encrypted using the Client/Server Session Key.
  3. The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correct. If so, then the client can trust the server and can start issuing service requests to the server.
  4. The server provides the requested services to the client.





Cassandra Study Notes

  1. Cassandra does not have a central coordinator, .e.g., namenode in hdfs or hmaster in hbase. It does not have single point failure (SPF)
  2. Every data row needs have a primary key. Primary key is hashed using MD5
  3. Cassandra use consistent hashing for keys distribution
  4. Cassandra data storage model is different from hdfs
  5. Cassandra enterprise version (product of DataStax) have developed a hdfs compatible filesystem, Cassandra file system (CFS), which can support hadoop M/R, hive, etc.
  6. The idea is to use dedicate Cassandra table column family to store file meta data (file name, path). And use another one to store file block data. By doing this, it removes the need for name node and data node. Basically, it re-implement hdfs api.
  7. A data node in Cassandra serves both as data node as well as coordinator. A client cannot connect to any number of data node for reading data. If the data does not exist in current collected node, it will compute the sharding and forward the request to the correct destination node. This is different as Hbase, where client directly know the destination region server through the sharding meta data saved in zookeeper.
Cassandra Study Notes