Resumo

  • O RFC 5281 divide o EAP-TTLSv0 em um handshake TLS e uma fase de dados protegidos. No ramo usual de TLS unilateral, a fase 1 autentica o servidor TTLS; a identidade real e a prova do assinante só chegam na fase 2.
  • Um recibo de acesso defensável precisa unir identidade externa de roteamento, validação do certificado, método e identidade internos, decisão AAA, autorização, entrega de chaves, aplicação no ponto de acesso e tráfego observado. Nenhum sucesso anterior prova sozinho o desfecho posterior.

O canal ficou pronto antes da alegação de identidade

A fase 1 do EAP-TTLSv0 é o handshake TLS. O servidor TTLS apresenta seu certificado; o cliente verifica a cadeia, o nome esperado e a política de confiança. Um certificado do cliente é opcional. Depois de ChangeCipherSpec e Finished, a camada de registros pode proteger as mensagens seguintes.

Esse marco responde a uma pergunta limitada: o cliente abriu um canal cifrado para o endpoint TTLS que aceitou como servidor. No ramo sem certificado de cliente, ainda não há uma conclusão sobre o assinante. A fase 2 transporta AVPs que podem conter usuário, prova de senha, EAP interno, validação de integridade, configuração ou provisionamento.

A ordem é o contrato. “TLS estabelecido” quer dizer que há um caminho protegido para apresentar a alegação. Não quer dizer que o AAA doméstico aceitou a pessoa, que a política foi autorizada, que o ponto de acesso instalou as chaves nem que uma aplicação funcionou.

O contexto histórico também importa. O RFC 5281 é Informational e descreveu prática implantada. O RFC 8996 passou a proibir TLS 1.0 e 1.1, e o RFC 9427 atualizou a derivação de chaves e o tratamento de resultados do EAP-TTLS para TLS 1.3. A modernização criptográfica não transforma a primeira fase em prova do que só acontece depois.

A primeira identidade pode ser apenas um endereço de encaminhamento

Antes do túnel, o ponto de acesso normalmente pede uma EAP-Response/Identity em claro. Para reduzir exposição, o cliente pode omitir o usuário verdadeiro, responder com um marcador anônimo e manter apenas o realm necessário para levar a tentativa ao provedor correto.

Esse valor externo é útil para roteamento. Ele informa a direção administrativa da conversa, não a identidade autenticada do assinante. O identificador interno aparece no canal protegido e chega à autoridade que avalia a credencial.

Um registro com uma única coluna chamada identity destrói essa diferença. Se o nome interno sobrescrever o externo, desaparece a trilha de roteamento. Se ficar apenas o anônimo externo, a decisão do AAA parecerá pertencer a um marcador. Os dois valores devem ser preservados com função, observador, instante e transação.

O túnel acaba no terminador TTLS

Os AVPs internos ficam protegidos por TLS até o servidor TTLS. Ali são recuperados em texto claro e, quando necessário, encaminhados ao AAA/H por RADIUS, Diameter ou outro protocolo transportador de AAA. Terminador e AAA doméstico podem estar no mesmo sistema, mas não precisam estar; proxies também podem compor o caminho.

Assim, a proteção TLS externa não é uma caixa cifrada contínua entre o cliente e toda autoridade de backend. O trecho posterior tem seus próprios controles de identidade, confidencialidade, integridade e autorização. Uma auditoria que mostra apenas o cadeado do túnel deixa justamente esse trecho sem evidência.

O terminador ocupa uma superfície de controle. Ele vê o material interno, traduz contextos de AVP e decide o que repassar. O RFC 5281 alerta que códigos de atributo iguais não garantem significado igual: o servidor não deve copiar um AVP entre EAP-TTLS e o protocolo backend sem entender as duas semânticas. Compatibilidade de formato não é preservação de intenção.

Um resultado de autenticação pode agregar várias decisões

O AAA/H pode desafiar, aceitar ou rejeitar. Um desafio retorna pelo terminador ao canal protegido e gera outra resposta. Só após a sequência exigida pela política surge uma conclusão que o servidor TTLS converte no resultado EAP externo.

Também pode haver mais de um método interno: senha seguida de token, por exemplo. Se todos devem passar ou se um basta é uma escolha de política. Dizer apenas “método interno aprovado” omite a sequência, os resultados individuais e a regra que os reduziu a uma decisão.

