Kerberos for dummies ! Kerberos authentication process

Steps involved in Kerberos authentication

A simple description of the Kerberos authentication process using the example of a user trying to access a database server.

1. Emily types in his/her username and password, the Kerberos software at the user end sends the user name to the Authentication service of the KDC, the AS on the KDC verifies if the user name exists in the KDC database,
2. if it does, it creates a TGT (ticket granting ticket) which has the secret key(password)  of the user encrypted.
3. If the password which Emily typed in earlier (temporarily stored on user machines) is the same as the encrypted secret key, Emily is allowed access to the machine.
4. Once this is done,  now say Emily needs access to the database server, in order to get this, Emily will send her TGT which was granted by the authentication service to the TGS(ticket granting service)
5. The TGS in return creates a second ticket which has 2 session keys which are the same, the first session key is encrypted with the Emileys shared secret key (user-kdc-key), and the second session key is encrypted with the database shared secret key (db-kdc-key), in addition to this the kdc adds the authenticator information of the requesting user in the second session key.
6. Once Emily receives this new ticket, Emily will be able to decrypt the first part which was encrypted by the user-kdc- key to get to the session key, once decrypted Emily will add an authenticator (sequence number, ip address, etc) to that session and will re-encrypt using  the extracted session key, this updated ticket will then be sent by Emily to the database server.
7. The DB server will receive the updated ticket and will be able to decrypt the part which was encrypted by the db-kdc-key, once decrypted db server will have a session key and a authenticator, DB server will use the extracted session key to decrypt the first part of the ticket which was encrypted by Emily with the extracted session key.
8. Once decrypted, Db server will be able to match the authenticator information extracted from the first session key with the authentication information extracted from the second session key.

This process proves to the db server that emily is a authenticated user who is trusted by the kdc due to the fact that she had encrypted the first part of the ticket with the session key which was orignally created by the kdc.

Components of the KDC

KDC is primarily used to provide authentication services, it is useful in an environment where users / services do not trust each other, a mechanism is needed which would vouch for a user to another user that the user requesting access is indeed  trusted / authenticated  user , basically this is the service which KDC provides, authenticating  users as well as  vouching for authenticated  users .

KDC components:

1. KDC is the core service within the KDC architecture, it holds the secret keys of all user principles and service principles, and uses the secret keys to encrypt messages.
2. Authentication service, when a user request access, the service request goes to the authentication service, authentication service verifies if there is a username exist in the database, if it does, it creates a TGT which is encrypted by the secret key (password) of that user.
3. TGT:  Is a ticket granting ticket which is issued by the authentication service, this is the enabler for single sign on capability of Kerberos, once the user has a TGT, a user is not required to insert passwords for every service they require access on.
4. TGS: ticket granting service is responsible for creating tickets which have 2 sessions with the same key, these session keys allows users to communicate with each other.

5. User principle: user principles is the user device which is requesting access, user principle interact with AS, TGS and target device.
6. Service Principle: is the target service which the user principle needs access to, it could also be vice versa, the service principle verifies if the user principle has been authenticated by the KDC.
7. The session ticket contains 2 copies of the session key, one copy is encrypted with the user-kdc secret key, the other is encrypted with the service-kdc-secret key.

Time stamp and sequence numbers, are primarily used to stop reply attacks and false impersonation, the service principle compares the  ticket time stamp against its own internal time stamp to verify it has not been sniffed by a hacker wanting to impersonate a user principle at a later time, likewise sequence number is verified by the service principle if it has not received the same sequence number before.

Difference between the secret key and session key.

A secret key is shared between the principle and the kdc, it is static in nature.

Where as a session key is generated dynamically and its shared between 2 principles, it is created on a need basis and destroyed when not required.

Weakness in Kerberos:

1. Single point of failure, If the KDC goes down which holds all the secret keys for all user and service principles, no aunthentication can take place.
2. Dependent on clock synchronization between client and server.
3. Open to password guessing, Kerberos does not know if the password brut force attack is taking place in the background, a separate mechanism must be in place to protect this (windows has password login attempts which prevent this)

SESAME

Secure European system for application in a multi vendor environment

Sesame is based on symmetric asymmetric cryptography, Unlike KDC which holds all the secret keys of all principles, it uses Privilege attribute server to digitally sign PAC (privilege attribute certificates) using asymmetric cryptography , these PACS can be decrypted by the public key of the PAS which makes sesame far more scalable.