Kerberos (protocolo)

Kerberos () é um protocolo de autenticação de rede de computador que funciona com base em tíquetes para permitir que os nós que se comunicam em uma rede não segura provem sua identidade para um outro de forma segura. Seus projetistas visaram principalmente um modelo cliente-servidor e fornecem autenticação mútua - tanto o usuário quanto o servidor verificam a identidade um do outro. As mensagens do protocolo Kerberos são protegidas contra espionagem e ataques de repetição.

O Kerberos baseia-se na criptografia de chave simétrica e requer um terceiro confiável e, opcionalmente, pode usar criptografia de chave pública durante certas fases de autenticação. O Kerberos usa a porta UDP 88 por padrão.

O protocolo recebeu o nome do personagem Kerberos (ou Cerberus) da mitologia grega, o feroz cão de guarda de três cabeças de Hades.

História e desenvolvimento

Massachusetts Institute of Technology (MIT) desenvolveu o Kerberos em 1988 para proteger os serviços de rede fornecidos pelo Projeto Athena. O protocolo é baseado no protocolo de chave simétrica Needham-Schroeder anterior. Existem várias versões do protocolo; as versões 1–3 ocorreram apenas internamente no MIT.

O Kerberos versão 4 foi projetado principalmente por Steve Miller e Clifford Neuman. Publicado no final dos anos 1980, a versão 4 também foi direcionada ao Projeto Athena.

Neuman e John Kohl publicaram a versão 5 em 1993 com a intenção de superar limitações existentes e problemas de segurança. A versão 5 apareceu como RFC 1510, que foi tornada obsoleta pela RFC 4120 em 2005.

As autoridades dos Estados Unidos classificaram o Kerberos como "Equipamento militar auxiliar" na Lista de Munições dos EUA e baniu sua exportação porque usou o algoritmo de criptografia Data Encryption Standard (DES) (com chaves de 56 bits). Uma implementação Kerberos 4 desenvolvida no Royal Institute of Technology na Suécia chamada KTH-KRB (renomeada para Heimdal na versão 5) disponibilizou o sistema fora dos EUA antes que os EUA mudassem seus regulamentos de exportação de criptografia (por volta de 2000). A implementação sueca foi baseada em uma versão limitada chamada eBones. O eBones foi baseado na versão exportada do MIT Bones (sem as funções de criptografia e as chamadas para elas) com base na versão Kerberos 4 patch-level 9.

Em 2005, o grupo de trabalho Kerberos da Internet Engineering Task Force (IETF) atualizou as especificações. Atualizações incluídas:

• Criptografia e Checksum Especificações (RFC 3961).
• Criptografia avançada padrão (AES) Criptografia para Kerberos 5 (RFC 3962).
• Uma nova edição da especificação Kerberos V5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Esta versão obsoleta o RFC 1510, esclarece aspectos do protocolo e destina-se a usar em uma explicação mais detalhada e mais clara.
• Uma nova edição da especificação de Interface de Programa de Aplicação de Serviços de Segurança Genéricos (GSS-API) "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mecanismo: Versão 2" (RFC 4121).

O MIT disponibiliza uma implementação do Kerberos gratuitamente, sob permissões de direitos autorais semelhantes às usadas para o BSD. Em 2007, o MIT formou o Kerberos Consortium para promover o desenvolvimento contínuo. Os patrocinadores fundadores incluem fornecedores como Oracle, Apple Inc., Google, Microsoft, Centrify Corporation e TeamF1 Inc..

Microsoft Windows

O Windows 2000 e versões posteriores usam Kerberos como método de autenticação padrão. Algumas adições da Microsoft ao conjunto de protocolos Kerberos estão documentadas no RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". RFC 4757 documenta o uso da cifra RC4 pela Microsoft. Enquanto a Microsoft usa e estende o protocolo Kerberos, ela não usa o software MIT.

Kerberos é usado como o método de autenticação preferencial: em geral, juntar um cliente a um domínio do Windows significa ativar o Kerberos como o protocolo padrão para autenticações desse cliente para serviços no domínio do Windows e todos os domínios com relações de confiança para esse domínio.

Por outro lado, quando o cliente, o servidor ou ambos não estão associados a um domínio (ou não fazem parte do mesmo ambiente de domínio confiável), o Windows usará o NTLM para autenticação entre o cliente e o servidor.

Os aplicativos da web da Internet podem aplicar o Kerberos como um método de autenticação para clientes ingressados no domínio usando APIs fornecidas pelo SSPI.

Microsoft Windows e Windows Server incluem setspn, um utilitário de linha de comando que pode ser usado para ler, modificar ou excluir os nomes principais de serviço (SPN) para um Active Directory conta de serviço.