Existem ramos legítimos sem fase 2. Um certificado do cliente na fase 1 pode ser suficiente, ou uma sessão retomada pode herdar uma autenticação anterior bem-sucedida. A ausência do transcript interno, sozinha, não é falha. O observador precisa registrar qual ramo autorizou a omissão e a identidade histórica herdada.

O erro inverso é grave: guardar como retomável uma sessão que completou TLS e depois falhou na autenticação do usuário. O RFC 5281 chama a consequência de catastrófica. A entrada de cache precisa nascer do êxito do assinante, não da mera conclusão do handshake.

Derivar material de chave não concede acesso

O segredo TLS e os valores aleatórios permitem derivar MSK e EMSK. Ao final de uma autenticação bem-sucedida, material de chave e autorização seguem para o ponto de acesso pelo caminho AAA.

São fatos diferentes. O software pode calcular bytes candidatos antes de a política permitir seu uso. A chave pode ser associada à sessão errada, chegar com uma geração de autorização antiga, não ser instalada ou proteger um enlace que continua sem serviço útil.

Por isso, “a chave foi gerada” é uma pergunta insuficiente. O recibo deve mostrar qual transcript e quais identidades a produziram, qual decisão liberou sua distribuição, qual sessão do ponto de acesso a consumiu, quais restrições a acompanharam e qual tráfego confirmou o efeito pretendido.

O sucesso sai por caminhos distintos

Quando o AAA/H aceita o assinante, o cliente normalmente recebe EAP-Success. Já o ponto de acesso recebe, pelo transportador AAA, o resultado, as chaves e parâmetros como rede lógica, filtros, prazo e limites. As mensagens são relacionadas, mas têm destinos e observadores diferentes.

EAP-Success no cliente não comprova que o ponto de acesso aplicou a mesma política. Um Access-Accept recebido pelo ponto de acesso não comprova que filtros ou VLAN foram instalados. Mesmo a proteção do enlace não garante endereço, rota, DNS ou alcance da aplicação.

Para fechar a frase “o acesso foi restaurado”, é preciso ler o estado do executor e observar tráfego bidirecional; se a promessa pública menciona um serviço, deve-se observar também esse serviço. A autoridade de identidade só pode atestar a decisão que tomou, não todos os efeitos que não viu.

Dois êxitos ainda podem não pertencer ao mesmo contexto

O RFC 5281 reconhece uma limitação do EAP-TTLSv0 básico: não há binding criptográfico entre a autenticação TLS externa e a interna. Uma prova de credencial que também seja aceita fora do túnel pode ser retransmitida em outro contexto. O documento recomenda evitar essa reutilização e empregar extensões que amarrem as camadas.

Isso não torna toda sessão EAP-TTLS falsa. Mostra que “as duas etapas passaram” é mais fraco do que “as etapas foram vinculadas à mesma sessão e aos mesmos participantes”. Garantias de métodos encapsulados posteriores não podem ser retroativamente atribuídas ao contrato básico.

Monte o recibo na ordem em que a autoridade muda de mãos

Uma decisão de acesso consequente deveria preservar:

  • identidades do cliente, ponto de acesso, servidor TTLS e AAA/H;
  • identidade externa em claro, realm e caminho de proxies;
  • cadeia do certificado do servidor, política de nome esperado e resultado;
  • versão TLS, suíte, transcript e conclusão da fase 1;
  • presença de certificado do cliente e papel que ele exerceu;
  • sessão nova ou retomada, com autenticação e autorização herdadas;
  • identidade interna, sequência dos métodos, desafios e resultados;
  • identificador da transação TTLS–AAA e proteção do transportador;
  • accept ou reject, geração de política e autorização devolvida;
  • EAP-Success ou EAP-Failure observado pelo cliente;
  • entrega do MSK e vínculo com a sessão correta no ponto de acesso;
  • filtros, rede, tempo e banda efetivamente instalados;
  • proteção do enlace e tráfego bidirecional observado; e
  • resultado de aplicação exigido pela afirmação operacional.

O recibo precisa poder parar em qualquer fronteira. Um túnel seguro pode coexistir com um assinante rejeitado. Um assinante aceito pode coexistir com falha de execução. Um enlace protegido pode coexistir com serviço inútil. Separar essas verdades impede que o primeiro verde se aproprie do último resultado.

Sources