Resumo

  • RFC 5418 apresenta a segurança do CAPWAP como várias relações bilaterais entre estação sem fio, serviço AAA, controlador de acesso e ponto de terminação sem fio. Proteger cada ligação não cria automaticamente uma autorização de ponta a ponta.
  • Com uma chave pré-compartilhada, a autorização pode valer para uma classe inteira de equipamentos. A posse da chave não necessariamente diferencia um controlador de um ponto de terminação.
  • Um certificado válido, um canal de controle protegido e a autorização para entrar em determinada rede são fatos distintos. Cadastro, papel, credenciais AAA e rota dos dados exigem verificações próprias.

A credencial pode autenticar o par e deixar o papel em aberto

Quando AC e WTP usam chaves pré-compartilhadas, a lista de dispositivos confiáveis pode reconhecer uma classe sem provar qual função cada integrante exerce. Em CAPWAP, essa distinção importa porque controlador e ponto de terminação ocupam lugares diferentes na arquitetura. RFC 5418 trata a identificação de papel como uma decisão própria, além da autenticação do par.

Essa diferença ajuda a ler RFC 5418, uma análise Informational publicada em 2009 sobre o que muda quando um ponto de acesso autônomo é dividido em dois elementos: o Wireless Termination Point (WTP), na borda sem fio, e o Access Controller (AC), localizado em outro ponto. Interações que antes aconteciam dentro de um único equipamento passam a atravessar uma rede de camada 3. A segurança depende da rede intermediária e de como as funções são distribuídas entre WTP e AC.

O escopo é específico: ameaças ao CAPWAP no contexto de IEEE 802.11. O texto não é uma pesquisa de produtos instalados, um relato de ataque nem um Internet Standard. Sua contribuição está em separar perguntas que um diagrama de arquitetura costuma condensar: quem é o outro equipamento, que papel pode exercer, quais chaves recebe e por onde os dados do cliente realmente passam?

A lente editorial vem da Nota 65 de Heng Lu, “Running-Code Primacy”: confrontar a afirmação com o que o sistema executa e com aquilo que o operador consegue verificar. A nota trata do desenho de sistemas de coordenação da Internet, não de requisitos para redes sem fio. Aplicada aqui, ela lembra que um diagrama ou uma política declarada não substituem a evidência sobre credenciais, papéis, relações entre controladores e encaminhamento efetivamente instalado.

O CAPWAP acrescenta relações de confiança

Em um ponto de acesso convencional, um único equipamento conecta a borda sem fio à rede cabeada. O CAPWAP separa essas funções: o WTP transmite e recebe o tráfego sem fio; o AC concentra o controle e as funções do lado cabeado. A separação facilita a gestão centralizada e diferentes arquiteturas de filial, mas cria mais relações de confiança.

O exemplo simplificado de RFC 5418 inclui pelo menos sete relações ou transferências de chave:

Etapa Relação ou transferência O que estabelece no exemplo
1 WTP–AC Uma relação entre pares CAPWAP
2 AC–AAA O enlace autenticado do controlador com o serviço de autenticação
3 Estação–AAA Autenticação EAP e geração de material de chave
4 AAA → AC Entrega de uma chave mestra por pares ao controlador
5 AC–estação Troca de quatro etapas que gera chaves temporárias
6 AC → WTP Entrega de uma chave temporária se a criptografia for descentralizada
7 WTP–estação Segurança do enlace sem fio do cliente

Não é uma negociação única de ponta a ponta. RFC 5418 ressalta que cada item é uma relação bilateral. A estação confiar no AAA, o AAA confiar no AC e o AC confiar no WTP não significa que a estação deva confiar automaticamente nesse WTP. Um WTP comprometido pode manter sua relação com o AC e ainda apresentar informações enganosas ao cliente. Um dispositivo comprometido na hierarquia pode afetar os elementos abaixo dele.

Essa é uma propriedade da arquitetura, não a afirmação de que toda rede foi comprometida. A análise deve acompanhar cada identidade e cada chave até os privilégios que concedem e avaliar o que um nó comprometido conseguiria fazer.

O que uma chave compartilhada comprova — e o que não comprova

RFC 5418 separa autenticação e autorização. A autenticação pergunta se o outro lado consegue comprovar uma identidade ou a posse de uma credencial. A autorização determina os recursos e as ações disponíveis.

Para chaves pré-compartilhadas, o documento descreve uma autorização ampla e pouco granular: conhecer a chave inclui o equipamento em uma classe confiável. Separar classes com chaves distintas pode ajudar, mas a chave da classe ainda não necessariamente comprova se quem a possui é um AC ou um WTP. Se os dois papéis aceitam o mesmo segredo, quem o obtiver pode reivindicar qualquer um deles, a menos que outro controle limite a tentativa.

O risco cresce quando a mesma credencial circula além do inventário. Uma chave copiada para o provisionamento de fábrica, as anotações de preparação, a configuração do controlador e o procedimento de substituição deixa de ser uma propriedade de um equipamento: vira uma capacidade compartilhada. O impacto depende de quem pode obtê-la, de como as classes são separadas, de como ocorre a rotação e de como o receptor verifica o papel declarado. RFC 5418 não diz que uma operadora específica adota essas práticas; são perguntas para a própria organização responder.

Certificados permitem verificações mais específicas, mas o documento não trata sua mera apresentação como uma política completa de cadastro. Ele descreve um nome de sujeito com o endereço MAC e bits Extended Key Usage que diferenciam AC de WTP. Isso ajuda quando o receptor confirma que o nome pertence a esta rede e aplica a finalidade do certificado de forma estrita. Aceitar uma finalidade genérica pode eliminar a separação de papéis sem controles adicionais sobre o nome.

