Resumo

  • TLS-POK, da RFC 9966, faz o servidor demonstrar conhecimento da BSK pública de um equipamento e o equipamento demonstrar posse da chave privada correspondente.
  • A norma não define como o servidor recebeu essa chave pública e não transforma a prova em evidência de proprietário, custódia, política de rede ou acesso efetivamente concedido.

O primeiro acesso de um equipamento novo pode ser uma armadilha circular. Para entrar numa rede com EAP, ele precisa de uma credencial; para receber a credencial, pode precisar entrar na rede. Dan Harkins e Owen Friel propõem na RFC 9966 uma passagem limitada para esse início em ambiente cabeado. O mecanismo, chamado TLS Proof of Knowledge ou TLS-POK, usa uma Bootstrap Key, BSK, dentro de uma sessão TLS 1.3 antes de uma credencial de uso posterior.

A BSK é um par de chaves elípticas. A parte privada deve ser conhecida apenas pelo dispositivo. A pública é conhecida pelo dispositivo e por seu dono ou detentor e é provisionada no servidor TLS pelo operador daquele servidor. Na troca, o servidor prova ao cliente que conhece a chave pública; o cliente prova ao servidor que guarda a privada. A EPSK é derivada da parte pública, e o cliente usa a BSK como chave pública bruta durante a autenticação. Isso resolve uma questão sobre conhecimento de chaves, não sobre a legitimidade administrativa de todos os fatos anteriores.

O documento faz questão de deixar o fato anterior sem maquiagem. O meio exato pelo qual o servidor adquiriu a BSK pública está fora de escopo. Uma leitura de QR code e o envio de uma lista de materiais, BOM, são apenas possibilidades. Quando o QR está preso fisicamente ao dispositivo, o modelo assume que posse física significa propriedade legítima. A assunção pode servir de ponto de partida, mas não é uma verificação que o handshake executou sobre compra, recebimento, transporte, revenda ou inventário.

É por isso que a advertência de segurança não pode ser reduzida a detalhe. A confiança do cliente depende de sua chave pública BSK não estar disseminada. Quem conhece a chave e consegue atrair o cliente para um servidor hostil pode completar TLS-POK e se apresentar como a rede de bootstrap. Há ainda uma falha de associação: se a chave pública de um dispositivo honesto for substituída por uma de dispositivo malicioso durante o bootstrap, o servidor poderá integrar o dispositivo errado. A criptografia confirma o material que recebeu; não certifica a origem daquele material.

As regras práticas mantêm essa diferença visível. O cliente só pode enviar sua BSK pública depois de processar ServerHello e verificar o cronograma de chaves TLS; se a verificação PSK falhar, deve encerrar sem expô-la. Cada fabricante deveria usar uma BSK única para cada dispositivo. Quando vários equipamentos dividem a mesma BSK, o operador não consegue distingui-los nem assegurar que apenas unidades específicas e autorizadas se conectem. São controles de exposição e diferenciação, não uma escritura de propriedade.

Depois da sessão, o servidor pode provisionar uma credencial para futuras autenticações EAP. A BSK, contudo, é usada somente durante o bootstrap. Logo, proveniência da chave, provisionamento do servidor, êxito TLS, emissão de credencial, decisão EAP e aplicação no ponto de acesso precisam continuar como registros ligados, mas independentes. Uma linha de log bem-sucedida não prova todos os elos restantes.

O perfil público de Harkins no IETF estabelece sua conexão documental com a RFC; a página de reconhecimento IEEE 802.11 oferece a referência pública para o retrato editorial da pessoa. Esses dados não atribuem a ele controle sobre equipamentos ou implantações. O texto que ele coassinou vale porque limita o que uma prova inicial pode alegar.

Fontes