Understand Sigle Sign On with Kerberos

How It works?

To understand the workflow, we need to first define some terms thats gonna use in entire flow.

AS → Authentication Server / Kerberos Authentication Server. It authenticates the client and provide a TGT.
TGS → Ticket Granting Server. It use the TGT to provide service ticket for a requested service.
app1, app2, app3 → services
TGT → Ticket Granting Ticket. It is a ticket issued by the AS that the client can subsequently use with the TGS to request service tickets.
ServiceTicket → A ticket issued by the TGS for a particular application/service.
K → It represents the client's long-term secret key known to the KDC, normally it would be password in password based authentication.
K → It is a long-term key of the TGS principal, known to the KDC and TGS
K<tgs, app1> → Long term key between TGS and app1 service
K<c,tgs> → Session key creation from the Authentication server for communcation between client and TGS.
K<c,app1> → Session key creation form the TGS for communicaiton between app1 and client.

Step 1

The client requests authentication. The AS creates a session key for client and TGS → K<c,tgs>

Also AS creates a TGT. Conceptually TGT would look like below

{
  "client_identity": "client_abc",
  "client_tgs_session_key": "K<c,tgs>",
  "validity_inforamtion": "300"
//Additional fields
}

{
  "client_identity": "client_abc",
  "client_tgs_session_key": "K<c,tgs>",
  "validity_inforamtion": "300"
//Additional fields
}

Since this TGT is for TGS, only TGS should able to see this information even the client should not able to see the information. So AS encrypt this using the K<tgs> key. Since this key only TGS and AS knows.

finally AS creates this TGT.

Now AS has TGT and it needs to pass it to client so that client would communicate with TGS with that ticket. also the session key K<c,tgs> needs to be shared with client.

AS combine both K<c,tgs> encrypted using K<c> , TGT encrypted by K<tgs> send to client.

Step 2

Client first decrypt the message and get session key with TGS K<c,tgs>

It can't decrypt the TGT see what it contains since it was encrypted by K<tgs>

Client now can ask the TGS to access the service it required since it has TGT.

Client create a authenticator like below conceptually.

{
  "client_identity": "client_abc",
  "timestamp" : "1786547109",
  //Additional fields
}

{
  "client_identity": "client_abc",
  "timestamp" : "1786547109",
  //Additional fields
}

This authenticator encrypted by session key K<c,tgs> sends to TGS along with service request which contains the requested service and TGT.

Once the request is received to TGS. TGS first decrypts the TGT since it has the key K<tgs>

It validates the TGT and TGT contains the session key K<c,tgs> . Using that session key it will decrypt the Authenticator message from client.

It validates the freshness of message using the timestamp and identity in the authenticator.

The TGS validates the request and ticket constraints and, if the request is acceptable, issues a service ticket for the requested service which is app1.

TGS creates Service Ticket for client. This service ticket will be encrypted using the long term key TGS shares with the relevent serivce. If it is app1 then the K<app1> will be used to encrypt the service ticket.

{
  "client_id": "client_abc",
  "client_app1_session_key": "K<c,app1>",
  "validity_period": 300
  //other fields
}

{
  "client_id": "client_abc",
  "client_app1_session_key": "K<c,app1>",
  "validity_period": 300
  //other fields
}

Step 3

Once the client receives the response from TGS, it decrypts the message using K<c,tgs>.

The message would contain the service ticket, and the session key for the App1 and client.

Client first create authenticator for the app1 conceptually as follow

{
  "client_identity": "client_abc",
  "timestamp": "1786547109",
  //Additional fields
}

{
  "client_identity": "client_abc",
  "timestamp": "1786547109",
  //Additional fields
}

then this authenticator encrypted by the session key shared by the TGS which is K<c,app1> .

Client requests app1 service to authenticate him with this encrypted authenticator and the service ticket which is provided by TGS.

Client → Hey App1 Here is the ticket the TGS gave me, and here is proof that I am the client who owns the corresponding session key

App1 first, decrypt the service ticket and verfies that was created by TGS.

App1 identifies the K<c,app1> session key from the service ticket.

Using the K<c,app1> key, App1 decrypts the authenticator message and ensure the request comes from the client.

So finally the Client and App1 now share K<c,app1>, which can be used by Kerberos/application security mechanisms to provide authentication, integrity, and/or confidentiality for subsequent communication, depending on how the application protocol uses Kerberos.

Now We understood how Kerberos work. Lets understand the each key purpose.

Why are timestamps Used in Authenticator?

Timestamps provide freshness and help prevent replay attacks.

The receiving party checks whether the timestamp is sufficiently recent.

An attacker who records an old authentication message cannot simply replay it later if it is outside the allowed validity window.

Timestamp → Prevent Replay

What If Attacker Sniffs Kerberos Traffic?

An attacker can sniff Kerberos traffic, but simply capturing the traffic is generally insufficient to impersonate the client. Kerberos protects sensitive protocol contents with long-term K, K, K and session keys K<c,tgs>, K<c,app1> and the Authenticator demonstrates possession of the session key and includes freshness information to help prevent replay.

Attacker sees cipher text but does not know the keys required to decrypt the informaiton.

Why Kerberos convenient for Users?

It provides single-sign-on.

The user authenticates once and can subsequently access multiple kerberos enabled services using tickets without repeatly entering the password.