3.3. L'échange avec le service d'octroi de tickets (TGS)
Vue d'ensemble
L'échange TGS est utilisé par les clients pour obtenir des tickets de service auprès des serveurs d'application. Le client utilise son TGT (Ticket-Granting Ticket) pour s'authentifier auprès du TGS et demander un ticket de service.
Flux des messages
- KRB_TGS_REQ : le client envoie une demande de ticket au TGS
- inclut le TGT
- inclut l'authentificateur
- précise le service souhaité
- KRB_TGS_REP : le TGS répond avec le ticket de service
- KRB_ERROR : renvoyé si la demande ne peut pas être satisfaite
Génération du message KRB_TGS_REQ
Le client construit une demande contenant :
- le TGT (issu de l'échange AS précédent)
- l'authentificateur (chiffré avec la clé de session du TGT)
- le nom de principal du service
- les options et drapeaux de ticket demandés
- la période de validité demandée
Réception du message KRB_TGS_REQ
Le TGS valide la demande :
- déchiffre et valide le TGT
- déchiffre et valide l'authentificateur
- contrôle l'autorisation
- vérifie les contraintes de politique
- traite les options particulières (RENEW, VALIDATE, PROXY, FORWARDED, etc.)
Génération du message KRB_TGS_REP
Si la demande est valide, le TGS délivre un ticket de service :
- chiffre le ticket dans la clé à long terme du service
- chiffre la réponse (contenant la clé de session) dans la clé de session du TGT
- positionne les drapeaux de ticket appropriés
- fixe la période de validité du ticket
Réception du message KRB_TGS_REP
Le client :
- déchiffre la réponse au moyen de la clé de session du TGT
- extrait le nouveau ticket de service et la clé de session
- peut alors s'authentifier auprès du service demandé
Traitements particuliers
Le TGS gère divers cas particuliers :
- renouvellement de ticket
- validation de ticket (pour les tickets postdatés)
- demandes de tickets mandataires et transférés
- renvois inter-royaumes
- authentification utilisateur à utilisateur
Référence
Pour les détails techniques complets, voir RFC 4120, section 3.3.