Resumo

  • Nos intercâmbios com resposta, RFC 2025 concatena o randSrc do iniciador e o randTarg do destino para formar o Context ID. Os dois componentes registram que cada lado participou da separação entre o contexto atual e os anteriores.
  • O SPKM-2 unilateral contém apenas SPKM-REQ. O destino não fornece valor aleatório; precisa confiar no frescor declarado pelo iniciador ou rejeitar o contexto. key-src-bind reforça a ligação entre solicitação e chave, mas não cria uma contribuição do destino.
  • A proteção contra repetição durante o estabelecimento e os serviços opcionais replay/sequence para mensagens posteriores são planos distintos. O Context ID também não prova autorização, entrega ou resultado de negócio.

Um recibo em que os autores são visíveis

RFC 2025 especifica o Simple Public-Key GSS-API Mechanism, o SPKM. Seus tokens de estabelecimento têm muitos campos, mas a construção do Context ID oferece uma evidência particularmente clara. O iniciador envia randSrc. Quando há uma resposta, o destino acrescenta randTarg. A concatenação dos dois passa a identificar o contexto nos tokens seguintes.

Cada parte do identificador tem procedência. O iniciador percebe que o destino produziu material para aquele intercâmbio; o destino sabe que seu próprio valor recém-gerado foi incluído ao lado do valor do iniciador. Por isso randSrc || randTarg funciona como recibo bilateral de uma alegação restrita: com alta probabilidade, aquele contexto foi separado dos anteriores.

O adjetivo “restrita” faz diferença. RFC 2025 não exige imprevisibilidade. Exige que seja altamente provável que os valores nunca tenham sido usados. A função é evitar reutilização entre contextos, não esconder um segredo. Qualificar o número como “forte” não aumenta o alcance da prova.

O caso que não tem resposta

SPKM-1 sempre inclui resposta do destino. Na autenticação unilateral, a sequência é SPKM-REQ e SPKM-REP-TI; na mútua, aparece ainda SPKM-REP-IT. O SPKM-2 mútuo também responde. Em todos esses caminhos, o destino dispõe de um token para acrescentar randTarg.

O SPKM-2 unilateral é diferente: existe apenas SPKM-REQ. Sem token de retorno, o destino não contribui com valor aleatório, e o Context ID fica limitado ao valor do iniciador. RFC 2025 torna explícita a consequência: o destino deve confiar que o iniciador gerou um valor fresco ou rejeitar o contexto.

Não se trata apenas de poupar uma viagem pela rede. Nos intercâmbios com resposta, quem decide aceitar também coloca sua própria garantia de não reutilização no identificador. No caso unilateral, essa parte apenas avalia a alegação do iniciador. O Context ID ainda distingue o contexto, mas já não demonstra frescor produzido em conjunto.

O que key-src-bind realmente acrescenta

Há uma defesa específica para SPKM-2 unilateral. Se o algoritmo de estabelecimento de chave não ligar por conta própria o nome de origem à chave do contexto, SPKM-REQ deve carregar key-src-bind: um resumo MD5 do nome de origem codificado e da chave proposta.

Essa ligação ajuda o destino a avaliar como uma só solicitação a origem declarada, o token recebido e a chave. A RFC também diz que ela auxilia a confiança no frescor do token e da chave proposta. Ainda assim, o campo é produzido dentro da solicitação do iniciador. Ele não acrescenta resposta, não gera randTarg e não mostra que o destino criou material fresco.

Vínculo entre identidade e chave, autoria do frescor e autenticação mútua são fatos diferentes. Um registro que os reduz a “contexto estabelecido” elimina exatamente a distinção que o protocolo permite observar.

Dois planos de replay

O SPKM pode verificar repetição e ordem das mensagens protegidas depois do estabelecimento. Esses serviços usam números de sequência quando solicitados pela aplicação. Eles não surgem automaticamente da composição aleatória do Context ID.

A especificação geral da GSS-API, RFC 2743, trata replay e sequence por mensagem como opções selecionáveis. O chamador as solicita, o aceitador informa o que foi disponibilizado, e uma implementação pode marcar duplicação ou desordem em estado suplementar sem necessariamente impedir a entrega da mensagem ao chamador. A aplicação também continua responsável pelo transporte dos tokens.

Uma auditoria precisa separar duas perguntas. Esta tentativa de estabelecer o contexto foi distinguida de tentativas antigas? As mensagens posteriores foram examinadas quanto a duplicação ou ordem dentro do contexto aceito? O Context ID ajuda na primeira. Flags negociadas, estado da sequência e resultados de verificação respondem à segunda.

História da especificação, não adoção comprovada

O RFC Editor registra RFC 2025 como Proposed Standard publicado em outubro de 1996; na data desta análise, a busca de erratas não mostrava correções publicadas. O registro SMI da IANA mantém identificadores de objeto para SPKM-1, SPKM-2, SPKM-3 e os tokens GSS do SPKM. Isso documenta especificação e alocação de identificadores, não uso atual.

RFC 2847 definiu mais tarde SPKM-3 como equivalente a SPKM-1, exceto por mudanças enumeradas. A relação situa a família, mas não muda o limite probatório de RFC 2025: um Context ID só pode ser interpretado junto ao padrão de troca que o produziu.

A leitura defensável é curta. randSrc || randTarg registra contribuição bilateral para o frescor do contexto. No SPKM-2 unilateral, o Context ID registra apenas a contribuição do iniciador, mesmo com key-src-bind. Nenhum dos dois prova autorização por certificado, escolha de algoritmo, entrega de mensagens ou conclusão de uma operação.

Fontes