Unix e outros sistemas operacionais

Muitos sistemas operacionais semelhantes ao Unix, incluindo FreeBSD, OpenBSD, macOS da Apple, Red Hat Enterprise Linux, Solaris da Oracle, AIX da IBM, HP-UX e outros, incluem software para Autenticação Kerberos de usuários ou serviços. Uma variedade de sistemas operacionais não-Unix como z/OS, IBM i e OpenVMS também apresentam suporte a Kerberos. A implementação incorporada do protocolo de autenticação Kerberos V para agentes clientes e serviços de rede executados em plataformas incorporadas também está disponível nas empresas.

Protocolo

Descrição

O cliente se autentica no Servidor de Autenticação (AS), que encaminha o nome de usuário para um centro de distribuição de chaves (KDC). O KDC emite um ticket de concessão de ticket (TGT), que é carimbado com a hora e o criptografa usando a chave secreta do ticket-granting service's (TGS) e retorna o resultado criptografado para a estação de trabalho do usuário. Isso é feito com pouca frequência, geralmente no logon do usuário; o TGT expira em algum momento, embora possa ser renovado de forma transparente pelo gerenciador de sessão do usuário enquanto ele estiver conectado.

Quando o cliente precisa se comunicar com um serviço em outro nó (um "principal", na linguagem do Kerberos), o cliente envia o TGT para o TGS, que geralmente compartilha o mesmo host que o KDC. O serviço já deve ter sido registrado no TGS com um Service Principal Name (SPN). O cliente usa o SPN para solicitar acesso a esse serviço. Depois de verificar que o TGT é válido e que o usuário tem permissão para acessar o serviço solicitado, o TGS emite o ticket e as chaves de sessão para o cliente. O cliente então envia o ticket para o servidor de serviço (SS) junto com sua solicitação de serviço.

Negociações de Kerberos

O protocolo é descrito em detalhes abaixo.

Login baseado no cliente do usuário sem Kerberos

1. Um usuário digita um nome de usuário e senha na(s) máquina(s) cliente(s). Outros mecanismos de credenciais como pkinit (RFC 4556) permitem o uso de chaves públicas no lugar de uma senha. O cliente transforma a senha na chave de uma cifra simétrica. Isso ou usa o agendamento de chaves embutido, ou um hash único, dependendo da suíte cifra usada.
2. O servidor recebe o nome de usuário e cifra simétrica e o compara com os dados do banco de dados. O login foi um sucesso se a cifra corresponder à cifra armazenada para o usuário.

Autenticação do cliente

1. O cliente envia uma mensagem de texto clara do ID do usuário para os serviços de solicitação AS (Authentication Server) em nome do usuário. (Nota: Nem a chave secreta nem a senha é enviada para o AS.)
2. O AS verifica se o cliente está na sua base de dados. Se for, o AS gera a chave secreta ao hashing a senha do usuário encontrada no banco de dados (por exemplo, Active Directory no Windows Server) e envia as seguintes duas mensagens para o cliente:
   • Mensagem A: Chave de sessão do cliente/TGS criptografado usando a chave secreta do cliente / usuário.
   • Mensagem B: Bilhete-Granting-Ticket (TGT, que inclui o ID do cliente, endereço de rede do cliente, período de validade do ticket, e o Chave de sessão do cliente/TGS) criptografado usando a chave secreta do TGS.
3. Uma vez que o cliente recebe mensagens A e B, ele tenta descriptografar a mensagem A com a chave secreta gerada a partir da senha inserida pelo usuário. Se a senha inserida pelo usuário não corresponder à senha no banco de dados AS, a chave secreta do cliente será diferente e, portanto, incapaz de descriptografar a mensagem A. Com uma senha válida e chave secreta o cliente descriptografa mensagem A para obter o Chave de sessão do cliente/TGS. Esta chave de sessão é usada para mais comunicações com o TGS. (Nota: O cliente não pode descriptografar a Mensagem B, pois é criptografado usando a chave secreta do TGS.) Neste ponto, o cliente tem informações suficientes para se autenticar no TGS.

Autorização de serviço do cliente

1. Ao solicitar serviços, o cliente envia as seguintes mensagens para o TGS:
   • Mensagem C: Composto da mensagem B (o TGT criptografado usando a chave secreta TGS) e o ID do serviço solicitado.
   • Mensagem D: Autenticador (que é composto pelo ID do cliente e pelo timestamp), criptografado usando o Chave de sessão do cliente/TGS.
