Resumo

  • O RFC 5421 registra o uso do tipo 6 — já atribuído ao EAP-GTC — pelo EAP-FAST-GTC, em uma troca interna de formato diferente transportada pelo túnel.
  • As proibições recíprocas de uso dentro e fora do túnel e o alerta de compatibilidade do IESG tornam o contexto EAP-FAST parte da identidade do método; isso é uma implicação para a implementação, não prova de uma interrupção medida.

Um campo curto, uma decisão importante

O campo Type do EAP tem um octeto, mas escolhe o caminho de processamento. O RFC 3748 diz que ele identifica o método e descreve o encaminhamento dos pacotes pelo valor Type, de forma semelhante à seleção por porta na camada de transporte. Ao ver o tipo 6, o sistema parece poder chamar o Generic Token Card.

O RFC 5421 acrescenta uma condição ausente nessa leitura isolada. O memorando Informational de 2009 documenta o EAP-FAST-GTC, método interno para uma troca básica de senha. O texto cita bancos de senhas legados, alteração de senha e fluxos de senha de uso único entre os usos pretendidos. Por razões históricas, o método reutiliza o código originalmente atribuído ao EAP-GTC. O registro atual da IANA ainda identifica o tipo 6 como “Generic Token Card”; o RFC 5421 não criou uma segunda atribuição global.

A diferença está no enquadramento e no formato. O EAP-FAST estabelece um túnel TLS; em sua fase interna, os pacotes EAP são encapsulados em TLVs EAP Payload. O RFC 5421 observa que o formato do EAP-FAST-GTC é específico desse túnel e pode não ser compatível com os mecanismos do EAP-GTC usados fora dele. Por isso, estabelece limites complementares: EAP-FAST-GTC NÃO DEVE ser usado fora de um túnel EAP-FAST, e EAP-GTC NÃO DEVE ser usado dentro dele.

Essas regras também dão sentido ao tipo 6 em cada situação. Se o despachante guardar apenas o octeto Type e perder se o pacote veio da troca externa ou da fase interna do EAP-FAST, descartará uma informação que o protocolo usa para distinguir os métodos. Essa é uma implicação de implementação, não a afirmação de que algum sistema atual cometeu esse erro.

O alerta de compatibilidade está no próprio documento

A nota do IESG anexada ao RFC 5421 diz que reutilizar códigos EAP já atribuídos é incompatível com a negociação de métodos definida no RFC 3748. Como o EAP-GTC não tem negociação de versão específica do método, o EAP-FAST-GTC fica implícito dentro do túnel. A nota alerta que isso pode gerar problemas quando uma implementação também precisa aceitar o EAP-GTC de outro fornecedor, e que dar suporte ao mesmo código dentro e fora do túnel exige casos especiais. Um código Type único teria evitado a dificuldade; por isso, tipos atribuídos não devem ser reutilizados com outros sentidos em métodos futuros dentro de túneis.

O alcance da afirmação deve ser preservado: o RFC não diz que toda negociação falha, que o tipo 6 foi revogado ou que um produto atual específico tem um defeito. Ele registra um custo de compatibilidade causado pelo significado contextual do código. O registro oferece o nome global; as regras do túnel delimitam o uso interno; a nota do IESG explica a tensão.

A primazia do código em execução é um enquadramento editorial útil: a entrada de registro não é o sistema inteiro. O resultado também depende do código que recebe o pacote, identifica a camada e escolhe o método. A Nota 65 de Heng Lu ajuda a formular essa lente; não é evidência sobre requisitos EAP nem sobre comportamento de fornecedores.

A proteção da senha é outro limite

O RFC 5421 também afirma que o EAP-FAST-GTC envia informações de senha como texto claro dentro do túnel TLS criptografado. O par precisa autenticar o servidor antes de revelar credenciais, e o EAP-FAST-GTC NÃO DEVE ser usado no Server-Unauthenticated Provisioning Mode, que não autentica o servidor. É uma condição de segurança importante, mas separada da questão do Type: proteger a credencial não resolve por si só a seleção do método, e selecionar corretamente não comprova a autenticação do servidor.

Para quem opera a pilha, a revisão deve localizar a fronteira: onde o sistema decide se o tipo 6 representa EAP-GTC comum ou EAP-FAST-GTC? A fase do túnel deve acompanhar o Type e as proibições recíprocas precisam ser aplicadas. Uma matriz de testes pode aceitar GTC fora, FAST-GTC dentro e rejeitar os dois arranjos invertidos. Trata-se de uma prática de verificação proposta, não de um requisito novo do RFC.

O RFC 5421 é Informational. As fontes públicas consultadas não demonstram prevalência atual, comportamento de fornecedores ou incidentes. A lição mais precisa é que, se um código é reutilizado sob um túnel, o enquadramento externo vira contexto operacional que o despachante não deve descartar.

Fontes