Resumo

  • Quando o servidor aceita retomar uma sessão TEAP, a RFC 9930 permite que toda a fase 2 seja pulada; o ticket precisa continuar ligado à autenticação interna e às credenciais que sustentam a autorização atual.
  • Se novas credenciais não puderem ser associadas ao ticket, o servidor deve invalidá-lo e forçar autenticação completa na próxima conexão.

Retomada de sessão resolve um custo concreto. Usuários e máquinas podem se autenticar várias vezes no mesmo dia, e repetir todos os métodos internos aumenta a carga sobre o serviço de identidades. A RFC 9930 exige que implementações TEAP ofereçam retomada e aponta ganhos de escala e estabilidade. Oferecer a capacidade, porém, não transforma qualquer ticket apresentado em uma ordem de aceitação.

Uma execução completa de TEAP separa dois momentos. Na fase 1, TLS estabelece um túnel protegido e autenticado. Na fase 2, métodos internos e TLVs podem autenticar máquina, usuário ou ambos, emitir ou trocar credenciais, fazer Crypto-Binding e trocar resultados protegidos. A RFC 6678 traz os requisitos para um método EAP tunelado padronizado, e a RFC 3748 define os papéis e resultados de EAP. A existência do túnel não prova a conclusão de tudo o que deveria ocorrer dentro dele.

A economia da retomada vem dessa distinção. Se o servidor concorda em retomar, a RFC 9930 diz que a fase 2 é inteiramente contornada. Se recusa, conclui um handshake TLS completo e ambas as partes devem prosseguir para a fase 2. O estado pode ficar no servidor ou em um ticket do lado do cliente, como no mecanismo da RFC 5077. Em TLS 1.3, a RFC 8446 usa NewSessionTicket para preparar estado relacionado a PSK para uma conexão futura. Esse objeto sustenta continuidade criptográfica, não a permanência automática da autorização.

O ticket também pode surgir antes da hora. A RFC 9427 observa que TLS 1.3 permite enviar NewSessionTicket depois do Finished do cliente, quando a autenticação interna do método tunelado talvez ainda nem tenha sido executada. Um cliente poderia obter o ticket, abandonar a sessão e tentar retomá-la sem concluir o controle interno. Por isso, o servidor não deve permitir retomada sem sucesso prévio da autenticação interna. Deve preferir adiar a emissão; quando a biblioteca TLS impede isso, precisa descartar ou invalidar tickets de sessões malsucedidas. Se o ticket não permite saber o resultado, o servidor deve presumir que a etapa não terminou e executar os métodos internos antes de conceder acesso.

Crypto-Binding não substitui essa decisão. Depois de cada método interno bem-sucedido, a RFC 9930 exige Intermediate-Result e Crypto-Binding. O Compound MAC liga participantes, túnel e sequência de autenticação, revelando certas substituições ou falhas de vínculo. Ele não escolhe VLAN, ACL, função, estado da conta ou serviço permitido. Mesmo após um Result TLV de sucesso, o par pode solicitar ação adicional se sua política não estiver satisfeita; o servidor responde conforme sua própria política.

O problema temporal continua após uma primeira sessão perfeitamente válida. A fase 2 pode fornecer ou alterar credenciais. A autorização posterior deve usar as credenciais autenticadas, não uma identidade anônima ou diferente da fase 1. A autorização correta também precisa ser aplicada na retomada: novas credenciais devem ser associadas ao ticket. Se a associação não puder ser feita, o servidor deve invalidar os tickets da sessão atual. A conexão seguinte volta ao caminho completo, permitindo que um novo ticket receba uma base de autorização atual e explicável.

A RFC 9190 estende a análise a outros dados que mudam entre o handshake original e a retomada: informações sobre o par, o autenticador e as camadas ao redor. Se a mudança puder alterar autorização, contabilização ou política, a decisão deve ser reavaliada. Quando não houver decisão segura, a retomada deve ser rejeitada e o handshake completo retomado. O teto de sete dias para um ticket TLS 1.3 não é uma concessão de acesso por sete dias.

O registro operacional precisa reconstruir a cadeia: hash do ticket ou Session ID, emissor, emissão e expiração, sessão completa de origem, sucesso interno, versões de credencial e política, contexto do autenticador, mudanças ocorridas, reavaliação e motivo de aceitação, recusa ou invalidação. Depois vêm, em registros separados, a autorização atual, o comprovante de aplicação pelo NAS e a observação de tráfego ou serviço. A RFC 5247 organiza o contexto de chaves e identidades EAP, mas não comprova esses efeitos posteriores.

O princípio de especificação inicial mínima de Heng Lu preserva o limite: o ticket compartilhado carrega somente o estado limitado necessário à interoperabilidade. A decisão futura continua local e atribuível. O código em execução deve mostrar o que consultou de fato, e as camadas da realidade não podem ser fundidas: ticket, credencial autenticada, política atual, autorização, aplicação e resultado. Retomada confiável é trabalho poupado com justificativa verificável.

Sources