Resumo

  • A RFC 1964 coloca o resumo de vínculos informados pelo chamador, flags de serviço e eventual KRB_CRED no checksum 0x8003 do autenticador Kerberos.
  • Bnd zerado registra ausência de vínculo; KRB_AP_REQ unilateral não confirma o aceitador; e credencial delegada, MIC, Wrap ou sequência válida não demonstram autorização nem conclusão da aplicação.

Delegar uma chave do prédio não é aprovar tudo o que será feito dentro dele. A analogia ajuda a ler a parte mais delicada da RFC 1964: um TGT encaminhável pode ser entregue ao aceitador em KRB_CRED, mas cada serviço posterior ainda decide se aceita o principal e a operação.

Antes da delegação, o mecanismo organiza seus envelopes. O OID da versão Kerberos V5 proposta como padrão é 1.2.840.113554.1.2.2. KRB_AP_REQ recebe TOK_ID 01 00; KRB_AP_REP, 02 00; KRB_ERROR, 03 00. MIC usa 01 01 e Wrap, 02 01. Esses números reduzem erro de interpretação. Eles não validam o conteúdo, a sessão ou o resultado.

O resumo de canal depende do que a aplicação entregou

O autenticador KRB_AP_REQ inclui um checksum especial, de tipo 0x8003. Ele começa com o comprimento 16 e armazena um MD5 calculado sobre componentes não nulos da estrutura de channel bindings, obedecendo a regras de ordem de bytes e comprimentos.

Quando a aplicação passa GSS_C_NO_BINDINGS, o campo Bnd tem dezesseis bytes zero. Esse valor não é identidade implícita do transporte. Não representa automaticamente TLS, endereço de rede ou socket. É uma declaração exata de ausência. Para que a comparação tenha significado, os participantes precisam concordar previamente sobre qual binding representa o canal e fornecer os valores correspondentes.

Em seguida aparecem os flags de delegação, mutualidade, replay, sequência, confidencialidade e integridade. Os quatro primeiros combinam pedido do iniciador e disponibilidade do mecanismo; os dois últimos descrevem disponibilidade de proteção por mensagem. Um flag ligado é parte da descrição do contexto, não um recibo de que a aplicação usou ou aprovou o serviço.

A autenticação mútua precisa voltar

Sem mutual_req, a RFC define autenticação de mão única. O alvo não devolve confirmação ao KRB_AP_REQ. Isso pode bastar para o alvo autenticar o iniciador, mas o iniciador não obteve prova de retorno do alvo.

Ao pedir mutualidade, o iniciador marca mutual-required em APOptions e o bit correspondente no checksum. O alvo responde com KRB_AP_REP ou KRB_ERROR. Um KRB_AP_REP válido fecha com sucesso a troca mútua; KRB_ERROR fecha o caminho de falha. Auditoria que registra apenas “resposta recebida” perde a diferença que determina o resultado.

Ainda assim, KRB_AP_REP não confirma uma transação de negócio. Ele confirma o estabelecimento do contexto. Uma requisição posterior pode falhar na política de autorização, na sintaxe ou no estado do serviço.

A cadeia da delegação continua depois de KRB_CRED

Com delegação ativa, o checksum cresce para levar a opção 1, o comprimento e KRB_CRED. O TGT transferido possui FORWARDABLE. O aceitador pode então obter capacidade para pedir tickets para outros serviços.

Essa possibilidade precisa de recibos adicionais: validação e decifragem do KRB_CRED, armazenamento controlado, prazo, pedido ao KDC, emissão do ticket de serviço e decisão de autorização no destino. O flag de delegação não prova a presença do conteúdo. A presença do conteúdo não prova uso. O uso não prova autorização.

Proteção por mensagem não é semântica de negócio

MIC protege a integridade de dados separados; Wrap transporta dados com integridade e, se selecionado, sigilo. O número de sequência protegido inclui um indicador de direção. A detecção de repetição e fora de ordem, porém, é opcional e pode ser desativada por solicitação do chamador.

Uma MIC verificada sustenta uma afirmação criptográfica. Um Unwrap correto sustenta outra. A aplicação ainda precisa interpretar, autorizar, executar e registrar. É possível que toda a proteção esteja correta e a operação seja legitimamente recusada.

A RFC 4121 atualizou o mecanismo, e a RFC 6649 depreciou algoritmos fracos da época. Por isso, a RFC 1964 não deve ser tratada como catálogo criptográfico atual. Seu desenho continua útil como disciplina de evidência: a especificação comum define o mínimo verificável, e as decisões futuras permanecem nos componentes que executam o código e suportam o risco. A ideia editorial de Running-Code Primacy ajuda a manter essa ordem sem transformar o texto de Heng Lu em fonte histórica do protocolo.

Fontes