Kerberos é um protocolo de autenticação que permite usuários acessarem serviços de forma segura e transparente através de uma rede. Ele utiliza um servidor de chaves centralizado (KDC) para emitir tickets criptografados que autenticam usuários e serviços um com o outros.

1. Kerberos Protocol

2. Introdução
• Protocolo de Autenticação de Rede.
Desenvolvido para fornecer forte autenticação para aplicações
cliente/servidor.
• Criado pelo MIT durante o projeto Athena (1983).
Atualmente na versão 5 (krb5-1.11.6 24/02/2015).
• Criptografia.
baseado no protocolo de Needham-Schroeder.
• "Kerberos is an authentication protocol for trusted hosts on untrusted
networks“.

3. Importante I
• A senha do usuário nunca deve viajar através da rede.
• A senha do usuário nunca deve ser armazenado na máquina do cliente: deve
ser descartado após o uso.
• A senha do usuário nunca deve ser armazenada de forma não criptografada,
mesmo no banco de dados do servidor de autenticação.
• O usuário é solicitado a digitar a senha uma única vez por sessão de trabalho.
Usuários podem acessar de forma transparente todos os serviços que estão
autorizados sem ter que redigitar a senha. Single Sign-On.
• Autenticação mútua. Não só os usuários têm de demonstrar que são quem
eles dizem, mas, quando solicitado, os servidores de aplicativos devem provar
a sua autenticidade para o cliente também.

4. Importante II
• O gerenciamento da informação de autenticação é centralizada e reside no
servidor de autenticação . Os servidores de aplicativos não devem conter as
informações de autenticação para seus usuários. Com isso:
1. O administrador pode desativar a conta de qualquer usuário, agindo em um
único local, sem ter que agir sobre os vários servidores de aplicativos que
fornecem os vários serviços;
2. Quando o usuário muda sua senha, ela é alterada para todos os serviços ao
mesmo tempo;
3. Não há redundância de informações de autenticação que de outra forma
deveria ser guardada em vários lugares.

5. Descrição
• Protocolo Needham-Schroeder
Baseado em algoritmo de chave simétrica.
Objetivo de estabelecer uma chave de sessão entre duas partes da rede.
• Utilização de KDC (Key-Distribution Center) dividido em duas partes:
Servidor de Autenticação (AS).
Servidor de Concessão de Ticket (TGS).
O KDC mantém um banco de dados de chaves secretas, onde toda entidade de
rede, clientes ou servidores, compartilham uma chave secreta que é apenas
conhecido por eles mesmos e pelo KDC.
Para a comunicação entre as entidades o KDC gera-se uma chave se sessão
temporária, para garantir a privacidade das informações.

6. Funcionamento I

7. Funcionamento II
1. AS_REQ: request inicial de autenticação do usuário. Encaminhado ao
Servidor de Autenticação do KDC (AS).
2. AS_REP: respostas do AS para o request em (1). Contém o TGT (criptografado
usando a chave secreta TGS) e a chave de sessão (criptografada usando a
chave secreta do usuário solicitante).
3. TGS_REQ: request do cliente para o TGS para um bilhete de serviço. Inclui o
TGT obtido a partir de (2) e um autenticador gerado pelo cliente
criptografado com a chave de sessão.

8. 4. TGS_REP: resposta do TGS para (3). Inclui o ticket de servido solicitado
(criptografado com a chave do serviço) e a chave de sessão do serviço gerada
pelo TGS e criptografada usando a chave de sessão anterior gerada pelo AS.
5. AP_REQ: request que o cliente envia para um servidor de aplicativos para
acessar um serviço. Inclui a permissão obtida a partir do TGS em (4) e um
autenticador novamente gerado pelo cliente, desta vez criptografado usando
a chave de sessão de serviço (gerada pelo TGS).
6. AP_REP: resposta que o servidor de aplicativos dá ao cliente para provar que
realmente é o servidor que o cliente está esperando. Nem sempre é
solicitado, somente quando a autenticação mútua é necessária.
Funcionamento III

