Kerberos 📖 Wikipedia

O Kerberos é um protocolo de autenticação de rede de computadores, que funciona com base em bilhetes (tickets) para permitir que nós se comunicando em uma rede insegura provem sua identidade uns aos outros de maneira segura. Seus projetistas o direcionaram principalmente para um modelo cliente-servidor e ele fornece 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 escutas (eavesdropping) e ataques de repetição.

O Kerberos baseia-se em criptografia de chave simétrica e requer uma terceira parte confiável, podendo, opcionalmente, utilizar criptografia de chave pública durante certas fases da autenticação.^[1] O Kerberos utiliza a porta UDP 88 por padrão.

O protocolo recebeu o nome do personagem Cérbero (do grego Kerberos), da mitologia grega, o feroz cão de guarda de três cabeças de Hades.^[2]

O Instituto de Tecnologia de Massachusetts (MIT) desenvolveu o Kerberos em 1988 para proteger os serviços de rede fornecidos pelo Projeto Athena.^[3][4] Sua primeira versão foi projetada principalmente por Steve Miller e Clifford Neuman, baseando-se no anterior protocolo de chave simétrica Needham-Schroeder.^[5][6] As versões 1 a 3 do Kerberos foram experimentais e não foram lançadas fora do MIT.^[7]

A versão 4 do Kerberos, a primeira versão pública, foi lançada em 24 de janeiro de 1989. Como o Kerberos 4 foi desenvolvido nos Estados Unidos e utilizava o algoritmo de encriptação Data Encryption Standard (DES), as restrições de controle de exportação dos EUA impediram que ele fosse exportado para outros países. O MIT criou uma versão exportável do Kerberos 4 com todo o código de encriptação removido,^[7] chamada "Bones".^[8] Eric Young, da Universidade Bond na Austrália, reimplementou o DES no Bones, criando uma versão chamada "eBones", que podia ser usada livremente em qualquer país. O Instituto Real de Tecnologia da Suécia lançou outra reimplementação chamada KTH-KRB.^[9]

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

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

• Especificações de Encriptação e Checksum (RFC 3961).
• Encriptação Advanced Encryption Standard (AES) para Kerberos 5 (RFC 3962).
• Uma nova edição da especificação do Kerberos V5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Esta versão torna obsoleta a RFC 1510, esclarece aspectos do protocolo e o uso pretendido em uma explicação mais detalhada e clara.
• Uma nova edição da especificação da Interface de Programação de Aplicativo para Serviços de Segurança Genérica (GSS-API) "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121).

O MIT disponibiliza uma implementação do Kerberos gratuitamente, sob permissões de direitos autorais semelhantes às usadas nas licenças BSD. Em 2007, o MIT formou o Consórcio Kerberos para promover o desenvolvimento contínuo. Os patrocinadores fundadores incluem empresas como Oracle, Apple Inc., Google, Microsoft, Centrify Corporation e TeamF1 Inc., além de instituições acadêmicas como o Instituto Real de Tecnologia na Suécia, a Universidade Stanford e o MIT. Empresas como a CyberSafe também oferecem versões com suporte comercial.

O cliente se autentica no Servidor de Autenticação (AS - Authentication Server), que faz parte do centro de distribuição de chaves (KDC - Key Distribution Center). O KDC emite um ticket de concessão de ticket (TGT - Ticket-Granting Ticket), que possui um carimbo de data/hora (timestamp), criptografa-o usando a chave secreta do serviço de concessão de ticket (TGS - Ticket-Granting Service) e retorna o resultado criptografado para a estação de trabalho do usuário. Isso é feito de forma infrequente, normalmente 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 logado.

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

O protocolo é descrito em detalhes abaixo.

1. O usuário insere um nome de usuário e senha na máquina cliente. Outros mecanismos de credenciais, como o PKINIT (RFC 4556), permitem o uso de chaves públicas ou cartões inteligentes (smart cards) em vez de uma senha.
2. O cliente transforma a senha em uma chave simétrica usando uma função de hash unidirecional ou derivação de chave, dependendo do conjunto de cifras utilizado.
3. No Kerberos moderno (v5), o cliente geralmente usa essa chave para criptografar um carimbo de data/hora (timestamp) atual. Esse timestamp criptografado é enviado ao AS junto com o nome de usuário como uma "pré-autenticação", provando que o usuário conhece a senha antes que o AS emita qualquer bilhete, o que previne ataques de força bruta offline.

