Kerberos

Interações da rede Kerberos

Kerberos é um Protocolo de rede, que permite comunicações individuais seguras e identificadas, em uma rede insegura. Para isso o Massachusetts Institute of Technology (MIT) disponibiliza um pacote de aplicativos que implementam esse protocolo. O protocolo Kerberos previne Eavesdropping e Replay attack, e ainda garante a integridade dos dados. Seus projetistas inicialmente o modelaram na arquitetura cliente-servidor, e é possível a autenticação mutua entre o cliente e o servidor, permitindo assim que ambos se autentiquem.

Kerberos utiliza Criptografia simétrica e necessita de um sistema de confiança tripla.

História e Desenvolvimento

Kerberos é um protocolo de autenticação do Projeto Athena. Tem esse nome em alusão ao Cão guarda de três cabeças (Cérbero) do deus Hades da Mitologia grega. Diversas versões do protocolo já existiram, as versões 1 até a 3 foram utilizadas somente dentro da MIT. Steve Miller e Clifford Neuman, foram os principais projetistas da versão 4 do Kerberos, publicada nos anos 80, ainda com foco no Projeto Athena.

A versão 5 foi projetada por John Kohl e Clifford Neuman e publicada em 1993 no RFC 1510 (Ficou obsoleto ao RFC 4120 de 2005), e teve como intenção melhorar a segurança e as limitações relativas a versão 4.

A MIT disponibilizou uma implementação livre sob licença BSD.

Autoridades Norte-americanas/Estadundenses proibiram o uso do Kerberos, pois esse utiliza um algoritmo de criptografia com uma chave de 56-bit, chamado DES. Eles consideraram que o protocolo prejudica a segurança nacional, porque impede que mensagens interceptadas sejam entendidas (Assim como qualquer aplicativo que utilize criptografia com chave maior que 40-bit). Uma implementação não americana do Kerberos, KTH-KRB foi desenvolvida pela Royal Institute of Technology na Suécia, tornando assim o sistema disponível fora dos EUA, até a mudança da regulamentação de exportação de criptografias. A implementação Sueca é baseada em uma versão chamada eBones. eBones é baseado em um release da versão eBones da MIT (Retirado a criptografia e as chamadas a mesma) que por sua vez foi baseado na versão 4 do Kerberos atualização 9. Esse Kerberos limitado é chamado hoje como eBones. Uma implementação chamada Heimdal, foi feita basicamente, pelo mesmo grupo de pessoas e é baseada na versão 5 do Kerberos.

Windows 2000, Windows XP e o Windows Server 2003 utilizam uma variante do Kerberos, como seu método de autenticação padrão. As adições feitas no conjunto de protocolos do Kerberos pela Microsoft são documentadas no RFC 3244 chamado “Microsoft Windows 2000 Kerberos change Password and Set Password Protocols”. O Mac OS X da Apple também usa o Kerberos, tanto o cliente como o servidor.

Em 2005, o grupo chamado IETF “IETF Kerberos Workgroup” atualizou as especificações Kerberos. As atualizações incluem:

• "Encryption and Checksum Specifications" (RFC 3961),
• "Advanced Encryption Standard (AES) Encryption for Kerberos 5" (RFC 3962),
• Uma nova edição da especificação do Kerberos versão 5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Essa versão substitui o RFC 1510, tornando a especificação do protocolo mais transparente e o explicando de modo mais detalhado e limpo.
• Uma nova edição de especificação do GSS-API "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2." (RFC 4121).

Descrição

O Kerberos utiliza basicamente o protocolo Needham-Schroeder. O sistema de confiança tripla é chamado de Centro de Distribuição de Chaves (CDC), que é composta por duas partes separadas: um Servidor de Autenticação (SA) e Servidor de Concessão de Ticket (SCT). O Kerberos trabalha baseado em Tickets, que identificam os usuários.

