2.3.7 - Autenticação Cruzada
Em Kerberos, há possibilidade de um usuário pertencente a certo domínio ser autenticado e acessar serviços de outro domínio. Essa característica, conhecida como Autenticação Cruzada, é baseada na suposição de que existe uma relação confiável entre os domínios envolvidos. Esta pode ser mono-direcional, de modo que usuários de um domínio A podem acessar serviços do domínio B, mas não o contrário, ou bi-direcional, em que, já esperado, o oposto também é possível.
Relações de Confiança Direta
Este tipo de relação de confiança é elementar e é a base da autenticação cruzada, sendo usada para construir outros dois tipos de relações (Relações de Confiança Transitiva e Relações de Confiança Hierárquica). Esta relação se dá quando o KDC do domínio B tem confiança direta no domínio A, assim permitindo que usuários deste último acessem seus recursos. De um ponto de vista prático, tal relação é obtida por compartilhamento de chave secreta entre dois KDCs, sendo duas chaves no caso bi-direcional. Para tanto, o conceito de Bilhete de Concessão remoto é introduzido, em que, no exemplo de domínios A e B, assume a forma generico/B@A e é adicionado a ambos KDCs com a mesma chave. Esta chave é o segredo que garantirá a confiança entre os dois domínios. Obviamente, para torná-la bi-direcional, é necessário criar o bilhete de concessão remoto generico/A@B em ambos KDCs, associando outra chave secreta.
A introdução do TGT remoto torna a autenticação cruzada uma generalização natural de uma autenticação normal intra-domínio. A operação do sistema Kerberos continua válida, uma vez aceito que o TGS de um domínio pode validar TGTs remotos emitidos pelo TGS de outro. Há uma anomalia formal tendo em vista que TGTs remotos não são emitidos pelo AS, como acontece na autenticação intra-domínio, mas pelo servidor de concessão de bilhete local.
A seguir, um exemplo para esclarecimento do assunto. Suponhamos que o usuário "carlos", pertencente ao domínio ARCHLINUX.ORG, cujo principal associado é carlos@ARCHLINUX.ORG, deseja acessar o servidor gcc.gnu.org, pertencente ao domínio GNU.ORG, via ssh:
- se carlos ainda não possui um TGT do domínio ARCHLINUX.ORG, ele faz uma solicitação de autenticação inicial (kinit). A resposta vem do AS de seu domínio;
- ele digita o comando ssh carlos@gcc.gnu.org para abrir uma conta remota em gcc.gnu.org sem ter de digitar novamente a senha;
- o cliente ssh faz duas interrogações ao DNS: ele responde o IP de gcc.gnu.org e com o endereço obtido apenas realiza o inverso a fim de obter o nome de host (FQDN) na forma canônica (neste caso, ele coincide com gcc.gnu.org);
- o cliente ssh então entende, graças ao resultado anterior, que o destino não pertence ao domínio do usuário e assim interroga o TGS de seu domínio pelo TGT remoto generico/GNU.ORG@ARCHLINUX.ORG;
- com o TGT remoto, ele indaga ao TGS do domínio GNU.ORG pelo bilhete de serviço host/gcc.gnu.org@gnu.org;
- quando o servidor de concessão de bilhete de GNU.ORG recebe a solicitação, ele verifica pela existência do principal generico/GNU.ORG@ARCHLINUX.ORG em seu banco de dados com o qual ele pode verificar a relação de confiança. Se tal verificação é positiva, o bilhete de serviço (criptografado com a chave de host/gcc.gnu.org@GNU.ORG) é finalmente emitido, o qual carlos enviará ao host gcc.gnu.org para obter a conta remota.
Relações de Confiança Transitivas
Quando aumenta o número de domínios nos quais a autenticação cruzada é realizada, o número de chaves em intercâmbio cresce em proporção quadrática. Para contornar o problema, Kerberos 5 introduziu a transitividade na relação de confiança: se um domínio A confia em B e B confia em C, então A automaticamente confia em C. Essa propriedade relacional reduz drasticamente o número de chaves.
Contudo, os clientes não podem adivinhar o caminho de autenticação, se ele não for direto. Então eles devem estar informados sobre o caminho correto pela criação de uma estrofe especial na configuração de cada cliente. Esses caminhos devem ser conhecidos também pelos KDCs, que usam eles para verificação do trânsito.
Relações de Confiança Hierárquicas
Se, em organizações, é utilizada a convenção de nomeação de domínios com o mesmo nome de domínios DNS em letras maiúsculas (escolha altamente recomendada) e se o último pertence a uma hierarquia, então Kerberos 5 suportará domínios adjacentes (hierarquia), tendo uma relação de confiança (naturalmente assumindo que a confiança deve ser sustentada pela presença de chaves apropriadas) e irá construir automaticamente os caminhos de autenticação transitiva. Contudo, administradores podem alterar este mecanismo automático (por questões de eficiência, por exemplo) por forçar caminhos de autenticação personalizados na configuração do cliente.