9. Authentication Server Request
(AS_REQ)
Fase em que o cliente solicita ao KDC (mais especificamente ao AS) por um TGT.
O request é complemente não criptografado e parecido com o seguinte:
Principal: nome usado para se referir às entradas no banco de dados do servidor de
autenticação. Um Principal é associado a cada usuário, host ou serviço de um determinado
domínio.
PrincipalClient: entrada associada com a busca de autenticação do usuário (por exemplo:
user@domain.com).
PrincipalService: entrada associada com o serviço do bilhete que está sendo solicitado (por
exemplo: krbtgt/REALM@REALM).
IP_list: Lista de IP’s onde se pode utilizar o bilhete que será emitido (servidores).
Lifetime: tempo de validade máximo solicitado para o uso do bilhete.

10. Authentication Server Request
(AS_REQ)
Cliente
KDC

11. Authentication Server Reply
(AS_REP) I
Quando o request anterior chega, o AS verifica se o PrincipalClient e o
PrincipalService existem no banco de dados do KDC, se pelo menos um deles
não existe uma mensagem de erro é retornada ao cliente, caso contrário o AS
procede da seguinte maneira:
• Cria-se chave de sessão randomicamente que será compartilhada em segredo entre o
cliente e o TGS. Chamada SKtgs.
• Cria-se um TGT contendo os dados do usuário, os dados do serviço, a lista de endereços
de IP, data e hora (do KDC) no formato timestamp, o lifetime e por último a chave de
sessão SKtgs. Assim, temos o TGS:

12. Authentication Server Reply
(AS_REP) II
• Uma mensagem é criada e enviada ao cliente contendo: o TGT, criptografado com a
chave secreta para o serviço (Ktgs), os dados do serviço, o timestamp, o lifetime e a
chave de sessão, todos criptografados com a chave secreta do serviço solicitado pelo
usuário (Kuser). Em resumo têm-se:
• Uma vez que a informação presente no TGT é criptografada utilizando a chave secreta
para o servidor, ela não pode ser lida pelo cliente e precisa ser repetida. Neste ponto,
quando o cliente recebe a mensagem de resposta, será solicitado ao usuário digitar a
senha. O dado do usuário é concatenado com a senha e, em seguida, a função
string2key é aplicada: com a chave resultante é feita uma tentativa para decodificar a
parte da mensagem criptografada pelo KDC usando a chave secreta do usuário
armazenada na base de dados. Se o usuário é realmente quem diz e se digitou a senha
correta, a operação de decriptação será bem-sucedida e, portanto, a chave de sessão
pode ser extraída, o TGT (que permanecerá criptografado) é armazenado em cache de
credenciais do usuário.

13. Authentication Server Request
(AS_REQ)
Cliente
KDC

14. Ticket Granting Server Request
(TGS_REQ)
Após o usuário obter o TGT e a chave de sessão e deseja acessar o serviço, mas
ainda não possui o ticket de serviço, envia-se um pedido (TGS_REQ) para o TGS
da seguinte maneira:
• Cria-se um Autenticador com o Principal do cliente, o timestamp da máquina cliente, e
criptografa tudo com a SKtgs obtida.
• Cria-se um pacote (request) contendo: o Principal do serviço para qual o ticket é
necessário e o lifetime não criptografados e o autenticador; o TGT que já está
criptografado com a chave do TGS.

15. Authentication Server Request
(AS_REQ)
Cliente
KDC

16. Ticket Granting Server Replay
(TGS_REP) I
Ao receber o TGS_REQ, o TGS verifica se o PrincipalService existe no banco de
dados do KDC: caso exista, a requisição é aberta usando a chave para o Principal
extraindo a chave de sessão (SKtgs) que é usada para descriptografar o
Autenticador. Para emitir o ticket do serviço solicitado verificam-se algumas
condições:
• O TGT não expirou;
• O PrincipalClient apresentado no Autenticador corresponde com o apresentado no TGT;
• O autenticador não está presente no cache de replay e não tenha expirou;
• Se o IP_list não é nulo, verifica-se se o endereço de IP de origem no pacote do request
(TGS_REQ) é um dos previstos na lista;

