Kerberos MIT

Como funciona:

O Kerberos foi desenvolvido a pensar em autenticação e não em autorização.  Podemos comparar o Kerberos a uma espécie de serviço supremo que nos diz: “sim, podes confiar em mim e esta pessoa é quem ela diz que é”.

Kerberos só trabalha a parte da autenticação. Não faz autorização (conceder ou negar acesso a serviços baseados no desejo de o utilizador usá-los) e também não trata a parte de gestão de contas, ou seja, não guarda nenhuma informação relacionada com UIDs, GIDs, home paths.

Sendo Kerberos um protocolo, têm várias implementações, desenvolvidas para vários propósitos:

• Kerberos MIT: O original. Devido a restrições de exportação da tecnologia de encriptação, foi desenvolvido na Europa o Kerberos Heimdal
• Kerberos Heimdal:  A versão Suiça do Kerberos. É compatível com o Kerberos MIT. As restrições do Kerberos MIT foram levantadas em 2000 de forma que ambas as implementações coexistem em larga escala.
• Active Directory:  Não é propriamente uma implementação do Kerberos. É um diretório Microsoft com uma implementação Kerberos e mais alguns serviços associados (LDAP). Não é directamente compatível com o Kerberos MIT ou Heimdal.
• TrustBroker: Uma implementação comercial do protocolo Kerberos, desenvolvida pela CyberSafe. Suporta uma série de sistemas operativos (Windows, Linux, Unix,…) e oferece interoperabilidade com outras implementações.
• Shishi: Uma implementação do Kerberos 5 para GNU.

Feita a introdução, vamos avançar para os detalhes de funcionamento. Vamos só falar em Kerberos V5.

Ticket Exchange Service:

A comunicação no Kerberos é construída à volta do protocolo Needham-Shroeder  (NS protocol), desenhado de forma a providenciar um serviço de autenticação seguro e distribuído, através da criptografia de uma chave secreta.

Todas as chaves são secretas, partilhadas pelas extremidades de uma ligação Kerberos. Difere dos sistemas assimétricos onde existe uma chave pública que toda a gente sabe e uma chave privada que permanece num servidor.

Para um utilizador, a chave secreta é a sua password em hash(a password é convertida numa string utilizando uma função de um caminho hash [one way hash function], string essa que passa a ser utilizada como chave), normalmente guardada no Key Distribution Center (KDC).

Para um serviço, a chave é uma sequência gerada aleatoriamente que também é guardada no KDC e num ficheiro chamado keytab na máquina onde se encontra o serviço.

De forma a que este sistema funcione, os clientes e os serviços têm ambos de confiar num terceiro serviço externo, o servidor Kerberos, que seja capaz de providenciar as chaves a pedido.

A comunicação Kerberos é construída à volta de tickets . Os tickets são uma esquema de dados encriptados transmitidos pela rede e guardados no lado do cliente (a forma como são guardados depende do sistema operativo do cliente e de outras configurações). Tradicionalmente, são guardados num ficheiro em /tmp.

A parte central de uma rede baseada no protocolo Kerberos é o Key Distribution Center (KDC). Consiste em três partes:

• Um Authentication Server que responde a pedidos de autenticação por parte dos clientes. Aqui estamos na fase de AS_REQUEST e AS_REPLY, onde o cliente recebe um Ticket Granting Ticket (TGT)
• Um Ticket Granting Server, que emite Ticket Granting Service (TGS) para um cliente. Esta é a fase TGS_REQUEST e TGS_REPLY onde o cliente recebe um TGS que vai permiti-lo autenticar-se junto de um serviço acessível na rede.
• Uma base de dados que guarda todas as chaves secretas (dos clientes e dos serviços) e mais alguma informação relacionada com as contas Kerberos (datas de criação, políticas…)

Normalmente o KDC é uma máquina dedicada apenas a servir serviços Kerberos (por questões de segurança).

As contas Kerberos chamam-se principals (é o equivalente a um username nas contas Unix).

O sistema de criptografia Kerberos é DES e suas variantes como o 3DES

Mecanismo de autenticação – Ticket Granting Tickets :

O mecanismo de autenticação é o primeiro passo a ser executado num ambiente Kerberos. Ele providencia o utilizador com um Ticket Granting Ticket (TGT) que serve de pós- autenticação  para mais tarde aceder a serviços específicos, Single Sign On.

-> Pré-Autenticação

Este método veio colmatar uma falha de segurança no Kerberos 4 e no fundo, este passo implica que o cliente primeiro que tudo tem de se identificar junto do KDC antes de obter um TGT.

-> 1º passo: Authentication Service Request – AS_REQUEST

Esta é a primeira mensagem enviada ao KDC. Contém:

• O principal nome do cliente
• O principal Ticket Granting Server (chamado “krbtgt principal”) que vai ser necessário mais tarde para obter o TGS.
• O timestamp do cliente
• O tempo de vida do ticket pedido (normalmente entre 8 a 10 horas)

O KDC recebe esta mensagem, verifica se o principal do cliente existe na sua base de dados e, se o timestamp entre a máquina do cliente e do KDC estiver próximo (tipicamente entre 3 a 5 minutos). Esta verificação do timestamp é somente para avisar o cliente, caso haja alguma de-sincronização temporal, antes de avançarem mais no processo de autenticação.

Se a pré-autenticação for obrigatória, o KDC não retorna um TGT. Em vez disso ele envia uma mensagem NEEDED_PREAUTH e pede ao cliente para enviar alguns dados pré-autenticação antes de entregar o TGT. Tradicionalmente o método usado é o PA-ENC-TIMESTAMP, onde o timestamp corrente é encriptado usando a chave do utilizador. conhecida no lado do cliente através da password.