2. Ao receber mensagens C e D, o TGS recupera a mensagem B fora da mensagem C. Ele descriptografa a mensagem B usando a chave secreta do TGS. Isto dá-lhe o Chave de sessão do cliente/TGS e o ID do cliente (ambos estão no TGT). Usando isto Chave de sessão do cliente/TGS, o TGS descriptografa a mensagem D (Authenticator) e compara os IDs do cliente das mensagens B e D; se corresponderem, o servidor envia as seguintes duas mensagens para o cliente:
   • Mensagem E: Bilhete de cliente para servidor (que inclui o ID do cliente, endereço de rede do cliente, período de validade e Sessão Cliente/Server Chaveiro) criptografado usando a chave secreta do serviço.
   • Mensagem F: Sessão Cliente/Server Chaveiro criptografado com o Chave de sessão do cliente/TGS.

Solicitação de serviço do cliente

1. Ao receber mensagens E e F da TGS, o cliente tem informações suficientes para se autenticar no Servidor de Serviços (SS). O cliente se conecta às SS e envia as seguintes duas mensagens:
   • Mensagem E: Do passo anterior (o Bilhete de cliente para servidor, criptografado usando a chave secreta do serviço pelo TGS).
   • Mensagem G: Um novo Autenticador, que inclui o ID do cliente, o timestamp e é criptografado usando Sessão Cliente/Server Chaveiro.
2. A SS descriptografa o bilhete (mensagem E) usando sua própria chave secreta para recuperar o Sessão Cliente/Server Chaveiro. Usando a chave de sessões, a SS descriptografa o Autenticador e compara o ID do cliente das mensagens E e G, se corresponderem ao servidor envia a seguinte mensagem ao cliente para confirmar a sua verdadeira identidade e vontade de servir o cliente:
   • Mensagem H: O timestamp encontrado no Autenticador do cliente (mais 1 na versão 4, mas não é necessário na versão 5), criptografado usando o Sessão Cliente/Server Chaveiro.
3. O cliente descriptografa a confirmação (mensagem H) usando o Sessão Cliente/Server Chaveiro e verifica se o timestamp está correto. Se assim for, então o cliente pode confiar no servidor e pode iniciar a emissão de pedidos de serviço para o servidor.
4. O servidor fornece os serviços solicitados ao cliente.

Desvantagens e limitações

• Kerberos tem requisitos de tempo rigorosos, o que significa que os relógios dos hosts envolvidos devem ser sincronizados dentro de limites configurados. Os tickets têm um período de disponibilidade de tempo, e se o relógio do host não estiver sincronizado com o relógio do servidor Kerberos, a autenticação falhará. A configuração padrão por MIT requer que os tempos do relógio não sejam mais de cinco minutos de distância. Na prática, os daemons do Network Time Protocol são geralmente usados para manter os relógios de host sincronizados. Note que alguns servidores (a implementação da Microsoft sendo um deles) podem retornar um resultado KRB_AP_ERR_SKEW contendo o tempo do servidor criptografado se ambos os relógios tiverem um deslocamento maior do que o valor máximo configurado. Nesse caso, o cliente poderia repensar calculando o tempo usando o tempo do servidor fornecido para encontrar o deslocamento. Este comportamento é documentado no RFC 4430.
• O protocolo de administração não é padronizado e difere entre implementações do servidor. As alterações de senha são descritas no RFC 3244.
• Em caso de adoção de criptografia simétrica (Kerberos pode trabalhar usando criptografia simétrica ou assimétrica (public-key)), uma vez que todas as autenções são controladas por um centro centralizado de distribuição de chaves (KDC), o compromisso desta infraestrutura de autenticação permitirá que um atacante impersone qualquer usuário.
• Cada serviço de rede que requer um nome de host diferente precisará de seu próprio conjunto de chaves Kerberos. Isso complica hospedagem virtual e clusters.
• Kerberos requer contas de usuário e serviços para ter um relacionamento confiável com o servidor de token Kerberos.
• A confiança do cliente necessária torna a criação de ambientes encenados (por exemplo, domínios separados para ambiente de teste, ambiente de pré-produção e ambiente de produção) difíceis: Qualquer relacionamento de confiança de domínio precisa ser criado que evite uma separação estrita de domínios de ambiente, ou clientes de usuário adicionais precisam ser fornecidos para cada ambiente.

Vulnerabilidades

A cifra Data Encryption Standard (DES) pode ser usada em combinação com o Kerberos, mas não é mais um padrão da Internet porque é fraca. Vulnerabilidades de segurança existem em muitos produtos legados que implementam Kerberos porque não foram atualizados para usar cifras mais recentes como AES em vez de DES.

Em novembro de 2014, a Microsoft lançou um patch (MS14-068) para corrigir uma vulnerabilidade explorável na implementação do Windows do Kerberos Key Distribution Center (KDC). A vulnerabilidade supostamente permite que os usuários "elevem" (e abusar) dos seus privilégios, até ao nível do Domínio.