Start a Conversation

Unsolved

This post is more than 5 years old

2389

November 4th, 2014 05:00

The security protocol of CIFS: Kerberos

The security protocol of CIFS: Kerberos

Share: image001.png

Please click here for all contents shared by us.

Introduction

    As we know, NTLM and Kerberos are two major authentication methods for NAS and CIFS protocols. In this article we’ll talk about the basic concepts of the Kerberos protocol.


Detailed Information

    Kerberos is a protocol relies on “shared key” authentication technology. The concept is simple, if a secret is only known by two people,anyone can identify the other one by the shared secret. Technically, it is called symmetric encryption and mutual recognition.

    You may ask "NTLM is also the authentication protocol for CIFS, why Kerberos is more common? What’s the advantage of Kerberos?" I believe you would be clear after reading this article and understanding the basic concepts of Kerberos.

    The authentication process of Kerberos is very similar to the process we go to see the movies. It can be divided into three steps:

     The first step (Inquiry): Login to the domain

     The second step (Buy the ticket): Get the service ticket

     The third step (Visit): Use the service ticket to access the service

kerberos.png

·         Logging into the domain

1.       Authentication Server request

AS_REQ, step 1 in the diagram

In the first step, a user performs an interactive logon to a workstation by entering their username, password and the domain where their user account is located. The workstation performs a one-way hashing function on the user’s password and encrypts it with the client’s timestamp. This one-way hash of the user’s password is known as the user’slong-term key (LTK). This authentication request will be send to Kerberos Data Center (KDC), and ask for a Ticket Granting Ticket (TGT) returned by KDC.

2.       Authentication Server response

AS_REP, step 2 in the diagram

KDC searches the user’s password in the directory database, and uses the same hashing function to generate a new LTK. The server decrypts the data in the packet using the user’s long-term key and checks the timestamp. If the decryption is successful and the timestamp is within five minutes, the user is authenticated. KDC will generate a new TGT and send it back to the client.

In the meanwhile, KDC generates a random number as the Logon Session Key, and encrypt it with the LTK sent by the client, to generate a piece of information called “enc-part”. The enc-part will be placed at the KRB_AS_REP packet. The KDC will also encrypt the TGT and LTK to generate another “enc-part” and place it in the header of TGT. This TGT can be decrypted by KDC only. Finally KDC adds this TGT to KRB_AS_REP packet and sends it back to the client.

3.       Ticket cache

The client receives KRB_AS_REP then uses its own LTK to decrypt the “enc-part” in the packet. Here we’ll get the random number (Logon Session Key) chose by the KDC. The client will save the Logon Session Key and the TGT from KRB_AS_REP in the credential cache for next steps.

·         Getting a Service Ticket

1.       Ticket Granting Server (TGS) request

TGS_REQ, step 3 in the diagram

After the client gets the TGT, it will tell the KDC which service the client wants to access and ask for a service ticket. The service ticket can be used to access the service in the future. The client encrypts the current timestamp and the Logon Session Key saved in the credential cache to generate the authenticator, then send it with the original timestamp to KDC for authentication.

2.       Ticket Granting Server response

TGS_REP, step 4 in the diagram

After the KDC receives the KRB_TGS_REQ packet, it will use its own LTK to decrypt the TGT, to verify if the TGT is still valid by checking the original timestamp. Then KDC will read the Logon Session Key from the TGT and use it to decrypt the authenticator to get the second timestamp. If it is within five minutes, the user is authenticated, and KDC will generate a new service ticket.

Next the KDC will generate a new random number called Service Session Key, and decrypt the number with the Logon Session Key from the service ticket, to generate the “enc-part” and put it into the KRB_TGS_REP packet. The KDC will also encrypt the service ticket and LTK to generate another “enc-part” and place it in the header of TGS. This service ticket can be decrypted by KDC only. Finally KDC adds this service ticket to KRB_AS_REP packet and sends it back to the client.

3.       Ticket Cache

After the client receives the KRB_TGS_REP, it decrypts the Logon Session Key in the credential cache and gets the Service Session Key. Finally the client saves the Service Session Key and service ticket in the credential cache as the credential to the target server.

·         Using the Service Ticket

1.       Application Server request

AP_REQ, step 5 in the diagram

After the above two steps, the client now can access the service with the service ticket. The client saves the timestamp, reads the Service Session Key in the memory and encrypts it to generate a new authenticator. At the meanwhile, the client should also determine if the mutual authentication is required. Finally the client sends all this information with the service ticket to the server (In this case, the service is CIFS so the server is the CIFS server).

2.       Application Server response

AP_REP, step 6 in the diagram

After the NAS server receives the encrypted KBR_AP_REQ, it will uses its own LTK to decrypt it. Then the server reads the service session key from the service ticket to decrypt the timestamp in the authenticator. If it is within five minutes, the NAS server will allow the client to access the server and create a security token for the user.

Kerberos Benefits:

Although Kerberos is a bit more complex, but we can still find out its efficiency, and the advantages of the mutual authentication and interoperability.

                    I.            High efficiency: The client does not have to perform a DC authentication. It can finish the task by client credentials.

                  II.            Mutual authentication: The client and server can validate each other.

                III.            Interoperability: Microsoft's Kerberos V5 protocol is based on IETF standards and regulations.

Some useful links:

Kerberos Explained - TechNet

Kerberos Authentication Technical Reference - TechNet

Kerberos (protocol) - Wikipedia

Author: Roger


No Responses!
No Events found!

Top