Resumo

  • Os valores mestres da RFC 3079 serviam apenas como entrada de derivação. Chaves transitórias distintas, separadas por função e sentido, inicializavam os contextos de envio e recepção.
  • Acertar o vetor de teste provava a aritmética, não que os pares escolheram a mesma primeira autenticação, cruzaram corretamente envio e recepção, negociaram a mesma força ou entregaram dados à aplicação.

O valor mestre parava antes do tráfego

A especificação é explícita: chaves mestras nunca são usadas para cifrar ou decifrar dados. Em MS-CHAP-2, o hash duplo da senha e o NT-Response produziam um valor mestre. GetAsymmetricStartKey abria a ramificação com duas coordenadas — enviar ou receber, cliente ou servidor. GetNewKeyFromSHA produzia então a chave transitória instalada na tabela RC4.

Um log de “master key OK” não informava a ramificação, a direção nem o contexto final. Dois equipamentos poderiam calcular saídas válidas localmente e ainda falhar juntos por inversão de papel ou por associação a outro link.

Publicada em março de 2001 como RFC Informational, a RFC 3079 buscava oferecer uma referência aberta de interoperabilidade. Negociação CCP, pacotes MPPE e mudanças durante a sessão ficavam na RFC 3078. Publicação não significava padrão da Internet nem prova de adoção.

As credenciais continuavam tendo origem

MS-CHAP-1 derivava 40 e 56 bits do hash LAN Manager e 128 bits do hash Windows NT mais o desafio. MS-CHAP-2 usava o caminho Windows NT e o NT-Response para as três forças. EAP-TLS começava no segredo exportado pelo TLS.

Chegar ao mesmo tipo de chave MPPE não apagava essas diferenças. A evidência precisava guardar família de autenticação, par que iniciou a chamada, primeiro evento escolhido, desafios ou geração TLS e link de destino. Oito octetos podiam ter 40 ou 56 bits efetivos; dezesseis octetos podiam vir de sessões diferentes.

A RFC 2759 definia os desafios e o NT-Response de MS-CHAP-2; a RFC 2433, o mecanismo anterior; a RFC 2716, EAP-TLS em PPP. Cada uma documentava entradas. Nenhuma provava CCP Opened.

“Primeira autenticação” era estado distribuído

As chaves iniciais nos dois sentidos vinham das credenciais do par que iniciou a chamada. Havendo desafio, valia o da primeira autenticação, mesmo em autenticação bilateral e em cada link de um bundle multilink.

Esse detalhe exige memória operacional. Um serviço de identidade pode manter apenas o último sucesso; um coordenador pode combinar links sem reter o desafio original; um chassi de failover pode receber usuário e sessão, mas não a geração de derivação. A fórmula permanece correta e o resultado, errado.

No multilink multichassi, a RFC atribuiu às implementações a responsabilidade de gerar as chaves certas em todas as máquinas. A verdadeira identidade da sessão incluía evento de autenticação, papel, membro do bundle e geração.

Enviar de um lado era receber do outro

As constantes de GetAsymmetricStartKey cruzavam os papéis. A chave de envio do servidor correspondia à de recepção do cliente; o par oposto seguia a relação inversa. Na seção EAP-TLS, a RFC dizia diretamente que a chave de envio de um lado é a de recepção do outro.

Copiar um campo send_key para o send_key do par preservaria o nome e quebraria a relação. O recibo precisa ligar identidades, papéis, direção local, direção remota e impressões digitais da geração e da chave transitória, sem expor o segredo.

A força também era moldada depois. Os modos de 40 e 56 bits usavam oito octetos; o primeiro sobrescrevia três octetos com constantes e o segundo, um. O modo de 128 bits usava dezesseis. EAP-TLS exigia completar à esquerda valores curtos e truncar valores longos. Comprimento final igual não demonstrava origem igual.

Os vetores publicados verificavam o cálculo, não uma sessão viva. A RFC alertava ainda que MS-CHAP-1 de 40 bits repetia a chave inicial sob as mesmas credenciais e recomendava evitá-lo. Esta é uma análise histórica, não recomendação atual de RC4 ou MS-CHAP.

A sessão começava depois da derivação

A RFC 3078 exigia PPP na fase Network-Layer Protocol e CCP em Opened antes do primeiro pacote MPPE. A RFC 2548 tratava do transporte de chaves direcionais por RADIUS e da custódia exercida por proxies. A RFC 1661 separava as fases PPP.

Autenticação não provava entrega do segredo; entrega não provava vínculo ao link; vínculo não provava negociação; CCP Opened não provava sincronização contínua; decifrar um pacote não provava resultado de aplicação.

Pela disciplina de camadas de realidade de Lu Heng, “mestra”, “envio”, “autenticado” e “128 bits” são rótulos. O sistema real está nas transições. A RFC 3079 deixou um legado preciso: linhagem e direção fazem parte da interoperabilidade, e derivação bem-sucedida é apenas um recibo intermediário.

Fontes