Resumo

  • Publicada em setembro de 1993, a RFC 1510 conectou realms Kerberos com chaves entre realms e tickets TGT para os serviços de concessão de tickets (TGS). transited era um conjunto sem ordem dos realms intermediários; o realm do cliente e o do serviço ficavam em outros campos.
  • Uma conexão direta podia, portanto, cruzar de um realm para outro com transited vazio. A RFC 4120, que substituiu a RFC 1510 em 2005, tornou a checagem explícita: o servidor da aplicação valida o caminho ou rejeita o ticket entre realms sem a marca de política verificada pelo KDC.

Análise

Dois extremos fora da lista

Considere dois nomes de realm para o exemplo. Uma pessoa cadastrada em ALPHA.EXAMPLE solicita um ticket para o serviço de arquivos de BETA.EXAMPLE. Se os dois realms compartilham a chave necessária e não há um terceiro realm no meio, transited pode ficar vazio. Os campos de origem e destino continuam presentes; o campo vazio registra um salto direto.

transited resume os realms intermediários. Os extremos ficam em outros campos; um salto direto deixa vazio o trecho intermediário.

A RFC 1510 descreve cada realm como um domínio administrativo com seu próprio serviço Kerberos. O realm integra o nome do principal e pode ajudar o serviço de destino a decidir se atende à solicitação. Para atravessar a fronteira, os administradores estabelecem uma chave entre realms; podem usar uma chave diferente para cada direção. O serviço de concessão de tickets do realm remoto é cadastrado como principal no outro realm, e o KDC remoto usa a chave compartilhada para decifrar o ticket que recebeu.

O cliente não precisa manter uma conta separada em cada destino. Primeiro obtém um ticket TGT para o serviço de concessão de tickets (TGS) remoto; depois apresenta esse ticket para pedir o ticket da aplicação. A chave compartilhada faz a ponte criptográfica. Instalar e manter a ponte é uma decisão administrativa.

Os intermediários entram como conjunto, sem ordem

O caminho pode passar por vários realms. A RFC 1510 descreve como comum uma hierarquia em que cada realm compartilha uma chave com seu pai e chaves diferentes com cada filho. A hierarquia permite construir um caminho quando os extremos não compartilham chave direta. A especificação também aceita caminhos alternativos que contornam realms intermediários, inclusive para tornar a comunicação mais eficiente. Em uma estrutura sem hierarquia, outra base de dados pode ser necessária para montar o trajeto.

A RFC 1510 guarda os realms intermediários como conjunto sem ordem e comprime nomes hierárquicos comuns para reduzir o campo. A sequência do trajeto fica em outro registro, como uma trilha de auditoria operacional.

O serviço de concessão de tickets adiciona o realm que emitiu o ticket recebido; seu próprio realm fica fora do campo. A regra impede que um servidor esconda sua participação apenas omitindo o próprio nome. A RFC também aponta que ele ainda pode omitir outros realms; a política do serviço precisa avaliar as demais declarações.

Em julho de 2005, a RFC 4120 substituiu a RFC 1510 e detalhou a responsabilidade pela checagem. O servidor da aplicação decide, no fim, aceitar ou rejeitar a autenticação. Ele deve confirmar se confia nos KDCs envolvidos. O KDC do realm de destino pode aplicar uma política local e marcar o ticket de serviço com TRANSITED-POLICY-CHECKED. Se não fez essa verificação, o servidor precisa checar os realms por conta própria ou rejeitar o ticket sem a marca. A RFC alerta que um KDC não confiável pode fabricar a lista, mesmo quando ela contém nomes de KDCs confiáveis.

A decisão se divide em três pontos: administradores instalam chaves entre realms, KDCs emitem tickets e registram as checagens feitas, e cada aplicação escolhe os caminhos que aceita. Acrescentar uma chave pode encurtar o percurso e facilitar o acesso. Também amplia o conjunto de identidades que serviços conectados podem aceitar. A linha escrita na configuração aprova uma relação de acesso futura; o diagrama mostra apenas parte dessa decisão.

A RFC 1510, em setembro de 1993, dizia que o protocolo seguia em revisão e ainda não era proposto como padrão da Internet. A RFC 4120 entrou na trilha Standards Track em 2005 e detalhou as obrigações de implementação. Falta um registro de implantação dos anos 1990 que mostre quais servidores verificavam transited; esse registro revelaria se o controle funcionava nos sistemas em produção, enquanto as RFCs documentam o desenho.

Fontes