O CDC mantém um banco de dados de chaves secretas; toda entidade de rede – tanto clientes como servidores – compartilham uma chave secreta que é apenas conhecido por eles mesmos e pelo CDC. O conhecimento da chave secreta pelo CDC é necessário para a identificação das entidades de rede. Para a comunicação entre as entidades o CDC gera uma chave de sessão temporária, que serve para garantir a privacidade das informações.

Utilizadores

Os seguintes softwares podem utilizar Kerberos para a autenticação:

• 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 maior)
• PAM (com o módulo pam_krb5)
• Samba Desde v3.x
• SOCKS (Desde SOCKS5)
• Netatalk
• FreeIPA
• As implementações X Window System
• Indire(c)tamente, 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, veja http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/single-signon.html

O Protocolo

Qualquer um pode especificar o protocolo utilizando a notação de protocolo de segurança, onde Alice (A) se autentica com Bob (B) utilizando um servidor S. Onde:

• K_AS é uma chave pré-estabelecida somente conhecida por A e S;
• Como também K_BS é somente conhecido por B e S;
• K_AB é uma chave de sessão entre A e B, gerada a cada vez que o protocolo é utilizado;
• T_S e T_A são marcas temporais geradas por S e por A, respectivamente;
• L é um 'lifespan' definindo o tempo de vida da marca temporal.

$A\rightarrow S:A,B$

A pede para S iniciar um conexão com B.

$S\rightarrow A:\{T_{S},L,K_{AB},B,\{T_{S},L,K_{AB},A\}_{K_{BS}}\}_{K_{AS}}$

S gera uma chave K_AB e envia para A junto com a marca temporal e com os dados encriptados por B.

$A\rightarrow B:\{T_{S},L,K_{AB},A\}_{K_{BS}},\{A,T_{A}\}_{K_{AB}}$

A passa a mensagem para o B, obtém um novo TA e passa utilizando a chave de sessão.

$B\rightarrow A:\{T_{A}+1\}_{K_{AB}}$

B confirma a recepção da chave de sessão retornando uma versão modificada da marca temporal do A.

Percebemos que a segurança do protocolo se baseia em marcas temporais T e “lifespans” L como indicadores de quão recente é a comunicação. E em relação à operação do Kerberos, é importante salientar que o servidor S é utilizado por ambos como o Servidor de Autenticação (SA), e como Servidor de Concessão de Ticket (SCT). Sendo $\{T_{S},L,K_{AB},B,\{T_{S},L,K_{AB},A\}_{K_{BS}}\}_{K_{AS}}$, $\{T_{S},L,K_{AB},A\}_{K_{BS}}$ é o Ticket do cliente para o servidor, $\{A,T_{A}\}_{K_{AB}}$ é o autenticador, e $\{T_{A}+1\}_{K_{AB}}$ confirma a veracidade da identificação de B e se o mesmo é reconhecido por A. Isso é necessário para uma autenticação mutua.

Funcionamento do Kerberos

A seguir, é descrito fluxo simplificado do funcionamento do protocolo.

As seguintes nomenclaturas serão usadas:

• SA = Servidor de Autenticação
• SCT = Servidor de Concessão de Ticket
• SS = Servidor de Serviço
• cliente = Aplicação cliente do kerberos no sistema

Em uma sentença: o cliente se autentica no SA, então demonstra para o SCT que está autorizado a receber um Ticket para utilizar em um serviço (e o recebe), então demonstra ao SS que ele está aprovado para receber um serviço.

Em mais detalhes:

1. O usuário coloca o nome de usuário e a senha no cliente.
2. O cliente aplica uma criptografia de via única (ou hash) na senha digitada, e isso se torna a chave secreta do cliente.
3. O cliente envia uma solicitação de serviço, através de uma mensagem em texto-plano, ao SA. Exemplo de mensagem: “O usuário XYZ gostaria de receber um serviço”. Nota: Nem a chave secreta, nem a senha são enviadas ao SA.
4. O SA verifica se o cliente está em sua base de dados. Se estiver, ele manda as seguintes duas mensagens ao cliente:
   1. Mensagem A: Chave de sessão Cliente/SCT criptografada usando a chave secreta do usuário.
   2. Mensagem B: Ticket de Concessão (Que inclui a ID do cliente, endereço de rede do cliente, validade do ticket e a Chave de sessão Cliente/SCT) criptografado utilizando a chave secreta do SCT.