1. O cliente envia uma mensagem em texto claro com o ID do usuário para o AS (Servidor de Autenticação) solicitando serviços em nome do usuário. (Nota: Nem a chave secreta nem a senha são enviadas ao AS.)
2. O AS verifica se o cliente está em seu banco de dados. Se estiver, o AS gera a chave secreta calculando o hash da senha do usuário encontrada no banco de dados (por exemplo, Active Directory no Windows Server) e envia de volta as seguintes duas mensagens para o cliente:
   • Mensagem A: Chave de Sessão Cliente/TGS criptografada usando a chave secreta do cliente/usuário.
   • Mensagem B: Ticket de Concessão de Ticket (TGT, que inclui o ID do cliente, o endereço de rede do cliente, o período de validade do ticket e a Chave de Sessão Cliente/TGS) criptografado usando a chave secreta do TGS.
3. Assim que o cliente recebe as mensagens A e B, ele tenta decifrar 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 do AS, a chave secreta do cliente será diferente e, portanto, incapaz de decifrar a mensagem A. Com uma senha e chave secreta válidas, o cliente decifra a mensagem A para obter a Chave de Sessão Cliente/TGS. Esta chave de sessão é usada para comunicações posteriores com o TGS. (Nota: O cliente não pode decifrar a Mensagem B, pois ela está criptografada com a chave secreta do TGS.) Neste ponto, o cliente possui informações suficientes para se autenticar no TGS.

1. Ao solicitar serviços, o cliente envia as seguintes mensagens para o TGS:
   • Mensagem C: Composta pela mensagem B (o TGT criptografado com a chave secreta do TGS) e o ID do serviço solicitado.
   • Mensagem D: Autenticador (composto pelo ID do cliente e o carimbo de data/hora), criptografado usando a Chave de Sessão Cliente/TGS (encontrada pelo cliente na Mensagem A).
2. Ao receber as mensagens C e D, o TGS extrai a mensagem B da mensagem C. Ele decifra a mensagem B usando a chave secreta do TGS. Isso lhe fornece a Chave de Sessão Cliente/TGS e o ID do cliente (ambos estão no TGT). Usando esta Chave de Sessão Cliente/TGS, o TGS decifra a mensagem D (Autenticador) e compara os IDs de cliente das mensagens B e D; se eles corresponderem, o servidor envia as seguintes duas mensagens para o cliente:
   • Mensagem E: Ticket cliente-servidor (que inclui o ID do cliente, o endereço de rede do cliente, o período de validade e a Chave de Sessão Cliente/Servidor) criptografado usando a chave secreta do serviço.
   • Mensagem F: Chave de Sessão Cliente/Servidor criptografada com a Chave de Sessão Cliente/TGS.

1. Ao receber as mensagens E e F do TGS, o cliente possui informações suficientes para se autenticar no Servidor de Serviço (SS). O cliente se conecta ao SS e envia as seguintes duas mensagens:
   • Mensagem E: Do passo anterior (o Ticket cliente-servidor, criptografado usando a chave secreta do serviço pelo TGS).
   • Mensagem G: Um novo Autenticador, que inclui o ID do cliente, carimbo de data/hora e é criptografado usando a Chave de Sessão Cliente/Servidor.
2. O SS decifra o ticket (mensagem E) usando sua própria chave secreta para recuperar a Chave de Sessão Cliente/Servidor. Usando a chave de sessão, o SS decifra o Autenticador e compara o ID do cliente das mensagens E e G; se eles corresponderem, o servidor envia a seguinte mensagem ao cliente para confirmar sua identidade real e disposição para atender o cliente:
   • Mensagem H: O carimbo de data/hora encontrado no Autenticador do cliente (mais 1 na versão 4, mas não necessário na versão 5^[10][11]), criptografado usando a Chave de Sessão Cliente/Servidor.
3. O cliente decifra a confirmação (mensagem H) usando a Chave de Sessão Cliente/Servidor e verifica se o carimbo de data/hora está correto. Em caso afirmativo, o cliente pode confiar no servidor e começar a emitir solicitações de serviço para o servidor.
4. O servidor fornece os serviços solicitados ao cliente.

O Windows 2000 e versões posteriores utilizam o Kerberos como seu método de autenticação padrão.^[12] Algumas adições da Microsoft ao conjunto de protocolos Kerberos estão documentadas na RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". A RFC 4757 documenta o uso da cifra RC4 pela Microsoft. Embora a Microsoft utilize e estenda o protocolo Kerberos, ela não usa o software do MIT.

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

Em contrapartida, quando o cliente, o servidor ou ambos não estão integrados a um domínio (ou não fazem parte do mesmo ambiente de domínio confiável), o Windows utilizará o NTLM para autenticação entre cliente e servidor.^[12]

