2.3.2 - Resposta do Servidor de Autenticação (AS_REP)
Quando a solicitação anterior chega, o AS verifica se PrincipalCLIENTE e PrincipalSERVIÇO existem no banco de dados do KDC: se não existir algum deles, uma mensagem de erro é enviada ao cliente, caso contrário, o servidor de autenticação processa a resposta da seguinte forma:
- ele cria aleatoriamente uma chave de sessão que será o segredo compartilhado entre o cliente e o TGS. Chamaremos ela de SKTGS;
- ele cria um bilhete de concessão colocando dentro dele o principal do usuário solicitante, o principal do serviço, suponhamos generico/DOMÍNIO@DOMÍNIO, a lista de endereços IP, momento (data e hora do KDC) em formato timestamp, o tempo de vida e a SKTGS; o bilhete de concessão então se assemelha a:
- ele gera e envia a resposta contendo:
1) o bilhete criado, criptografado com a chave secreta do serviço (KTGS);
2) principal do serviço, momento, tempo de vida e chave de sessão, todos criptografados usando a chave secreta do usuário solicitante do serviço (KUSUÁRIO). Em suma:
Esta mensagem parece conter informação redundante (PrincipalSERVIÇO, momento, tempo_de_vida e chave de sessão). Todavia, não é o caso: uma vez que a informação presente no TGT são criptografadas com a chave secreta do servidor, ela não poder ser lida pelo cliente e precisa ser repetida. A esta altura, quando o cliente recebe a mensagem de resposta, ele pede ao usuário para digitar a senha. O tempero é concatenado à senha e a nova sequência passada pela função string2key: com a chave resultante, uma tentativa é feita para descriptografar a parte da mensagem criptografada pelo KDC usando a chave secreta armazenada no banco de dados. Se o usuário é realmente quem diz ser e se digitou a senha correta, a operação de descriptografia será bem sucedida e a chave de sessão poderá ser extraída e com o TGT (que permanece criptografado) armazenado no cache de credenciais do usuário.
O tempo de vida real posto no bilhete é o menor dos seguintes valores: o tempo de vida solicitado pelo cliente, o contido no principal do usuário e o do principal do serviço. Na realidade, em termos de implementação, outro limite pode ser definido a partir da configuração do KDC e aplicado a qualquer bilhete.
Próximo: 2.3.3 - Solicitação de Concessão de Bilhete (TGS_REQ)