17. Ticket Granting Server Replay
(TGS_REP) II
A verificação das condições anteriores garantem que o TGT realmente pertence
ao usuário que fez o request e, portanto, o TGS inicia o processamento da
resposta, da seguinte maneira:
• É criado randomicamente uma chave compartilhada em segredo entre o
cliente e o serviço (Skservice).
• É criado o ticket do serviço contendo:
• A resposta é enviada contendo: o ticket criado, criptografado usando a chave
secreta do serviço (Kservice) e demais dados da seguinte maneira:
Quando o cliente recebe a resposta, tendo no cache a chave SKtgs, ele pode
descriptografar parte da mensagem que contem as outras chaves e memorizá-las
junto com o ticket Tservice que, entretanto, permanece criptografado.

18. Authentication Server Request
(AS_REQ)
Cliente
KDC

19. Application Request (AP_REQ) I
O cliente, tendo as credenciais para acessar o serviço (o ticket e as chaves
mencionadas), pode pedir ao servidor de aplicações para acessar o recurso via
uma mensagem AP_REQ. Essa mensagem não é padronizada, varia de acordo
com a aplicação solicitada, é definida pelo programador da aplicação que define
a estratégia utilizada para validar o acesso do cliente. Entretando, pode ser
considerada a seguinte exemplo:
• O cliente cria um autenticador com os seguintes componentes:
• Cria-se um pacote para o request com a seguinte estrutura:

20. Authentication Server Request
(AS_REQ)
Cliente
KDC
App Server

21. Application Request (AP_REQ) II
Quando a mensagem chega, o servidor da aplicação abre o ticket, usando a
Kservice, e extrai a chave SKservice, que é usada para descriptografar o
autenticador. Para estabelecer que a requisição do usuário está autenticada e
garantir o acesso ao serviço, o servidor verifica as seguintes condições:
• O ticket não expirou;
• O PrincipalClient apresentado no autenticador corresponde ao apresentado no ticket;
• Se o IP_list (extraído do ticket) não é nulo, verifica-se que o endereço IP de origem do
pacote do request (AP_REQ) é um dos contidos na lista.
Nota: Essa estratégia é muito similar a utilizada pelo TGS para checar a
autenticidade da requisição do cliente ao solicitar um ticket para um serviço. TGS
pode ser considerado como um servidor de aplicativos cujo serviço é fornecer
tickets para aqueles que provam sua identidade com um TGT.

22. Principais Vantagens
Proteção por senha: As senhas dos usuários não precisam ser enviadas através da
rede.
Autenticação Cliente/Servidor: A comunicação é interrompida se caso cada lado
não conseguir autenticar a contrapartida.
Durabilidade e Reutilização: É possível manter-se autenticado através do
protocolo Kerberos, sem ter que re-introduzir um nome de usuário e senha
através da rede (até expirar da autenticação).
Ubiquidade: tornou-se tão amplamente utilizado e confiável pelos melhores
desenvolvedores, especialistas em segurança e cryptologistas, que quaisquer
novas fraquezas ou violações são susceptíveis de ser identificadas e superadas
imediatamente.

23. Principais Desvantagens
• Kerberos presume que cada usuário é confiável e está usando uma máquina
não confiável em uma rede não confiável. No entanto, se alguém além do
usuário legítimo tiver acesso à máquina que emite tickets usados para
autenticação o sistema de autenticação inteiro do Kerberos estará em risco.
• Para que um aplicativo use o Kerberos, sua fonte deve ser alterada para fazer
as chamadas apropriadas às bibliotecas do Kerberos. Os aplicativos
modificados desta maneira são considerados kerberizados. Para alguns
aplicativos, isto pode ser bastante problemático outros são incompatíveis.
Aplicativos de código fechado que não têm suporte ao Kerberos por padrão
são geralmente os mais problemáticos.
• Para se utilizar o Kerberos, é necessário tomar algumas decisões sobre
algumas questões cruciais, para as quais uma escolha errada pode
comprometer a segurança de todo o sistema. Por exemplo, tempo de duração
de um ticket, a escolha de quais proxies devem ser autorizados, e como
garantir a integridade física de algumas máquinas, como os servidores de
autenticação.

24. Referências
• http://web.mit.edu/kerberos/
• http://www.kerberos.org/software/tutorial.html
• http://en.wikipedia.org/wiki/Kerberos_(protocol)#History_and_development
• http://www.funhen.com/quais-sao-as-vantagens-de-kerberos/
• www.aavellar.com/arquivos/cripto/Kerberos.ppt