2.3.4 - Resposta do Servidor de Concessão de Bilhetes (TGS_REP)
Quando uma solicitação de concessão de bilhete chega, o TGS primeiramente verifica se o principal do serviço solicitado (PrincipalSERVIÇO) existe no banco de dados do KDC: se existe, ele abre o TGT usando a chave para generico/DOMÍNIO@DOMÍNIO e extrai a chave de sessão (SKTGS) a qual usa para descriptografar o autenticador. Para o bilhete do serviço a ser emitido, ele verifica se as seguintes condições tem resultado positivo:
- o TGT não expirou;
- o PrincipalCLIENTE presente no autenticador corresponde ao presente no TGT;
- o autenticador não está presente no cache de reprodução e não expirou;
- se lista_IPs não é nula, ele verifica se o IP de origem do pacote solicitado (TGS_REQ) é um dos contidos na lista.
Tais condições provam que o TGT realmente pertence ao usuário que fez a solicitação e, deste modo, o TGS inicia o processamento da resposta, a seguir:
- ele cria aleatoriamente uma chave de sessão que será o segredo compartilhado entre cliente e serviço, digamos SKSERVIÇO;
- ele cria o bilhete de serviço, colocando dentro o principal do usuário, o principal do serviço, a lista de IPs, momento (data e hora do KDC) em formato timestamp, o tempo de vida (o mínimo entre o tempo de vida do TGT e o associado ao principal do serviço) e, por fim, a chave de sessão SKSERVIÇO. Conhecido como TSERVIÇO, o novo bilhete é:
- ele envia a mensagem de resposta contendo: o bilhete criado, criptografado com a chave secreta de serviço (KSERVIÇO), o principal do serviço, momento, tempo de vida e nova chave de sessão, todos criptografados com a chave de sessão extraída do TGT. Em suma:
Quando o cliente recebe a resposta, tendo a chave de sessão SKTGS no cache de credenciais, ele pode descriptografar parte da mensagem contendo a outra chave de sessão e memorizá-la juntamente com o bilhete de serviço TSERVIÇO que, contudo, permanece criptografado.
Próximo: 2.3.5 - Solicitação de Aplicação (AP_REQ)
Anterior: 2.3.3 - Solicitação de Concessão de Bilhete (TGS_REQ)