TGS-REP

TGS-REP: Ticket Granting Server Reply (KDC to User)

KDC verifies TGT and its privileges then sends a session key for the user to the service

• TGS decrypts TGT with TGS secret key to obtain the TGS session key
• TGS decrypts the user authenticator with TGS session key.
• Once the two messages have been decrypted, TGS validates the messages
  • TGS compares the TGT username and the user authenticator username
  • TGS compares the TGT and user authenticator timestamp. Typically a difference between 2 minutes is fine.
  • TGS compares the IP address stored in the TGT and the IP address of the client host (who sent TGS the TGS-REP)
  • TGS checks that the TGT has not expired
  • TGS checks that the TGS Cache does not already contain a recent authenticator for this service to prevent replay attacks
• If the user is authenticated and the service exists, TGS grabs the service’s service secret key
• TGS adds this user authenticator to the TGS cache
• Message 1 to client; encrypted with TGS session key
  • Service name/ID
  • Timestamp
  • Lifetime (same as TGT’s)
  • Service Session Key
• Message 2 to client: service ticket (aka TGS); encrypted with Service Secret Key
  • Username/ID
  • Service name/ID
  • Timestamp
  • User IP address
  • Lifetime of service ticket
  • Service Session Key