Kerberos Protocol

Introduo
Protocolo de Autenticao de Rede.
Desenvolvido para fornecer forte autenticao para aplicaes
cliente/servidor.

Criado pelo MIT durante o projeto Athena (1983).

Atualmente na verso 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 usurio nunca deve viajar atravs da rede.

A senha do usurio nunca deve ser armazenado na mquina do cliente: deve

ser descartado aps o uso.

A senha do usurio nunca deve ser armazenada de forma no criptografada,

mesmo no banco de dados do servidor de autenticao.

O usurio solicitado a digitar a senha uma nica vez por sesso de trabalho.
Usurios podem acessar de forma transparente todos os servios que esto
autorizados sem ter que redigitar a senha. Single Sign-On.

Autenticao mtua. No s os usurios tm de demonstrar que so quem

eles dizem, mas, quando solicitado, os servidores de aplicativos devem provar
a sua autenticidade para o cliente tambm.
Importante II
O gerenciamento da informao de autenticao centralizada e reside no
servidor de autenticao . Os servidores de aplicativos no devem conter as
informaes de autenticao para seus usurios. Com isso:

1. O administrador pode desativar a conta de qualquer usurio, agindo em um

nico local, sem ter que agir sobre os vrios servidores de aplicativos que
fornecem os vrios servios;

2. Quando o usurio muda sua senha, ela alterada para todos os servios ao
mesmo tempo;

3. No h redundncia de informaes de autenticao que de outra forma

deveria ser guardada em vrios lugares.
Descrio
Protocolo Needham-Schroeder
Baseado em algoritmo de chave simtrica.
Objetivo de estabelecer uma chave de sesso entre duas partes da rede.

Utilizao de KDC (Key-Distribution Center) dividido em duas partes:

Servidor de Autenticao (AS).
Servidor de Concesso de Ticket (TGS).

O KDC mantm 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 comunicao entre as entidades o KDC gera-se uma chave se sesso

temporria, para garantir a privacidade das informaes.
Funcionamento I
Funcionamento II

1. AS_REQ: request inicial de autenticao do usurio. Encaminhado ao

Servidor de Autenticao do KDC (AS).

2. AS_REP: respostas do AS para o request em (1). Contm o TGT (criptografado

usando a chave secreta TGS) e a chave de sesso (criptografada usando a
chave secreta do usurio solicitante).

3. TGS_REQ: request do cliente para o TGS para um bilhete de servio. Inclui o

TGT obtido a partir de (2) e um autenticador gerado pelo cliente
criptografado com a chave de sesso.
Funcionamento III
4. TGS_REP: resposta do TGS para (3). Inclui o ticket de servido solicitado
(criptografado com a chave do servio) e a chave de sesso do servio gerada
pelo TGS e criptografada usando a chave de sesso anterior gerada pelo AS.

5. AP_REQ: request que o cliente envia para um servidor de aplicativos para