Neste caso, o cliente reenvia uma mensagem AS_REQUEST mas desta vez incluindo o timestamp encriptado. Se a pré-autenticação for bem sucedida, o KDC retorna um TGT. Este é o passo AS_REPLY.

-> 2º passo: Authentication Service Reply – AS_REPLY

Após verificação, o Authentication Server gera uma chave de sessão aleatória (“short term” key). O KDC faz duas cópias: uma é para o cliente e é adicionada à mensagem AS_REPLY; a segunda cópia fica disponível no Ticket Granting Server. Esta última chave é para ser usada em negociações posteriores para outros tickets relacionados com serviços kerberizados.

Então, partindo do princípio que o cliente é autenticado com sucesso, o KDC envia uma mensagem AS_REPLY contendo o Ticket Granting Ticket. Será guardado numa espécie de cache de credenciais para ser usado mais tarde. A mensagem é encriptada com a chave do utilizador.

A mensagem AS_REPLY é formada por duas camadas: a primeira é encriptada com a chave do cliente enquanto que a segunda camada é o próprio TGT, primeiro encriptado com a chave do Ticket Granting Server  e depois reencriptado com a chave do utilizador. Desta forma só o utilizador autenticado é que vai conseguir desencriptar a mensagem para obter o TGT.

O conteúdo da mensagem AS_REPLY é o seguinte:

• encriptado com a chave do utilizador
• uma cópia da chave da sessão para o utilizador
• o tempo de duração do ticket
• o nome principal do krbtgt
• primeiro encriptado com a chave do Ticket Granting Server e depois com a chave do utilizador.Este é o TGT
• uma cópia da chave de sessão
• o tempo de vida do ticket
• o timestamp do KDC
• o principal do cliente
• o endereço IP do cliente

NOTA: apesar do TGT ser desencriptado e colocado na cache no lado do cliente, o seu conteúdo não pode ser lido no lado do cliente porque o mesmo está encriptado com a chave do Ticket Granting Server que só é conhecida pelo Ticket Granting Server.

Resumindo, podemos representar o mecanismo de autenticação desta forma:

Mecanismo do Serviço – Ticket Granting Service

Partindo do princípio que o cliente já passou pelo mecanismo de autenticação e já tem o Ticket Granting Ticket (TGT), o que ele quer agora é pedir acesso a um determinado serviço que está kerberizado na rede (pode ser um web server, um file sharing…). Para alcançar este objetivo, o cliente vai pedir um Ticket Granting Service (TGS).

Mais uma vez este pedido é dividido em dois passos: o TGS_REQUEST e o TGS_REPLY. Ambas as mensagens estão encriptadas por motivos de segurança.

-> 1º passo: Ticket Granting Service Request – TGS_REQUEST

Quando um utilizador quer aceder a um serviço kerberizado, primeiro tem de se identificar junto dele. Este pré requisito necessita de uma ligação separada ao Ticket Granting Server: o TGS_REQUEST.

A mensagem enviada pelo cliente é composta por vários elementos:

• o próprio pedido do TGS, contendo o serviço principal e o tempo de vida pedido.
• o TGT adquirido anteriormente (após uma autenticação bem sucedida)
• um autenticador

O autenticador é a mensagem ecnriptada com a chave de sessão adquirida durante o processo AS e contém o principal do utilizador e um timestamp. Assim, o KDC assegura que esta mensagem única vem da pessoa certa: primeiro verificando a chave temporária de sessão negociada anteriormente e segundo através do timestamp que detecta respostas fraudulentas. O objectivo do autenticador é frustar respostas.

Após um pedido válido (um TGT válido e um autenticador correcto), o Ticket Granting Server vai retornar o TGS.

-> 2º passo: Ticket Granting Service Reply – TGS_REPLY

Neste passo, o servidor vai gerar um novo conjunto de chaves de sessão.

A mensagem de resposta do servidor está encriptada com a chave de sessão adquirida através do processo AS, de forma que só o cliente que efetivamente se tinha autenticado anteriormente no KDC é que vai conseguir ler o seu conteúdo e extrair o TGS guardado.

A mensagem forma o TGS_REPLY e contém

• encriptada com a chave de sessão adquirida durante o processo AS:
• cópia de uma nova chave de sessão para o utilizador
• tempo de vida efetivo do ticket
• nome do serviço principal
• primeiro encriptado com a chave do serviço de longo termo, depois com a chave de sessão actual. Isto é o TGS:
• cópia de uma nova chave de sessão, para o serviço
• tempo de vida efetivo do bilhete
• KDC timestamp
• principal do cliente
• endereço IP do cliente

-> 3º passo: Contactar o serviço

Assim que o cliente tiver obtido o seu TGS, irá usá-lo para se autenticar diretamente junto do serviço requisitado. Este passo depende muito do tipo de serviço que pediu ajuda ao Kerberos de forma que não dá para detalhar muito.

O serviço tem acesso ao seu keytab, um ficheiro que guarda a sua chave de longo termo. Esta chave é que vai permitir ao serviço desencriptar o TGS enviado pelo cliente e obter todas as informações necessárias para criar um contexto de segurança

Esquematicamente,

Conclusão:

Podemos dividir o protocolo Kerberos em três passos fundamentais:

1. Processo de autenticação onde o utilizador (e anfitrião) obtém um Ticket Granting Ticket (TGT) como um token de autenticação.
2. Processo de requisito de um serviço, onde o utilizador obtém um Ticket Granting Service (TGS) para aceder ao serviço.
3. Acesso ao serviço, onde o utilizador (e anfitrião) utilizam o TGS para se autenticarem e acederem a determinado serviço.

---