All notes






  1. User Client-based Logon
    1. A user enters a username and password on the client machines.
    2. The client transforms the password into the key of a symmetric cipher.
  2. Client Authentication
    1. The client sends a cleartext message of the user ID to the AS (Authentication Server) on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS. The AS generates the secret key itself by hashing the password of the user from database.)
    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 the client/TGS session key), encrypted using the secret key of the TGS.
    3. The client attempts to decrypt message A with the secret key generated from the password entered by the user, to obtain the Client/TGS Session Key.
  3. Client Service Authorization
    1. The client sends the following two 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. 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.
  4. Client Service Request
    1. 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.




Message-Digest Algorithm 5, short for MD5, is a cryptographic hash function producing 128-bit/16-byte hash value. Usually the 16-byte value is represented by 32-byte hexical string (signed char), in case that some char value in 16-byte is inpritable or causes printing cease (such as '\0').

for (i=0; i<16; i++)
	printf("%02x", md5Str);

Zedwood website provides a CPP implementation.

RFC 2307

RFC 2307 suggests user passwords be hashed using a one-way cryptographically safe algorithm, which is referred to as being encrypted (it's a misnomer since they are not designed to be decrypted). Reference.

RFC 2307 includes schemes: {CRYPT}, {SSHA}, {SHA}, {SMD5}, {MD5}, etc. {SSHA} is the seeded {SHA}, and is mostly recommended for general use. {CRYPT} passwords are supported for migration purposes only. {MD5} is known to be weak. Reference1 and Reference 2.