Resumo

  • A autenticação atrasada da RFC 3118 dependia de um segredo compartilhado, provisionado fora de banda para cliente e servidor DHCP do mesmo domínio administrativo.
  • O cliente ainda podia aceitar uma oferta sem autenticação se a política local permitisse; o RFC recomendou que pudesse recusá-la e que essa fosse a configuração padrão.

A opção não criou uma identidade universal

O DHCP costuma ser lembrado como o protocolo que permite a um dispositivo entrar na rede e receber endereço e outros parâmetros. Essa conveniência também traz um problema de confiança. Um servidor malicioso ou iniciado por engano pode oferecer gateway, resolvedor ou endereço incorretos. O servidor, por sua vez, pode enfrentar um cliente que se passa por autorizado ou tenta esgotar o conjunto de endereços. Publicada em junho de 2001, a RFC 3118 buscou autenticar a origem e o conteúdo das mensagens DHCP sem redesenhar o protocolo.

A opção 90 colocava no pacote o protocolo, o algoritmo, o método de detecção de repetição, o valor de replay e as informações de autenticação. Embora parecesse uma única opção, ela reunia perguntas distintas: qual procedimento estava em uso, como reconhecer uma mensagem antiga e que segredo vinculava o pacote ao interlocutor?

A RFC 3118 distinguiu um token simples de configuração da autenticação atrasada. O token fornecia autenticação fraca da entidade, mas não autenticava a mensagem; o documento o descreveu como proteção rudimentar contra servidores DHCP ativados inadvertidamente. O mecanismo atrasado usava HMAC-MD5 e segredo compartilhado. Esta é uma descrição da escolha histórica, não uma recomendação para novos sistemas.

A autenticação começava antes da descoberta

Na autenticação atrasada, o cliente solicitava o mecanismo em DHCPDISCOVER. O servidor escolhia um segredo e devolvia as informações de autenticação em DHCPOFFER. O cliente selecionava uma oferta e enviava DHCPREQUEST com o segredo correspondente; depois, precisava validar uma confirmação autenticada. A detecção de repetição fazia parte da troca, para impedir que uma etiqueta válida de um pacote antigo fosse simplesmente copiada e reapresentada.

Isso exigia uma relação anterior ao primeiro pacote. A RFC 3118 previa que o cliente recebesse sua chave por um canal fora de banda. O servidor precisava conhecer, ou obter com segurança, as chaves de clientes autorizados. Se muitos compartilhassem o mesmo segredo, qualquer detentor poderia se passar por outro; onde a identidade individual importava, o RFC pedia chaves únicas. A troca em rede, portanto, dependia de um sistema de provisionamento que o DHCP não definia.

O limite era deliberado. A RFC 3118 não tratou do roaming entre domínios administrativos. Seu foco era o uso dentro de um domínio, onde o compartilhamento de segredos por outro canal era viável, e o documento alertou que a solução talvez não escalasse bem para clientes que acessassem vários domínios. Um MAC confirmava que a mensagem correspondia a uma chave configurada; não criava uma identidade global, acordo de roaming nem direito de usar qualquer rede.

Retransmissores e aceitação local também faziam parte do modelo

Relés DHCP podem alterar giaddr e hops e acrescentar informações do próprio relé. A RFC 3118 especificou como tratar esses campos no cálculo da autenticação para que o processamento legítimo do relé não invalidasse a verificação. Isso definiu como atravessar intermediários; não transformou cada relé em autoridade de identidade.

O tratamento sem autenticação é ainda mais revelador. Se nenhuma oferta tivesse autenticação válida, a política local do cliente podia permitir uma oferta sem autenticação. O RFC exigiu que clientes pudessem ser configurados para recusá-las e recomendou que essa fosse a configuração padrão. Se o cliente aceitasse uma, o texto aconselhava informar o usuário e registrar o evento. A segurança também dependia da política de fallback, e não apenas do MAC da opção.

É fácil confundir a presença de uma opção de autenticação com a garantia de que toda configuração aceita foi autenticada. A RFC 3118 alertou contra essa conclusão. Ela especificou um mecanismo e um padrão cauteloso, mas deixou a escolha local de confiança para administradores e implementações clientes.

O registro não mostra quantos clientes e servidores implementaram ou configuraram a opção 90, nem mede quanto ela reduziu ataques. Um padrão define um comportamento possível; adoção e resultado exigem evidências diferentes. A contribuição histórica da RFC 3118 é mais estreita: a autenticação DHCP continuou sendo um arranjo local, limitado por quem provisionava o segredo, pelos servidores e relés incluídos e pela decisão de aceitar uma alternativa sem assinatura.

Fontes

  1. https://www.rfc-editor.org/rfc/rfc3118.html
  2. https://www.rfc-editor.org/info/rfc3118
  3. https://datatracker.ietf.org/doc/rfc3118/
  4. https://www.rfc-editor.org/rfc/rfc2131.html
  5. https://www.rfc-editor.org/rfc/rfc2132.html
  6. https://www.rfc-editor.org/rfc/rfc3046.html
  7. https://www.rfc-editor.org/rfc/rfc2104.html
  8. https://www.rfc-editor.org/rfc/rfc1321.html
  9. https://www.rfc-editor.org/rfc/rfc2119.html
  10. https://www.rfc-editor.org/rfc/rfc951.html
  11. https://www.rfc-editor.org/rfc/rfc4361.html
  12. https://www.rfc-editor.org/rfc/rfc6842.html
  13. https://www.rfc-editor.org/rfc/rfc8415.html
  14. https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml