kerberos

Resumo

Kerberos é um protocolo de autenticação desenvolvido no MIT, como parte do projeto Athena. Com o objetivo de aumentar a segurança em uma rede, o Kerberos atua de forma centralizada, e se inspira no modelo de criptografia de chave simétrica para autenticar clientes e servidores. Nesse contexto, o trabalho visa apresentar o funcionamento, limitações, aplicações e utilização do Kerberos.

Autores

Esse trabalho foi escrito para a disciplina Redes de Computadores I, no primeiro período de 2012, pelos seguintes alunos:

Bernardo de Campos Vidal Camilo

• 5o período de Engenharia de Computação e Informação na Universidade Federal do Rio de Janeiro
• Contato:

Diego Ximenes Mendes

• 5o período de Engenharia de Computação e Informação na Universidade Federal do Rio de Janeiro
• Contato:

Pedro Paiva Miranda

• 5o período de Engenharia de Computação e Informação na Universidade Federal do Rio de Janeiro
• Contato:

-

Este trabalho foi totalmente produzido pelos autores que declaram não terem violado os direitos autorais de terceiros, sejam eles pessoas físicas ou jurídicas. Havendo textos, tabelas e figuras transcritos de obras de terceiros com direitos autorais protegidos ou de domínio público tal como idéias e conceitos de terceiros, mesmo que sejam encontrados na Internet, os mesmos estão com os devidos créditos aos autores originais e estão incluídas apenas com o intuito de deixar o trabalho autocontido. O(s) autor(es) tem(êm) ciência dos Artigos 297 a 299 do Código Penal Brasileiro e também que o uso do artifício de copiar/colar texto de outras fontes e outras formas de plágio é um ato ilícito, condenável e passível de punição severa. No contexto da Universidade a punição não precisa se restringir à reprovação na disciplina e pode gerar um processo disciplinar que pode levar o(s) aluno(s) à suspensão;

Figura 1. Emblema Kerberos MIT

Kerberos é um protocolo de autenticação desenvolvido no MIT como parte do projeto Athena. O projeto tinha como objetivo produzir um ambiente distribuído aberto com propósitos educacionais, em que usuários no campus acessariam serviços nos servidores distribuídos pela rede. Em um cenário ideal, os servidores poderiam restringir o acesso a usuários autorizados e autenticar as solitações de serviço. No entanto, nesse ambiente isso não é possível.

Não podemos garantir que uma máquina identifique seus usuários nos serviços da rede. Um usuário pode ter acesso a uma máquina e fingir ser outro usuário operando a partir dela, ou pode alterar o endereço de rede de uma máquina de modo que as solitações enviadas a partir desta pareçam vir de outra, ou até mesmo espionar as trocas e usar um ataque por repetição para obter acesso a um servidor ou perturbar as operações. Resumidamente, podemos afirmar que, nesse ambiente, um usuário não autorizado pode obter acesso a serviços e dados restritos.

Em vista a essa fragilidade, o Kerberos foi criado.Inicialmente, foi idealizado com três componentes (autenticação, contabilidade e auditoria) para proteger as entradas de uma rede. No entanto, apenas a primeira componente foi implementada, caracterizando-o como um protocolo de autenticação centralizado entre clientes e servidores. Seu nome é uma referência ao cão Kerberos (Cérbero) que, na mitologia grega, era um cão de três cabeças que fazia a segurança dos portões do sub-mundo dos mortos.

Diversas versões já existiram, sendo as primeiras utilizadas apenas dentro do MIT. A versão 4, publicada nos anos 80, foi a primeira a ser disponilizada de forma livre, sob uma licença similar à BSD (Berkeley Software Distribution), e ainda focava o projeto Athena. Em 1993, publicou-se a versão 5, melhorando a segurança e as limitações relativas a versão anterior.

No entanto, é importante ressaltar que até os anos 2000, o Kerberos era considerado pelas autoridades norte-americanas uma tecnologia de auxílio militar e por isso não poderia ser exportado. Em resposta a essa situação, o KTH-KRB foi desenvolvido no Instituto Real de Tecnologia, na Suécia, tornando o sistema disponível fora dos Estados Unidos até a mudança nas restrições de exportação.

Em 2007, formou-se o Kerberus Consortium para continuar o seu desenvolvimento, contanto com apoio de gigantes, como Oracle, Apple Inc., Google, Microsoft e TeamF1 Inc., de instituições acadêmicas, como KTH-Royal Institute of Technology, Stanford University, MIT e de fornecedores, como a CyberSafe que oferece soluções comerciais. Atualmente, várias implementações desse protocolo foram criadas e implementadas por diversos grupos e empresas.

• Conceitos Iniciais

Alguns conceitos básicos são importantes para o entendimento do funcionamento do Kerberos.

Usuário e cliente: O termo usuário é uma referência a uma pessoa que utiliza programas ou serviços. Cliente pode ser uma referência tanto a uma pessoa quanto a um programa que utiliza serviços ou programas.

Serviço e servidor: Geralmente as aplicações em uma rede consistem de duas partes: o “lado do cliente”, que é um programa que executa em uma máquina e solicita um serviço remoto; e o “lado do servidor”, que é um programa que executa em uma máquina remota e executa o serviço requisitado. Portanto, definimos serviço como uma referência a uma ação abstrata a ser realizada, e definimos servidor como o processo que executa tal ação (serviço).

Kerberos principal: Toda entidade que utiliza o Kerberos, seja essa entidade um cliente, um servidor ou um serviço, é um cliente do Kerberos, já que essa entidade utiliza os serviços do Kerberos. Então para distinguir os clientes do Kerberos dos clientes dos serviços foi criado o termo principal, que se refere às entidades clientes do Kerberos.

Chave simétrica: O emissor da mensagem a ser criptografada e o receptor devem possuir a mesma chave, onde tal chave é utilizada para criptografar e decriptografar a mensagem.

• Domínio Kerberos

Um domínio Kerberos consiste em um modelo com servidor Kerberos, diversos clientes e diversos servidores de aplicações. Nesse domínio, o servidor Kerberos necessita ter o nome dos usuários e as chaves privadas de todos os usuários em seu banco de dados, sendo que as chaves privadas dos usuários são derivadas das senhas dos mesmos. O servidor Kerberos também necessita compartilhar uma chave secreta com cada servidor presente no domínio. Portanto o conceito de domínio pode ser entendido como um conjunto de principals gerenciados que compartilham o mesmo banco de dados Kerberos.

• Nomes dos Kerberos principals

No Kerberos, os Kerberos principals são nomeados, dando assim uma base para que o sistema possa fazer autenticações. Desse modo, torna-se importante definirmos do que consiste o nome no Kerberos.

O nome no Kerberos consiste de três itens: nome primário, instância e domínio. No Kerberos versão 4, o nome é descrito desta maneira: primário.instância@domínio. Já no Kerberos versão 5, o nome é descrito desta maneira: primário/instância@domínio.

O nome primário se baseia no nome do usuário, do servidor ou do serviço.

A instância é utilizada para se fazer distinções entre diferentes nomes primários, possuindo informações adicionais. Para os usuários, a instância pode indicar privilégios, como por exemplo, root. Para os serviços, a instância normalmente indica o nome do servidor onde o serviço está executando.

O domínio se refere ao nome da entidade administrativa que mantém o banco de dados relativo à autenticação. Como exemplo, podemos supor que diferentes instituições possuem diferentes bases de dados de autenticação e, portanto, diferentes nomes de domínio.

• Credenciais do Kerberos

Existem dois tipos de credenciais no mecanismo de autenticação do Kerberos, os tickets e os autenticadores.

Os campos que compõem um ticket no Kerberos versão 4 são: nome do cliente; nome do servidor; carimbo de tempo (instante de tempo em que o ticket foi criado); tempo de vida; endereço de rede do cliente; chave de sessão compartilhada entre o servidor e o cliente. No Kerberos versão 5, os itens que estão incluídos no ticket são: flags; domínio do cliente; tempos; chave de sessão compartilhada entre o servidor e o cliente; nome do cliente; endereço de rede do cliente.

Figura 2.Ticket no Kerberos versão 4.


Figura 3.Ticket no Kerberos versão 5.



Os campos que compõem um autenticador na versão 4 são: nome do cliente; endereço de rede do cliente; carimbo de tempo (instante de tempo em que o autenticador foi criado). No Kerberos versão 5, os itens que estão incluídos no autenticador são: nome do cliente; domínio do cliente; carimbo de tempo (instante de tempo em que o autenticador foi criado); subchave (opcional); número de sequência (opcional).

Figura 4.Autenticador no Kerberos versão 4.


Figura 5.Autenticador no Kerberos versão 5.



O ticket possui a ideia de ser reutilizável, já o autenticador pode ser utilizado apenas uma vez e possui tempo de vida muito curto. Tal fato aperfeiçoará a segurança do Kerberos por questões que serão exploradas mais a frente. As utilidades dos itens do autenticador e do ticket também serão descritas mais adiante.

• KDC (Key Distribution Center)

O servidor de autenticação em um ambiente Kerberos é chamado de KDC (Key Distribution Center). O KDC é composto por três partes: Banco de dados, AS (Authentication Service) e TGS (Ticket-Granting Service).

O banco de dados armazena as informações referentes a todos os principals do domínio no qual o banco de dados pertence. No Kerberos versão 5, cada registro do banco de dados possui as seguintes informações: nome do principal no qual o registro é associado; chave privada relativa ao principal; valor máximo do tempo de vida referente ao ticket associado ao principal; valor máximo do tempo que um ticket associado ao principal pode ser renovado; atributos que caracterizam os flags dos tickets associados ao principal; data de expiração do principal, ou seja, data a partir do qual nenhum ticket poderá ser requisitado.

Todas as operações de escrita no banco de dados são feitas pelo KDBM (Key Distribution Manegement Service). O KDBM se encontra no computador mestre (master) do Kerberos, que por sua vez deve ser mantido em uma sala fisicamente segura. Cópias com autorização apenas de leitura podem existir em outros computadores Kerberos, chamados de computadores escravos (slaves), porém mudanças no banco de dados só podem ser efetuadas no computador mestre, sendo necessário possuir a senha mestre do sistema Kerberos.

Algumas vantagens de se possuir cópias de leituras do banco de dados são: se o computador mestre do Kerberos por algum motivo não está acessível, ainda continua sendo possível fazer autenticações; o fato de ser possível fazer autenticações em diferentes computadores contribui para que a máquina mestre não fique sobrecarregada. As inconsistências são uma grande desvantagem de se ter as cópias de leitura do banco de dados, já que essas cópias, antes de passarem por um processo de atualização periódico, podem conter dados discrepantes em relação aos dados cadastrados no computador mestre.

• Obtendo o ticket de concessão de ticket (TGT)

As sessões Obtendo o ticket de concessão de ticket (TGT), Obtendo tickets dos servidores, Solicitando um serviço e Solicitando serviço em outro domínio explicam o funcionamento do Kerberos versão 4. O Kerberos versão 5 (versão mais recente) é explicado mais facilmente traçando-se um paralelo entre as duas versões. Portanto, o funcionamento a versão 5 será abordada a partir da sessão Kerberos versão 5.

Após o usuário fazer o login em sua estação de trabalho utilizando a sua própria senha, existe a necessidade de se obter o ticket de concessão de ticket, que também é chamado de TGT (Ticket-Granting Ticket). Para isso, o cliente associado ao usuário deve enviar uma mensagem de solicitação para o AS (Authentication Server) contendo os seguintes itens: nome do usuário (IDc); nome de um serviço especial (IDtgs) conhecido como TGS (Ticket-Granting Service); carimbo de tempo (TS1) que identifica a hora em que a solicitação foi criada.

(1) C → AS: IDc||IDtgs||TS1 (*1 Legenda no final da sessão)

Figura 6. Cliente solicita TGT ao AS no Kerberos versão 4.



O AS confirma se o usuário referente ao nome do usuário recebido e o serviço referente ao nome do TGS recebido existem no banco de dados Kerberos. Por motivos que serão explicados mais adiante, o sincronismo entre os relógios dos principals é importante para a segurança no Kerberos, portanto, o AS também verifica, a partir do carimbo de tempo, se o relógio do cliente está sincronizado com o do AS. Caso esses dados estejam compatíveis, o AS gera uma chave de sessão aleatória que servirá para realizar comunicações entre o TGS e o cliente de maneira segura. O AS também cria um ticket, o TGT, que servirá para a autenticação do cliente no TGS, e o criptografa com a chave privada do TGS conhecida apenas pelo AS e pelo TGS.

Com o TGT criptografado e com a chave de sessão do cliente com o TGS, o AS se vê pronto para criar uma resposta contendo os seguintes itens: TGT (Tickettgs); chave de sessão do cliente com o TGS (Kc,tgs); nome do TGS (IDtgs); carimbo de tempo identificando a hora da criação da resposta (TS2); tempo de vida do TGT (TempodeVida2). Tal resposta é criptografada com a chave privada do cliente solicitante e então enviada ao cliente.

(2) AS → Cliente: E(Kc, [Kc,tgs||IDtgs||TS2||TempodeVida2||Tickettgs])

Tickettgs = E(Ktgs, [Kc,tgs||IDc||ADc||IDtgs||TS2||TempodeVida2]) (*2 Legenda no final da sessão)

Figura 7. AS envia resposta da solicitação do TGT ao cliente no Kerberos versão 4.



Neste ponto é bom lembrarmos que a chave privada do cliente é derivada da senha do usuário, e apenas o próprio cliente e o serviço de autenticação possuem acesso a essa chave. Também lembramos que o TGT foi criptografado com a chave do TGS, chave que é conhecida apenas pelo TGS e pelo serviço de autenticação, então podemos garantir que o usuário não pode alterar esse ticket para que no futuro possa utilizá-lo de maneira maliciosa.

Quando essa resposta chega ao cliente, é feita uma solicitação para que o usuário forneça a sua senha, e a partir dessa senha é gerada a chave privada através do algoritmo de criptografia DES (Data Encryption Standard). Essa chave privada permitirá que se tente decriptografar a mensagem recebida. Se a senha fornecida for correta, a mensagem poderá ser decriptografada e, portanto, o TGT e a chave de sessão serão recuperados e armazenados para um uso futuro. O nome do TGS vindo da resposta possibilitará que o cliente confirme que o ticket é para o TGS, já o carimbo de tempo e o tempo de vida informarão respectivamente a hora de criação da resposta e o tempo de vida do ticket. Como apenas o cliente correto deverá saber a senha que decriptografa a mensagem, podemos inferir que apenas o usuário correto poderá recuperar o TGT e a chave de sessão entre o TGS e o cliente.

(*1) Legenda do formato da mensagem utilizada: a parte à esquerda do sinal de dois pontos indica o emissor (lado esquerdo da seta) e o receptor (lado direito da seta); a parte à direita indica o conteúdo da mensagem; o símbolo “||” indica concatenação; o caractere “C” é uma referência ao cliente.

(*2) Legenda: E(K, itens) representa uma função de criptografia DES (Data Encryption Standard) que criptografa os itens utilizando com base a chave K.

• Obtendo tickets dos servidores

No mecanismo de funcionamento do Kerberos, é necessário que o cliente tenha um ticket para cada serviço que ele queira utilizar. Os tickets são obtidos através do TGS e são individuais para cada servidor e cliente.

Aqui consideramos que o cliente já obteve o TGT, então quando um cliente quer solicitar um ticket que ainda não possui ele envia uma solicitação ao TGS. Essa solicitação contém os seguintes itens: nome do servidor para qual o ticket está sendo solicitado (IDv); TGT (Tickettgs); um autenticador gerado pelo cliente e criptografado com a chave de sessão do cliente solicitante com o TGS (Autenticadorc).

(3) C → TGS: IDv||Tickettgs||Autenticadorc

Tickettgs = E(Ktgs, [Kc,tgs||IDc||ADc||IDtgs||TS2||TempodeVida2])

Autenticadorc = E(Kc,tgs, [IDc||ADc||TS3])

Figura 8. Cliente envia solicitação de ticket ao TGS no Kerberos versão 4.



Após receber a solicitação, o TGS decriptografa o TGT com a chave do próprio TGS e decriptografa o autenticador com a chave de sessão do cliente com o TGS.

Como somente o TGS e o próprio cliente possuem a chave de sessão compartilhada entre os dois, o cliente infere que somente o TGS conseguirá decriptografar o autenticador, e o TGS conclui que o criador do autenticador foi mesmo o cliente.

Ao analisar o carimbo de tempo do autenticador (data e hora em que o autenticador foi emitido) juntamente com o tempo de vida do autenticador, o TGS pode verificar se o autenticador expirou. A mesma verificação de expiração é feita com o ticket. O fato do tempo de vida do autenticador ser curto dificulta uma situação onde alguém intercepte um autenticador criado por um terceiro e utilize-o depois de maneira maliciosa, já que o tempo de se fazer tal operação geralmente é maior do que o tempo de vida do autenticador. Com essa situação descrita, fica evidenciada a necessidade de que os relógios dos principals estejam sincronizados.

O TGS ainda compara o nome do cliente e o endereço de rede do cliente contido no autenticador, com o nome do cliente e o endereço de rede do cliente contido no ticket, e com o endereço de rede do emissor da solicitação. Se todas essas informações coincidirem, o TGS possui garantias de que o emissor do ticket é realmente o proprietário real do ticket.

Através das técnicas descritas acima, o TGS consegue verificar a autenticidade do cliente solicitante. O cliente também pode exigir que o servidor se autentique perante a ele, porém esse assunto só será abordado na próxima sessão (Solicitando um serviço).

Caso a autenticidade do cliente seja comprovada, o TGS constrói um novo ticket referente ao servidor requisitado e ao cliente solicitante. Esse novo ticket possuirá o tempo de vida calculado pelo mínimo entre o tempo de vida restante ao TGT e o tempo padrão relacionado com o serviço requisitado. O TGS também criará uma chave de sessão aleatória do cliente com o servidor.

Com o ticket e a chave de sessão criadas, o TGS monta uma resposta contendo os seguintes itens: chave de sessão do cliente com o servidor (Kc,v); ticket do servidor com o cliente (Ticketv); nome do servidor (IDv); carimbo de tempo identificando a hora de criação da resposta (TS4). Então, tal resposta é criptografada com a chave de sessão do cliente com o TGS (Kc,tgs). Como a chave de sessão do cliente com o TGS só é acessível pelo próprio cliente e pelo TGS, pode-se garantir uma comunicação segura.

(4) TGS → C: E(Kc,tgs, [Kc,v||IDv||TS4||Ticketv])

Ticketv = E(Kv, [Kc,v||IDc||ADc||IDv||TS4||TempodeVida4])

Figura 9. TGS responde solicitação de ticket ao cliente no Kerberos versão 4.



Ao receber a resposta, o cliente a decriptografa com a chave de sessão do cliente com o TGS, verificará se o carimbo de tempo e o nome do servidor são compatíveis, e se tudo estiver certo o cliente recupera e armazena o novo ticket e a nova chave de sessão referente ao servidor requisitado. Ao contrário do que ocorreu no mecanismo de obtenção de ticket de concessão, não houve a necessidade de que o usuário fornecesse a sua senha para decriptografar a resposta. Portanto é importante salientar que, esse exemplo de utilização da chave de sessão, mostra como se minimiza o número de vezes que um usuário precisa digitar sua senha, diminuindo assim as chances de que a senha seja interceptada.

O AS ou TGS pode conceder um tempo de vida ao ticket suficientemente grande para que o usuário não tenha que solicitá-lo muitas vezes. No caso do TGT, isso se torna um fator muito importante para a segurança, já que cada vez que o usuário solicita um TGT ele precisa digitar sua senha.

• Solicitando um serviço

Aqui consideramos que o cliente já possui o ticket referente ao servidor no qual ele pretende solicitar um serviço, então quando o cliente deseja requisitar um serviço, ele cria um autenticador e o criptografa com a chave de sessão do cliente com o servidor. Com o ticket do servidor e o autenticador criptografado o cliente envia para o servidor a solicitação.

(5) C → V: Ticketv||Autenticadorc

Ticketv = E(Kv, [Kc,v||IDc||ADc||IDv||TS4||TempodeVida4])

Autenticadorc = E(Kc,v, [IDc||ADc||TS5])

Figura 10. Cliente envia solicitação de serviço ao servidor V no Kerberos versão 4.



Ao receber a solicitação, o servidor decriptografa o autenticador e o ticket. Após utilizar as técnicas descritas nas sessões anteriores, o servidor consegue comprovar a autenticidade do cliente solicitante.

Caso a autenticidade do cliente solicitante seja comprovada, o cliente também pode exigir que o servidor realize um processo de autenticação. Esse processo é feito com o servidor identificando o carimbo de tempo do autenticador enviado pelo cliente, incrementando em uma unidade esse carimbo de tempo, e o enviando ao cliente criptografado pela chave de sessão do servidor com o cliente. Como a mensagem foi criptografada com a chave de sessão do cliente com o servidor, o cliente tem certeza de que somente ele próprio ou o servidor foi o criador da mensagem, e como o conteúdo da não foi uma repetição da mensagem antiga, pode-se inferir que o criador da mensagem foi o servidor, obtendo assim a autenticação.

(6) V → C: E(Kc,v, [TS5 + 1])

Figura 11.Servidor envia resposta ao pedido de autenticação do servidor perante ao cliente no Kerberos versão 4.



Ao final desse processo de autenticação, tanto o servidor está convencido de que o cliente é quem ele diz ser quanto o cliente também está convencido de que o servidor é realmente o servidor solicitado.

• Solicitando serviço em outro domínio

Clientes e servidores que estão relacionados com diferentes entidades administrativas geralmente compõem domínios diferentes. Deste modo, é razoável que por algum motivo administrativo, clientes e servidores não possam se registrar em servidores Kerberos de outros domínios. Porém, pode existir a necessidade de que um usuário tenha que acessar um servidor pertencente a outro domínio.

Para prover a autenticação necessária na situação descrita acima, o TGS de um domínio deve compartilhar uma chave secreta com o TGS de todos os outros domínios. Considerando essa ideia, percebemos que se houver n domínios, então deverá haver n*(n-1)/2 chaves compartilhadas, podendo gerar assim um problema caso o número n de domínios for grande. Tal problema foi resolvido na versão 5 do Kerberos e a sua explicação está descrita mais adiante.

Para que um cliente solicite um serviço de um servidor pertencente a um domínio remoto, primeiramente ele deve obter o TGT referente ao domínio local, assim como foi descrito na sessão Obtendo o ticket de concessão de ticket (TGT).

Após obter o TGT do domínio local, o cliente solicitará o TGT do domínio remoto ao TGS do domínio local. Essa solicitação contém os seguintes itens: nome do TGS remoto para qual o ticket está sendo solicitado (IDtgsrem); o TGT referente ao domínio local (Tickettgs); um autenticador gerado pelo cliente e criptografado com a chave de sessão do cliente solicitante com o TGS local (Autenticadorc).

(3) C → TGS: IDtgsrem||Tickettgs||Autenticadorc

Figura 12. Cliente solicita TGT de um domínio remoto no Kerberos versão 4.



Ao receber a solicitação, o servidor decriptografa o autenticador e o ticket, e verifica a autenticidade do cliente pelas mesmas técnicas descritas nas sessões anteriores. Caso a autenticidade do cliente solicitante seja comprovada, o TGS local envia ao cliente uma resposta criptografada com a chave de sessão do cliente com o TGS local, contendo os seguintes itens: TGT entre cliente e o TGS do domínio remoto (Tickettgtrem); chave de sessão entre cliente e o TGS do domínio remoto (Kc,tgsrem); nome do TGS remoto (IDtgsrem); carimbo de tempo que identifica a hora de criação da mensagem (TS4).

(4) TGS → C: E(Kc,tgs, [Kc,tgsrem||IDtgsrem||TS4||Tickettgsrem])

Figura 13. TGS local envia TGT remoto ao cliente no Kerberos versão 4.



Ao receber e decriptografar a mensagem, o cliente terá em mãos o TGT referente ao domínio remoto e a chave de sessão entre o TGS remoto e o cliente, podendo assim solicitar ao TGS remoto um ticket referente a um servidor pertencente a esse domínio remoto. Isso é feito com uma solicitação do cliente ao TGS remoto contendo os seguintes itens: nome do servidor do domínio remoto para qual o ticket está sendo solicitado (IDvrem); TGT do domínio remoto (Tickettgsrem); um autenticador gerado pelo cliente e criptografado com a chave de sessão do cliente solicitante com o TGS do domínio remoto.

(5) C → TGSrem: IDvrem||Tickettgsrem||Autenticadorc

Figura 14. Cliente solicita ao TGT remoto o ticket para o servidor remoto no Kerberos versão 4.



Ao receber a solicitação, o TGS do domínio remoto toma as providências necessárias para autenticar o cliente solicitante. Caso o cliente consiga provar a sua autenticidade, o TGS do domínio remoto cria um novo ticket referente ao servidor requisitado e ao cliente solicitante. Também é criada uma chave de sessão aleatória do cliente com o servidor remoto. Com isso o TGS remoto se vê apto a criar a resposta criptografada com a chave de sessão do cliente com o TGS remoto, contendo os seguintes itens: chave de sessão entre o cliente e o servidor remoto (Kc,vrem); nome do servidor remoto (IDvrem); carimbo de tempo identificando a hora de criação da mensagem (TS6); ticket referente ao servidor remoto e ao cliente (Ticketvrem).

(6) TGSrem → C: E(Kc,tgsrem, [Kc,vrem||IDvrem||TS6||Ticketvrem])

Figura 15. TGS remoto envia ticket do servidor remoto ao cliente no Kerberos versão 4.



Ao receber a resposta e decriptografá-la, o cliente terá posse do ticket referente ao cliente e ao servidor do domínio remoto, juntamente com a chave de sessão do cliente com o servidor do domínio remoto. Com isso, o cliente pode criar o autenticador criptografado com a chave de sessão do cliente com o servidor do domínio remoto, e assim enviar a solicitação de serviço.

(7) C → Vrem: Ticketvrem||Autenticadorc

Figura 16. Cliente solicita serviço remoto no Kerberos versão 4.



• Kerberos versão 5

A versão 5 do Kerberos apresenta uma série de melhorias em relação a versão 4. Nesta sessão são apresentadas algumas mudanças técnicas e uma breve explicação do funcionamento da nova versão.

A versão 4 requer a utilização de endereços de rede IP (Internet Protocol). Entretanto, na versão 5 é possível utilizar qualquer tipo de endereço de rede, já que agora eles são marcados com tipo e tamanho.

Na versão 4 é exigido que o algoritmo de criptografia a ser utilizado seja o DES (Data Encryption Standard). Porém, na versão 5 é possível utilizar qualquer técnica de criptografia, já que agora as chaves de criptografia também são marcadas com tipo e tamanho.

A seguir, são descritos os formatos das trocas de mensagens realizadas pelo Kerberos versão 5.

Assim como descrito na sessão Credenciais do Kerberos, os tickets e os autenticadores da versão 5 possuem itens diferentes em relação a versão 4. No decorrer das trocas de mensagens serão explicadas as funcionalidades das mudanças nesses formatos.

Troca de mensagens para o cliente obter o ticket de concessão de tickets (TGT) na versão 5 do Kerberos:

(1) C → AS: Options||IDc||Realmc||IDtgs||Times||Nonce1

(2) AS → C:Realmc||IDc||Tickettgs||E(Kc,[Kc,tgs||Times||Nonce1||Realmtgs||IDtgs])

Tickettgs = E(Ktgs, [Flags||Kc,tgs||Realmc||IDc||ADc||Times])

Na mensagem (1), referente à solicitação de TGT enviada pelo cliente ao AS, verifica-se a presença dos seguintes itens que não existiam na versão 4: Opções (Options); domínio do cliente (Realmc); Tempos (Times); Nonce (Nonce1).

O campo Opções é utilizado para requisitar que determinados flags sejam marcados no ticket retornado ao cliente. As utilidades dos flags serão explicadas na sessão Flags do ticket.

O campo Tempos é utilizado pelo cliente para requisitar as seguintes definições de tempo no ticket: from, till e rtime. O campo from indica o instante de tempo inicial desejado para o ticket solicitado. O campo till indica a hora de expiração requisitada para o ticket solicitado. Já o campo rtime indica o tempo limite de renovação solicitado.

Na versão 4, os tempos de vida são codificados em 8 bits e em unidades de 5 minutos. Portanto, o tempo de vida máximo de um ticket na versão 4 é de 2^8 * 5 minutos = 1280 minutos que equivale a aproximadamente 21 horas. Com isso alguns serviços que, necessitam manter uma comunicação longa e com credenciais válidas durante todo o tempo, podem encontrar problemas na versão 4. A versão 5 conseguiu resolver essa dificuldade utilizando as definições de tempo descritas acima, já que assim torna-se possível determinar um tempo de vida arbitrário ao ticket.

O campo Nonce possui um valor aleatório a ser repetido na resposta do AS, garantindo assim que a resposta é recente e que não foi repetida por ninguém mal intencionado.

A mensagem (2), referente à resposta do AS a solicitação de TGT do cliente, contém os seguintes itens: domínio do cliente (Realmc); nome do cliente (IDc); TGT (Tickettgs); e um bloco criptografado com a chave privada do cliente. O bloco criptografado contém: chave de sessão do cliente com o TGS (Kc,tgs); tempos da mensagem de solicitação de TGT (Times); o Nonce da mensagem de solicitação de TGT (Nonce1); domínio do TGS (Realmtgs); nome do TGS (IDtgs).

Percebe-se que na versão 5, a mensagem (2) não possui o TGT criptografado novamente com a chave de sessão do cliente com o TGS, situação que ocorre na versão 4. Verificamos que realmente não existe a necessidade de se gastar esse segundo processamento de criptografia, já que somente o TGS e o AS conseguiriam decriptografar o TGT.

Troca de mensagens para o cliente obter tickets dos servidores na versão 5 do Kerberos:

(3) C → TGS: Options||IDv||Times||Nonce2||Tickettgs||Authenticatorc

Tickettgs = E(Ktgs, [Flags||Kc,tgs||Realmc||IDc||ADc||Times])

Authenticatorc = E(Kv, [IDc||Realmc||TS1])

(4) TGS → C:

Realmc||IDc||Ticketv||E(Kc, [Kc,tgs||Times||Nonce1||Realmtgs||IDtgs])

Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDc||ADc||Times])

Troca de mensagens para o cliente obter um serviço na versão 5 do Kerberos:

(5) C → V: Options||Ticketv||Authenticatorc

Ticketv = E(Kv, [Flags||Kc,v||Realmc||IDc||ADc||Times])

Authenticatorc = E(Kc,v, [IDc||Realmc||TS2||Subkey||Seq#])

(6) V → C: E_Kc,v[TS2||Subkey||Seq#]

Na mensagem (5), o autenticador possui os seguintes itens que não existiam na versão 4: domínio do cliente(Realmc); subchave (Subkey); número de sequência (Seq#).

O campo subchave é opcional e permite que o cliente escolha uma chave de criptografia que será utilizada para uma comunicação segura entre o cliente e o serviço. Caso esse campo seja omitido, a chave de sessão do cliente com o servidor será usada para garantir que essa comunicação seja segura.

O campo “número de sequência” também é opcional e permite que o cliente especifique o número de sequência inicial a ser utilizado pelo servidor para mensagens enviadas ao cliente durante essa sessão de aplicação. Com isso pode-se detectar repetições devido à enumeração das mensagens.

A mensagem (6) é enviada quando o cliente exige que o servidor se autentique perante a ele. Para fazer a autenticação na versão 4, o servidor enviava ao cliente o carimbo de tempo que indicava a hora de criação da solicitação de serviço incrementado em uma unidade. Já na versão 5, isso não acontece, já que as chaves utilizadas na criptografia da mensagem, juntamente com o carimbo de tempo referente a hora de criação da mensagem (5) incluída na mensagem (6) e com a técnica de detecção de repetições é possível fazer a autenticação.

Se o campo subchave (Subkey) da mensagem (6), que é opcional, não foi omitido, e o campo subchave da mensagem (5) também não foi omitido, então a subchave da mensagem (6) substituirá a subchave da mensagem (5). Já o campo opcional de número de sequência (Seq#) da mensagem (6) identifica o número de sequência inicial a ser usado pelo cliente.

• Flags dos tickets

Os flags nos tickets permitem expandir as funcionalidades referentes a esse tipo de credencial. Os flags dos tickets no Kerberos versão 5 são: INITIAL, PRE-AUTHENT, HW-AUTHENT, RENEWABLE, MAY-POSTDATE, POSTDATED, INVALID, PROXIABLE, FORWARDABLE e FORWARDED.

Na versão 4, não era previsto que o AS pudesse emitir tickets além do TGT, porém tal fato pode acontecer na versão 5. O flag INITIAL é utilizado para verificar se um determinado ticket foi emitido pelo AS e não pelo TGS. Quando um ticket é emitido pelo AS, é necessário que o usuário digite a sua senha, o que é uma vantagem para aplicações que necessitam garantir que a senha do usuário foi testada recentemente, aumentando assim a segurança do sistema em situações onde o usuário se afasta da sua estação de trabalho e alguém mal intencionado tente utilizar um serviço se passando pelo usuário “oficial” da estação de trabalho.

Para evitar que um usuário mal-intencionado peça um TGT referente a outro usuário e tente decriptografá-lo através de força bruta ou ataque de dicionário, na versão 5 é possível que o AS exija uma pré-autenticação do usuário antes de enviar o TGT. Se a pré-autenticação estiver ativada, quando um cliente solicita um TGT ao AS, o AS responde com uma mensagem de erro indicando a necessidade de pré-autenticação. Então o cliente reenvia o pedido adicionando um carimbo de tempo indicando a hora da criação da solicitação e criptografando a mensagem com a chave do usuário. Se o AS conseguir decriptografar o pedido com a chave do usuário e o tempo carimbado estiver dentro do prazo estipulado, o AS assume que a requisição é legítima e envia o TGT ao cliente.

Quando o flag PRE-AUTHENT é marcado, existe então uma indicação de que quando o AS recebeu a solicitação do TGT, ele pré-autenticou o cliente antes de emitir o TGT. Quando o flag HW-AUTHENT é marcado, existe uma indicação de que o protocolo utilizado para ser feita essa pré-autenticação exige a utilização de hardware que deve ser de posse apenas do cliente.

Na versão 5, existe a proposta de se utilizar tickets renováveis, onde tickets com o flag RENEWABLE marcado possuem dois tempos de expiração: um para esse ticket específico e outro é o último valor permitido para um tempo de expiração. Desse modo, um cliente pode obter a renovação de um ticket apresentando-o ao TGS com uma solicitação de um novo tempo de expiração. Caso esse novo tempo seja menor ou igual ao valor máximo permitido, então o TGS pode emitir um novo ticket com um novo tempo de expiração específico para o ticket e um novo tempo de expiração.

Um cliente pode solicitar um TGT ao AS com o flag MAY-POSTDATE marcado, indicando assim que esse ticket poderá ser utilizado para solicitar um ticket pós-datado. O flag POSTDATED marcado indica que o ticket foi pós-datado. Já o flag INVALID indica que o ticket é inválido e necessita ser validado pelo KDC antes de ser utilizado.

Na versão 5, é permitido que um servidor possua as credenciais e os privilégios de um cliente, podendo assim solicitar um serviço de outro servidor em nome do cliente. Para se utilizar essa funcionalidade, o cliente solicita um ticket com o flag PROXIABLE marcado. Quando esse ticket for enviado ao TGS, o TGS poderá emitir um ticket com o flag PROXY marcado e com um endereço de rede diferente do cliente solicitante.

Caso um ticket tenha o flag FORWARDABLE marcado, um TGS pode emitir um TGT com o flag FORWARDED e com um endereço de rede diferente do endereço de rede do solicitante. Esse flag constitui a base para que um cliente possa acessar um servidor pertencente a um domínio remoto. Um modo de se construir uma rede de domínios eficiente e capaz de atender essa necessidade, é termos um sistema organizado hierarquicamente em forma de árvore, onde os nós seriam representações dos domínios e as arestas seriam representações do compartilhamento de chaves entre diferentes domínios.

Inicialmente, para simplificar as explicações, consideramos uma rede com três domínios: A, B e C. Nessa rede, o domínio A compartilha uma chave de sessão com B e C, porém B e C não compartilham uma chave de sessão entre si.

Para garantir a segurança, o Kerberos versão 5 introduz a seguinte propriedade: se o domínio B confia no domínio A, e o A confia no domínio C, então automaticamente B confia em C.

Figura 17. Estrutura em árvore de uma rede de domínios no Kerberos versão 5.



Nesta situação, quando um cliente pertencente ao domínio B quer solicitar um serviço pertencente ao domínio C, o cliente segue as seguintes instruções:

(1) Considerando que o cliente já possui o TGT de B, então ele solicita ao TGS de B o ticket do servidor do C.

(2) O TGS de B consegue o TGT de A pela técnica descrita em Solicitando serviço em outro domínio, e envia um ticket de referência ao cliente contendo o TGT do A. Esse ticket de referência é criptografado com a chave compartilhada entre A e B.

(3) O cliente recebe o ticket enviado em (2), e então envia esse ticket recebido ao TGS de A, solicitando o ticket do servidor do C.

(4) O TGS de A decriptografa o ticket recebido em (3), consegue o TGT de C, e envia um ticket de referência ao cliente contendo o TGT de C. Esse ticket de referência é criptografado com a chave de sessão entre o A e o C.

(5) O cliente envia o ticket recebido em (4) ao TGS do C solicitando o ticket para o servidor pertencente ao C.

Em uma rede de n domínios com o mesmo funcionamento especificado acima, existiriam n-1 chaves compartilhadas entre os TGS’s de diferentes domínios, possuindo assim uma ordem a menos se comparado ao mecanismo da versão 4, que era da ordem de n^2 chaves compartilhadas. Desse modo, para alcançar o servidor remoto existiria uma caminho de autenticação, que poderia ser decidido pelo próprio domínio onde o cliente se encontra, dado que ele teria acesso a estrutura do grafo da rede.

Como exemplo, temos a seguinte rede:

Figura 18. Cliente pertencente ao domínio E solicita serviço pertencente ao domínio G no Kerberos versão 5.



Na situação descrita na imagem acima, o caminho de autenticação seria: E, B, A, C, G.

Existem alguns modos de se aperfeiçoar essa estrutura hierárquica. Um deles é baseado na criação de novas arestas, chamadas de atalhos. Dessa maneira o grafo da rede de domínios perde a propriedade de árvore.

Figura 19. Cliente pertencente ao domínio E solicita serviço pertencente ao domínio G com presença de "atalho" no Kerberos versão 5.



Na situação descrita na imagem acima, o caminho de encaminhamento seria: E, B, C, G. O caminho assim seria menor do que o caminho encontrado na situação anterior.

A tabela abaixo descreve, sucintamente, as principais implementações do protocolo atualmente:

Esta seção mostra como usar o MIT Kerberos em um sistema Linux.

• Usuário:

  Se o programa de login no computador do usuário já estiver integrado com o Kerberos, ao fazer login ele automaticamente vai receber o ticket de concessão de ticket (TGT) do servidor de autenticação (AS) para poder acessar serviços protegidos pelo Kerberos. Caso contrário, o usuário terá que usar o comando kinit e digitar sua senha para obtê-lo. Enquanto seu TGT não expirar ou for destruído a troca de tickets entre o cliente, o servidor de concessão de ticket(TGS) e os servidores de aplicações ocorre de forma transparente e o usuário pode se autenticar e utilizar serviços “kerberizados” sem precisar redigitar sua senha. Quando não for mais usar o computador o usuário deve utilizar o comando kdestroy para destruir os tickets guardados na máquina. O usuário tem também a opção de mudar sua senha através do comando kpasswd.

  Figura 20.Utilizando rsh com Kerberos


• Administrador:

  Para que o MIT Kerberos funcione o administrador fica encarregado das seguintes tarefas:

  • Instalar o Key Distribution Center (KDC) e o Servidor de Administração (kadmin)

    Figura 21.Instalando KDC e kadmin através de um gerenciador de pacotes

  • Configurar o Kerberos através dos arquivos de configuração krb5.conf e kdc.conf ou de um assistente de configuração

    Figura 22.Configurando Keberos com um assistente de configuração
    Figura 23.Editando o arquivo kerb5.conf

  • Criar o banco de dados do KDC através do comando kdb5_util create ou krb5_newrealm(script específico para Debian que cria um Domínio)

    Figura 24.Criando um novo Domínio

  • Adicionar os administradores ao arquivo Acces Control List (ACL) para que tenham permissão para ver e modificar o base de dados do Kerberos.

    Figura 25. Editando arquivo kadm5.acl

  • Iniciar o Kerberos KDC e o servidor administrativo no KDC mestre.

  • Instalar e configurar os KDCs escravos. (opcional)

  • Garantir que a base de dados seja propagada para os KDCs escravos. (se existirem)

  • Criar políticas para senhas através do comando add_policy do programa kadmin. Podendo escolher o número de senha antigas guardadas no banco de dados, validade máxima e mínima da senha, o o número mínimo de caracteres e de classes de caracteres(minúsculas, números, pontuação...).

    Figura 26.Criando uma política para categoria "user" que exige uma senha de tamanho mínimo 10

  • Garantir que os computadores da rede estejam com os relógios sincronizados, já que os tickets têm validade.

  • Adicionar, modificar e deletar principals na base de dados

    Figura 27.Adicionando principal "hercules"

  • Gerar chaves secretas para as aplicações e adicioná-las nos seus servidores

    Figura 28.Adicionando chaves secretas para aplicações

O Kerberos tem algumas limitações e fraquezas:

• O usuário tem que confiar na sua máquina, fato que nem sempre é verdade em computadores públicos.

  Num computador em que vários usuários tenham acesso, um usuário mal-intencionado pode instalar um software para capturar a senha de outro usuário e dessa forma se passar por ele. Uma forma de resolver esse problema é através do uso de smartcards.

  Além disso, como os tickets ficam armazenados no computador do cliente, eles podem ser roubados se um usuário tiver acesso “root” ou acesso a uma máquina na qual algum usuário tenha esquecido-se de “deslogar”. Esses tickets e as chaves de sessão associadas a eles poderão ser utilizados enquanto não expirarem, por isso é importante escolher um tempo de vida para os tickets que não seja muito curto para que o usuário não tenha que redigitar a senha várias vezes e nem seja muito longo para que o tempo de vulnerabilidade seja menor no caso de roubo.

• Os relógios dos computadores têm que estar sincronizados, já que os tickets tem validade. Pessoas mal-intencionadas podem tentar alterar o relógio dos servidores para aumentar a validade de tickets roubados.

• Se um usuário escolher uma senha fraca, ela pode ser descoberta por um terceiro, através de força bruta ou ataque de dicionário. Para diminuir esse risco pode se adotar uma política de criação de senhas.

• É necessário que as aplicações sejam compatíveis com Kerberos, ou seja, se o programa original não suportar o Kerberos ele terá que ser modificado(“kerberizado”).

A lista abaixo, extraída da Wikipédia[2], ilustra alguns softwares que podem utilizar o Kerberos para autentição:

• Andrew File System (AFS)
• Apache (com o módulo mod_auth_kerb)
• Apache 2 (usando libapache-mod-auth-kerb)
• Postfix (usando GSSAPI)
• Roteadores e Switches Cisco utilizando IOS
• Coda File System
• Eudora
• Mac OS X
• Microsoft Windows (2000 e posteriores) utiliza como protocolo de autenticação padrão
• Mulberry, um cliente de e-mail desenvolvido por Cyrusoft, Inc.
• NFS (Desde NFSv3)
• OpenSSH (com Kerberos v5 ou posterior)
• Pluggable Authentication Modules (com o módulo pam_krb5)
• Samba (Desde v3.x)
• SOCKS (Desde SOCKS5)
• Netatalk
• As implementações X Window System
• Indiretamente, qualquer software que possa utilizar o SASL para autenticação, como o OpenLDAP, Dovecot IMAP4 e servidores POP3, Servidor de e-mail Postfix
• O suíte de aplicativos Kerberos já vem com os clientes e servidores habilitados para rsh, FTP, e Telnet
• Qualquer software baseado em Java (Desde 1.4.2) utilizando JAAS/JGSS pode utilizar o Kerberos para a sua segurança

Tendo conhecimento das vantagens e desvantagens do Kerberos, concluímos que ele permite uma autenticação robusta em um ambiente distribuído. Podemos considerar uma solução de segurança confiável por diversas razões.

Uma delas é que esse protocolo é maduro, visto que ele foi usado e estudado amplamente por um longo período de tempo. Isso é muito importante quando se trata de segurança. Outra razão é que, uma vez que ele foi desenvolvido em um ambiente aberto e com comunicações inseguras (similar ao ambiente da Internet), ele atende aos requisitos dos sistemas distribuídos modernos. Também podemos afirmar que é um protocolo sólido, com uma abstração simples, facilitando a integração com outros sistemas e a análise do comportamento do protocolo. Por último, dizemos que o Kerberos já tem seu espaço consolidado, pois está integrado nos principais sistemas operacionais e em uma vasta gama de programas.

• Por que os relógios dos computadores da rede têm que estar sincronizados?

  Porque os tickets e autenticadores do Kerberos tem validade para evitar que tickets roubados sejam usados posteriormente.

• O que é um Domínio?

  Um conjunto de principals gerenciados que compartilham o mesmo banco de dados Kerberos.

• O que caracteriza o Kerberos como um mecanismo de criptografia de chave simétrica?

  O fato das chaves serem compartilhadas entre duas ou mais entidades e elas serem usadas pra criptografar e decriptografar uma mensagem.

• Qual a vantagem e a desvantagem do tempo de validade do TGT ser curto?

  A desvantagem é que o usuário provavelmente vai ter que redigitar sua senha muitas vezes, facilitando que ela seja roubada. A vantagem é que caso ele seja roubado o tempo de ação de alguém mal-intencionado será menor.

• O fato do funcionamento do Kerberos ser de conhecimento público o torna mais inseguro?

  Não, pois quando se trata de segurança em redes um mecanismo é considerado confiável quando conhecido, usado, estudado amplamente e não é burlado de forma eficaz.

1. MIT Kerberos. Kerberos: The Network Authentication Protocol. Disponível em: http://web.mit.edu/kerberos/. Acesso em: 23 de mai. 2012.
2. Wikipédia. Kerberos. Disponível em: http://pt.wikipedia.org/wiki/Kerberos. Acesso em: 23 de mai. 2012.
3. Wikipedia. Kerberos (protocol). Disponível em: http://en.wikipedia.org/wiki/Kerberos_(protocol). Acesso em: 23 de mai. 2012.
4. Natalia Castro Fernandes. Kerberos. Disponível em: http://www.gta.ufrj.br/grad/04_1/kerberos/. Acesso em: 23 de mai. 2012.
5. Microsoft. How the Kerberos Version 5 Authentication Protocol Works. Disponível em: http://technet.microsoft.com/en-us/library/cc772815%28v=ws.10%29.aspx. Acesso em: 23 de mai. 2012.
6. Kerberos Consortium. Kerberos Protocol Tutorial. Disponível em: http://www.kerberos.org/software/tutorial.html. Acesso em: 23 de mai. 2012.
7. Kerberos Consortium. Why is Kerberos a credible security solution. Disponível em: http://www.kerberos.org/software/whykerberos.html. Acesso em: 23 de mai. 2012.
8. Cisco. Kerberos Overview - An Authentication Service for Open Network Systems. Disponível em: http://www.cisco.com/en/US/tech/tk59/technologies_white_paper09186a00800941b2.shtml. Acesso em: 23 de mai. 2012.
9. Stallings, W. (1945). Criptografia e Segurança de Redes: princípios e práticas. São Paulo: Prentice-Hall, 2008.
10. Neuman, B. C.; Ts'o, T. Kerberos: An Authentication Service for Computer Networks. IEEE Communications Magazine, Volume 32, Número 9, páginas 33-38, Setembro 1994.
11. Bellovin, S. M.; Merritt, M. Limitations of the Kerberos Authentication System. Proceedings of the Winter 1991, Usenix Conference, Janeiro 1991.