Kerberos Protocol

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“.

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.

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.

Descrição

• Protocolo Needham-SchroederBaseado 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.

Funcionamento I

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.

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

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.

Authentication Server Request (AS_REQ)

Cliente

KDC

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:

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.

Authentication Server Request (AS_REQ)

Cliente

KDC

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.

Authentication Server Request (AS_REQ)

Cliente

KDC

Ticket Granting Server Replay (TGS_REP) IAo 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;

Ticket Granting Server Replay (TGS_REP) IIA 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.

Authentication Server Request (AS_REQ)

Cliente

KDC

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:

Authentication Server Request (AS_REQ)

Cliente

KDC

App Server

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.

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.

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.

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