Kerberos Flow Chart / Kerberos sessions keys / AS and TGS

1. Normal Flow
   
   
   
   
   
   
2. Forwarded Delegation
   
   
   
   
   
3. s4u Extension
   
   
   
   
   

A kerberos client is issued 2 type session keys:

1. Session key that is used for communication with TGS

2. Session key that is used for communication with service provider

The process of getting # 1 type session key is called "authentication". It's issued by Authentication Service (AS, for AD, AS resides on same machine as KDC). 

1. Client(machine) sends AS request(contains user ID in cleartext) on behalf of user to AS.
2. AS sends back session key type 1 back to client, encrypted with user's hash). AS also sends back TGT ( same session key plus other info such as session key valid duration) . TGT is not readable to client, it's encrypted with TGS' key (krbtgt hash)
3. Later on, user will use this session key to encrypt messages to TGS
4. AS (AD DC) never stores the session key. It's always the client to keep and present session key to TGS. This is achieved by sending TGT back to TGS (remember in step 2 above, TGT is encrypted with TGS' key so TGS can read the content and get the session key). In other words, session key becomes a timed common knowledge between TGS and client 

The process of getting #2 type session key can be roughly called "authorization" (actual access evaluation happens on resource provider, based on the Service Ticket presented). It's the process to get Service Ticket, which can be later presented to service provider. 

1. client sends a service request, one of the content of this request is its ID/time, encrypted with type #1 session key above. Along side the TGT (again this TGT is not readable to client, but it's readable to TGS/DC) 
2. TGS/DC decrypts TGT to get session key #1 so it can validate client ID /timestamp 
3. If matched, TGS sends back 2 things 
1. type #2 session key, encrypted with type #1 session key so client can read and use type #2 session key for communication with service provider
2. Service Ticket (not readable to client, but only for client to hold it and present to service provider). This is encrypted with service provider's key so only service provider can read it
3. In client's request, it specify a SPN for TGS to locate service provider's key
4. Client presents ST to service provider, along side its own ID, encrypted with type# session key

In short, neither TGS, nor service provide keeps any session keys. It's client's responsibility to obtain (Thru AS and TGS) to get those session keys, and present them to TGS/SP.