Um certificado do fabricante comprova sua origem, não a autorização dada pela empresa que opera a rede. Qual AC um WTP deve aceitar nesta instalação? Quais WTPs pertencem a este ambiente? RFC 5418 observa que a autorização baseada em certificados e a configuração sem intervenção não se encaixam perfeitamente. A análise parte do pressuposto de que cada lado consegue identificar o par correto; ela não resolve como estabelecer essa escolha inicial. Essa premissa deve permanecer explícita em compras e revisões de segurança.

O AAA exige outro responsável

No exemplo, o AC atua como autenticador e conversa com o servidor AAA via RADIUS ou Diameter. RFC 5418 alerta que credenciais de longa duração, pouco aleatórias ou reutilizadas no enlace AC–AAA podem afetar seriamente a segurança de todo o ambiente. Recomenda um enlace com autenticação mútua, confidencialidade e integridade, e remete à orientação de gerenciamento de chaves AAA em RFC 4962.

Essa proteção se aplica a uma relação diferente da que une WTP e AC. Uma sessão DTLS válida entre os dois não autentica automaticamente o AAA escolhido pelo controlador. Um método EAP forte entre estação e AAA não demonstra que apenas o controlador previsto recebe as chaves resultantes. Um enlace sem fio bem-sucedido tampouco comprova que a chave foi enviada ao WTP correto. A operadora precisa atribuir responsabilidade a cada credencial e decisão de autorização.

Há também uma questão de organização. O time sem fio pode cadastrar equipamentos; segurança pode administrar certificados; identidade pode operar AAA. Cada grupo pode informar que sua ligação está protegida sem que alguém confira como as garantias se conectam. Um registro útil associa cada relação a quem emite a credencial, quem a valida, qual papel concede e qual evidência prova que o equipamento pertence ao ambiente.

O túnel de controle não revela o caminho dos dados

Identidade e distribuição de chaves não descrevem toda a arquitetura. RFC 5418 separa o plano de controle do encaminhamento de dados e aborda Split MAC, Local MAC e outros cenários. No modo Local MAC, o WTP executa a maior parte do processamento MAC, e as tramas de dados em geral são conectadas à rede localmente. Os termos do CAPWAP não determinam sozinhos todos os detalhes do túnel de dados.

RFC 5415 define a fronteira do protocolo: Discovery Request e Discovery Response não usam DTLS para que o WTP encontre controladores candidatos; as demais mensagens de controle CAPWAP devem usar DTLS. Já a proteção dos pacotes de dados é opcional e depende da política do AC. Por isso, uma associação de controle protegida não prova que o tráfego dos clientes passe pelo AC, use um canal de dados criptografado ou seja entregue localmente à rede cabeada.

A decisão muda onde as regras são aplicadas. O encaminhamento central pode oferecer ao controlador um ponto de controle, mas adiciona percurso e dependência. A ponte local evita levar todo o tráfego a um controlador distante, mas aproxima segmentação, inspeção e monitoramento da borda e da rede cabeada conectada. São opções com custos diferentes, não recomendações universais. A revisão precisa comparar o caminho real com aquele pressuposto pelas políticas e pelo plano de resposta a incidentes.

DTLS também não elimina toda ameaça. RFC 5418 discute exaustão de recursos, observação passiva, análise de tráfego e interferência que descarta pacotes. Cita ainda ataques fora do CAPWAP, como falsificação de DNS ou DHCP e envenenamento de cache ARP. Esses limites não tornam DTLS inútil; mostram onde sua proteção termina e outro responsável precisa agir.

A revisão eficaz percorre as relações

Uma revisão CAPWAP começa pela topologia real e responde:

  1. Quais ACs cada WTP aceita? Como se comprova que pertencem a esta instalação?
  2. Quais WTPs cada AC aceita? Como os papéis são diferenciados?
  3. As chaves compartilhadas são exclusivas e limitadas o bastante para a classe que representam? Quem pode consultá-las, instalá-las, trocá-las ou revogá-las?
  4. Que verificações de nome e papel os equipamentos realmente aplicam? O que ocorre quando o certificado é válido, mas não consta na lista da instalação?
  5. Quais credenciais o AC usa com o AAA e onde ficam registrados o envio de chaves e sua autorização?
  6. Os dados dos clientes passam pelo AC ou são conectados localmente? Onde ficam criptografia, segmentação, inspeção e registros?
  7. Que riscos permanecem mesmo com DTLS: exaustão de recursos, análise de tráfego, descarte de pacotes, manipulação da descoberta ou ataque à LAN adjacente?

Essas perguntas transformam “a WLAN usa certificados” em afirmações verificáveis. Na substituição de um ponto de acesso, atualize inventário e autorização de papel; a assinatura do fabricante é só uma parte. Se uma filial migrar para ponte local, o plano de aplicação e monitoramento deve acompanhar os pacotes. Uma rotação da credencial AC–AAA não deve destruir sem aviso a identidade WTP–AC nem fechar um caminho de contingência.

Respeitar o limite do documento

RFC 5418 é uma análise de 2009 sobre CAPWAP e 802.11. Seus exemplos criptográficos e sua terminologia não devem ser copiados como configuração atual. RFC 5415 especifica o CAPWAP; RFC 5418 analisa a exposição criada ao dividir as funções do ponto de acesso. Nenhum dos dois comprova o que um fabricante fornece hoje, como uma rede está configurada ou que houve um incidente.

A contribuição analítica permanece mais estreita: um enlace protegido é uma aresta no grafo de confiança. A pergunta não é quantas arestas exibem um cadeado, mas se cada identidade aceita corresponde à instalação, ao papel e aos privilégios corretos — e se os dados dos clientes percorrem a rota que a organização pensa administrar. Possuir uma credencial não é o mesmo que governar o sistema que ela abre.

Fontes