5. Somente após o cliente receber a mensagem A e B, ele descriptografa a mensagem A e obtém a Chave de sessão Cliente/SCT. Essa chave de sessão será utilizada em comunicações futuras com o SCT. (Nota: O cliente não consegue descriptografar a mensagem B, pois essa é criptografada utilizando a chave secreta do SCT). A partir desse momento, o cliente tem informações o suficiente para se autenticar no SCT.
6. Após requisitar o serviço, o cliente envia as seguintes duas mensagens ao SCT:
   1. Mensagem C: Mensagem B e o ID do serviço requisitado.
   2. Mensagem D: O Autenticador (que é composto do ID do cliente e a marca temporal), criptografado utilizando a Chave de sessão Cliente/SCT.
7. Após receber as mensagens C e D, o SCT descriptografa a mensagem B com sua chave secreta e a mensagem D (O Autenticador) utilizando a Chave de sessão Cliente/SCT da mensagem B, verifica se os dados das mensagens conferem com os dados de quem enviou os pacotes e, caso esteja tudo certo, envia as seguintes duas mensagens ao cliente:
   1. Mensagem E: Ticket Cliente-para-Servidor (que inclui o ID do cliente, endereço de rede do cliente, período válido, e uma chave de sessão Cliente/Servidor) criptografado utilizando a chave secreta do serviço.
   2. Mensagem F: Chave de sessão Cliente/Servidor criptografado utilizando a chave de sessão Cliente/SCT.
8. Após receber as mensagens E e F do SCT, o cliente tem informações suficiente para se autenticar no SS (Nota: O cliente não consegue descriptografar a mensagem E, pois essa é criptografada utilizando a chave secreta do SS). Assim, o cliente se conecta no SS e envia as seguintes mensagens:
   1. Mensagem E do passo anterior (o Ticket Cliente-para-servidor, criptografado utilizando a chave secreta do serviço) .
   2. Mensagem G: Um novo Autenticador, que inclui o ID do cliente, uma marca temporal, criptografados com chave de sessão Cliente/Servidor
9. Após receber as mensagens, SS descriptografa a mensagem E e, com o Ticket Cliente-para-Servidor que estava nesta, descriptografa a mensagem G. Novamente os dados das mensagens são comparados com os dados de quem as envia e, caso esteja tudo certo, uma mensagem de confirmação, codificada com a Chave de sessão Cliente/Servidor, é enviada ao cliente contendo a marca temporal recebida na mensagem G incrementada em uma unidade.
10. O cliente descriptografa a confirmação utilizando a chave compartilhada com o servidor e verifica se a marca temporal está atualizado corretamente. Se tiver, o cliente pode confiar no servidor e começa a pedir serviços ao mesmo.
11. O Servidor retorna os serviços solicitados pelo cliente.

Limitações do Kerberos

Ponto de falha único: É necessária uma disponibilidade contínua do servidor central. Quando o servidor do Kerberos está indisponível, ninguém pode mais se autenticar na rede. Isso pode ser resolvido utilizando diversos servidores Kerberos.

O Kerberos necessita que os relógios internos dos clientes estejam sincronizados com o dele. Os Tickets têm um tempo de vida, e se o relógio do cliente não estiver sincronizado com o do servidor, a autenticação irá falhar. Na configuração padrão, é necessário que os relógios dos clientes não tenham uma diferença maior do que 10 minutos. Na prática, servidores NTP são utilizados para manter os relógios do servidor e dos clientes sincronizados.