Кратко

  • Отложенная аутентификация RFC 3118 зависела от секрета, заранее переданного по отдельному каналу клиенту DHCP и серверу внутри одного административного домена.
  • При разрешении локальной политики клиент всё ещё мог принять неаутентифицированное предложение; RFC рекомендовал дать возможность его отклонить и сделать отказ настройкой по умолчанию.

Опция не создавала универсальную идентичность

DHCP обычно вспоминают как протокол, который выдаёт подключившемуся устройству адрес и другие параметры. Но такое удобство создаёт проблему доверия: злоумышленный или ошибочно запущенный сервер может предложить неверный шлюз, DNS-сервер или адрес. Сервер, в свою очередь, может столкнуться с клиентом, который выдаёт себя за разрешённый или пытается исчерпать пул адресов. RFC 3118, опубликованный в июне 2001 года, стремился аутентифицировать источник и содержимое сообщений DHCP, не перестраивая сам протокол.

Опция 90 поместила в пакет селектор протокола, алгоритм, метод обнаружения повторов, значение для такой проверки и данные аутентификации. За одной опцией стояли разные вопросы: какой механизм используется, как распознать старое сообщение и какой секрет связывает пакет с собеседником.

RFC 3118 различал простой конфигурационный токен и отложенную аутентификацию. Токен давал слабую аутентификацию сущности, но не аутентифицировал сообщение; документ называл его лишь базовой защитой от случайно запущенного DHCP-сервера. Отложенный механизм применял HMAC-MD5 и общий секрет. Здесь зафиксирован исторический выбор, а не рекомендация для новых систем.

Аутентификация начиналась до обнаружения

При отложенной аутентификации клиент запрашивал её в DHCPDISCOVER. Сервер выбирал секрет и возвращал данные аутентификации в DHCPOFFER. Клиент выбирал предложение и отправлял DHCPREQUEST с соответствующим секретом; затем он должен был проверить аутентифицированное подтверждение. Проверка повторов входила в обмен, поэтому нельзя было просто скопировать действительный тег со старого пакета и предъявить его снова.

Отношения доверия, таким образом, требовались ещё до первого пакета. RFC 3118 предполагал передачу ключа клиенту вне полосы DHCP. Сервер должен был знать ключи авторизованных клиентов или безопасно их получать. Если секретом широко делились, любой его обладатель мог выдать себя за другого; для различения отдельных клиентов документ требовал уникальных ключей. Сетевой обмен зависел от системы распределения ключей, которую сам DHCP не определял.

Граница была намеренной. RFC 3118 не решал задачу роуминга между административными доменами. Он был нацелен на применение внутри домена, где отдельная передача секрета осуществима, и предупреждал, что работа с несколькими доменами может плохо масштабироваться. MAC подтверждал соответствие сообщения настроенному ключу, но не создавал глобальную идентичность, соглашение о роуминге или право использовать любую сеть.

Ретрансляторы и локальный выбор тоже входили в модель доверия

DHCP-ретрансляторы могут изменять giaddr и hops и добавлять информацию ретранслятора. RFC 3118 определил, как учитывать эти поля при вычислении аутентификации, чтобы штатная обработка ретранслятором не ломала проверку. Путь через посредников стал определённым, но каждый ретранслятор от этого не превратился в центр идентификации.

Особенно показателен выбор при отсутствии аутентификации. Если ни одно предложение не содержало действительной аутентификации, локальная политика могла разрешить принять неаутентифицированное. RFC требовал, чтобы клиент можно было настроить на отказ от таких сообщений, и рекомендовал этот режим по умолчанию. Если клиент всё же принимал сообщение, документ советовал уведомить пользователя и записать событие. Следовательно, безопасность зависела и от локального решения о переходе на запасной режим, а не только от MAC в опции.

Сам факт наличия опции аутентификации не гарантирует, что каждая принятая конфигурация была аутентифицирована. RFC 3118 предостерегал от такого вывода. Он описал механизм и осторожную настройку по умолчанию, но оставил локальный выбор доверия администраторам и клиентским реализациям.

Источники не показывают, сколько клиентов и серверов реализовали или включили опцию 90, и не измеряют сокращение атак. Стандарт задаёт возможное поведение, а распространение и результат требуют отдельного подтверждения. Исторический вывод RFC 3118 уже: аутентификация DHCP оставалась локальным соглашением доверия, ограниченным тем, кто выдавал секреты, какие серверы и ретрансляторы входили в область действия и принимал ли клиент вариант без подписи.

Источники

  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