Aplicações web da Internet podem impor o Kerberos como método de autenticação para clientes integrados ao domínio usando APIs fornecidas sob o SSPI.

O Microsoft Windows e o Windows Server incluem o setspn, utilitário de linha de comando que pode ser usado para ler, modificar ou excluir os Nomes Principais de Serviço (SPN) de uma conta de serviço do Active Directory.^[13][14]

Muitos sistemas operacionais semelhantes ao Unix, incluindo FreeBSD, 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 baseados em Unix, como z/OS, IBM i e OpenVMS, também apresentam suporte ao Kerberos. Implementações embarcadas do protocolo de autenticação Kerberos V para agentes clientes e serviços de rede em execução em plataformas embarcadas também estão disponíveis por meio de empresas do setor.

• O Kerberos possui requisitos estritos de tempo, o que significa que os relógios dos computadores envolvidos devem estar sincronizados dentro de limites configurados. Os tickets têm um período de disponibilidade de tempo e, se o relógio do computador host não estiver sincronizado com o relógio do servidor Kerberos, a autenticação falhará. A configuração padrão do MIT exige que as diferenças de horário não passem de cinco minutos. Na prática, daemons do Network Time Protocol (NTP) são geralmente usados para manter os relógios dos hosts sincronizados. Note que alguns servidores (a implementação da Microsoft sendo um deles) podem retornar um resultado KRB_AP_ERR_SKEW contendo o horário criptografado do servidor se ambos os relógios tiverem um desvio maior que o valor máximo configurado. Nesse caso, o cliente pode tentar novamente calculando o tempo com base no horário do servidor fornecido para encontrar o desvio. Este comportamento está documentado na RFC 4430.
• O protocolo de administração não é padronizado e difere entre as implementações de servidor. As alterações de senha são descritas na RFC 3244.
• No caso da adoção de criptografia simétrica (o Kerberos pode funcionar usando criptografia simétrica ou assimétrica de chave pública), como todas as autenticações são controladas por um centro de distribuição de chaves (KDC) centralizado, o comprometimento dessa infraestrutura de autenticação permitirá que um invasor se passe por 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 a hospedagem virtual (virtual hosting) e clusters.
• O Kerberos exige que as contas de usuário e os serviços tenham uma relação de confiança com o servidor de tokens Kerberos.
• A confiança exigida do cliente torna difícil a criação de ambientes em estágios (por exemplo, domínios separados para ambiente de teste, ambiente de pré-produção e ambiente de produção): ou relações de confiança de domínio precisam ser criadas (o que impede uma separação estrita dos domínios de ambiente) ou clientes de usuário adicionais precisam ser fornecidos para cada ambiente.

A cifra Data Encryption Standard (DES) pode ser usada em combinação com o Kerberos, mas não é mais um padrão da Internet por ser considerada fraca.^[15] Existem vulnerabilidades de segurança em produtos que implementam versões herdadas (legadas) do Kerberos que carecem de suporte para cifras de criptografia mais recentes, como o AES.

• Autenticação única (SSO)
• Gestão de identidades
• Host Identity Protocol (HIP)
• Interface de Programação de Aplicativo para Serviços de Segurança Genérica (GSS-API)
• SPNEGO
• S/Key
• Protocolo de senha remota segura (SRP)

Geral

RFCs

• RFC 1510 The Kerberos Network Authentication Service (V5) [Obsoleto]
• RFC 1964 The Kerberos Version 5 GSS-API Mechanism
• RFC 3961 Encryption and Checksum Specifications for Kerberos 5
• RFC 3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5
• RFC 4120 The Kerberos Network Authentication Service (V5) [Atual]
• RFC 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
• RFC 4537 Kerberos Cryptosystem Negotiation Extension
• RFC 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
• RFC 4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
• RFC 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows [Obsoleto]
• RFC 5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP
• RFC 5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
• RFC 5868 Problem Statement on the Cross-Realm Operation of Kerberos
• RFC 5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy
• RFC 6111 Additional Kerberos Naming Constraints
• RFC 6112 Anonymity Support for Kerberos
• RFC 6113 A Generalized Framework for Kerberos Pre-Authentication
• RFC 6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol
• RFC 6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message
• RFC 6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
• RFC 6560 One-Time Password (OTP) Pre-Authentication
• RFC 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos
• RFC 6784 Kerberos Options for DHCPv6
• RFC 6803 Camellia Encryption for Kerberos 5
• RFC 6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals
• RFC 6880 An Information Model for Kerberos Version 5
• RFC 8009 AES Encryption with HMAC-SHA2 for Kerberos 5