acessar um servio. Inclui a permisso obtida a partir do TGS em (4) e um
autenticador novamente gerado pelo cliente, desta vez criptografado usando
a chave de sesso de servio (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 autenticao mtua necessria.
Authentication Server Request
(AS_REQ)
Fase em que o cliente solicita ao KDC (mais especificamente ao AS) por um TGT.
O request complemente no criptografado e parecido com o seguinte:

Principal: nome usado para se referir s entradas no banco de dados do servidor de

autenticao. Um Principal associado a cada usurio, host ou servio de um determinado
domnio.

PrincipalClient: entrada associada com a busca de autenticao do usurio (por exemplo:

user@domain.com).

PrincipalService: entrada associada com o servio do bilhete que est sendo solicitado (por
exemplo: krbtgt/REALM@REALM).

IP_list: Lista de IPs onde se pode utilizar o bilhete que ser emitido (servidores).

Lifetime: tempo de validade mximo solicitado para o uso do bilhete.

Authentication Server Request
(AS_REQ)

KDC

Cliente
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
no existe uma mensagem de erro retornada ao cliente, caso contrrio o AS
procede da seguinte maneira:

Cria-se chave de sesso randomicamente que ser compartilhada em segredo entre o

cliente e o TGS. Chamada SKtgs.

Cria-se um TGT contendo os dados do usurio, os dados do servio, a lista de endereos

de IP, data e hora (do KDC) no formato timestamp, o lifetime e por ltimo a chave de
sesso 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 servio (Ktgs), os dados do servio, o timestamp, o lifetime e a
chave de sesso, todos criptografados com a chave secreta do servio solicitado pelo
usurio (Kuser). Em resumo tm-se:

Uma vez que a informao presente no TGT criptografada utilizando a chave secreta
para o servidor, ela no pode ser lida pelo cliente e precisa ser repetida. Neste ponto,
quando o cliente recebe a mensagem de resposta, ser solicitado ao usurio digitar a
senha. O dado do usurio concatenado com a senha e, em seguida, a funo
string2key aplicada: com a chave resultante feita uma tentativa para decodificar a
parte da mensagem criptografada pelo KDC usando a chave secreta do usurio
armazenada na base de dados. Se o usurio realmente quem diz e se digitou a senha
correta, a operao de decriptao ser bem-sucedida e, portanto, a chave de sesso
pode ser extrada, o TGT (que permanecer criptografado) armazenado em cache de
credenciais do usurio.
Authentication Server Request
(AS_REQ)

KDC

Cliente
Ticket Granting Server Request
(TGS_REQ)
Aps o usurio obter o TGT e a chave de sesso e deseja acessar o servio, mas
ainda no possui o ticket de servio, envia-se um pedido (TGS_REQ) para o TGS
da seguinte maneira:

Cria-se um Autenticador com o Principal do cliente, o timestamp da mquina cliente, e

criptografa tudo com a SKtgs obtida.

Cria-se um pacote (request) contendo: o Principal do servio para qual o ticket

necessrio e o lifetime no criptografados e o autenticador; o TGT que j est
criptografado com a chave do TGS.
Authentication Server Request
(AS_REQ)

KDC

Cliente
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 requisio aberta usando a chave para o Principal
extraindo a chave de sesso (SKtgs) que usada para descriptografar o
Autenticador. Para emitir o ticket do servio solicitado verificam-se algumas
condies:

O TGT no expirou;

O PrincipalClient apresentado no Autenticador corresponde com o apresentado no TGT;

O autenticador no est presente no cache de replay e no tenha expirou;

Se o IP_list no nulo, verifica-se se o endereo de IP de origem no pacote do request

(TGS_REQ) um dos previstos na lista;
Ticket Granting Server Replay
(TGS_REP) II
A verificao das condies anteriores garantem que o TGT realmente pertence
ao usurio 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 servio (Skservice).
criado o ticket do servio contendo:

A resposta enviada contendo: o ticket criado, criptografado usando a chave

secreta do servio (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)

KDC

Cliente
Application Request (AP_REQ) I
O cliente, tendo as credenciais para acessar o servio (o ticket e as chaves
mencionadas), pode pedir ao servidor de aplicaes para acessar o recurso via
uma mensagem AP_REQ. Essa mensagem no padronizada, varia de acordo
com a aplicao solicitada, definida pelo programador da aplicao que define
a estratgia 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)

KDC

Cliente

App Server
Application Request (AP_REQ) II
Quando a mensagem chega, o servidor da aplicao abre o ticket, usando a
Kservice, e extrai a chave SKservice, que usada para descriptografar o
autenticador. Para estabelecer que a requisio do usurio est autenticada e
garantir o acesso ao servio, o servidor verifica as seguintes condies:

O ticket no expirou;

O PrincipalClient apresentado no autenticador corresponde ao apresentado no ticket;

Se o IP_list (extrado do ticket) no nulo, verifica-se que o endereo IP de origem do

pacote do request (AP_REQ) um dos contidos na lista.

Nota: Essa estratgia muito similar a utilizada pelo TGS para checar a
autenticidade da requisio do cliente ao solicitar um ticket para um servio. TGS
pode ser considerado como um servidor de aplicativos cujo servio fornecer
tickets para aqueles que provam sua identidade com um TGT.
Principais Vantagens
Proteo por senha: As senhas dos usurios no precisam ser enviadas atravs da
rede.

Autenticao Cliente/Servidor: A comunicao interrompida se caso cada lado

no conseguir autenticar a contrapartida.

Durabilidade e Reutilizao: possvel manter-se autenticado atravs do

protocolo Kerberos, sem ter que re-introduzir um nome de usurio e senha
atravs da rede (at expirar da autenticao).

Ubiquidade: tornou-se to amplamente utilizado e confivel pelos melhores

desenvolvedores, especialistas em segurana e cryptologistas, que quaisquer
novas fraquezas ou violaes so susceptveis de ser identificadas e superadas
imediatamente.
Principais Desvantagens
Kerberos presume que cada usurio confivel e est usando uma mquina
no confivel em uma rede no confivel. No entanto, se algum alm do
usurio legtimo tiver acesso mquina que emite tickets usados para
autenticao o sistema de autenticao 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 so considerados kerberizados. Para alguns
aplicativos, isto pode ser bastante problemtico outros so incompatveis.
Aplicativos de cdigo fechado que no tm suporte ao Kerberos por padro
so geralmente os mais problemticos.

Para se utilizar o Kerberos, necessrio tomar algumas decises sobre

algumas questes cruciais, para as quais uma escolha errada pode
comprometer a segurana de todo o sistema. Por exemplo, tempo de durao
de um ticket, a escolha de quais proxies devem ser autorizados, e como
garantir a integridade fsica de algumas mquinas, como os servidores de
autenticao.
Referncias
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