Аннотация
Расширения безопасности DNS (DNSSEC) были разработаны для обеспечения аутентификации источника и защиты целостности данных DNS с использованием цифровых подписей. Эти цифровые подписи могут быть созданы с использованием различных алгоритмов. Этот документ определяет способ проверки распознавателей конечной системы, чтобы сообщить серверу, какие цифровые подписи и алгоритмы хеширования они поддерживают. Расширения позволяют сигнализировать о новом использовании алгоритма в клиентском коде, что позволяет администраторам зоны знать, когда можно завершить перенос алгоритма в зоне, подписанной DNSSEC.
Скачать оригинальный документ на английском языке RFC 6975 PDF
Оглавление
1. Введение
2. Требования к языку
3. Сигнализация DNSSEC Алгоритм Понятно (DAU), DS Хэш-Понятно (DHU), и NSEC3 Хэш-Понятно (N3U) Используя EDNS
4. Вопросы клиентов
4.1. Заглушки резольверов
4.1.1. Проверка правильности резольверов
4.1.2. Непроверяемые заглушки резольверов
4.2. Рекурсивные резольверы
4.2.1. Проверка рекурсивных резольверов
4.2.2. Не проверяющие рекурсивные резольверы
5. Промежуточные системные соображения
6. Особенности сервера
7. Анализ трафика
8. Соображения IANA
9. Вопросы безопасности
10. Нормативные документы
Адрес автора
Статус этой заметки
Это документ по отслеживанию стандартов Интернета.
Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.
Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc6975.
Уведомление об авторских правах
Copyright (c) 2013 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.
На данный документ распространяется действие ППГ 78 и Правовые положения IETF Trust, касающиеся документов IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны содержать текст Упрощенной лицензии BSD, как описано в Разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.
1. Введение
Расширения безопасности DNS (DNSSEC), [RFC4033], [RFC4034] и [RFC4035] были разработаны для обеспечения аутентификации источника и защиты целостности данных DNS с использованием цифровых подписей. Каждая запись ресурса (RR) цифровой подписи (RRSIG) содержит кодовый номер алгоритма, который соответствует RR открытого ключа DNSSEC (DNSKEY). Эти коды алгоритмов сообщают валидаторам, какой криптографический алгоритм использовался для генерации цифровой подписи.
Аналогично, записи RR подписывающего делегирования (DS) и записи отказа в существовании с хэшированной аутентификацией (NSEC3) используют хеш-значение как часть своих данных записи ресурса (RDATA), и, подобно алгоритмам цифровой подписи, эти алгоритмы хеширования имеют кодовые номера. Все три кода алгоритмов (RRSIG / DNSKEY, DS и NSEC3) хранятся в уникальных реестрах IANA.
Этот набор документов определяет способ проверки распознавателей конечной системы, чтобы сообщить серверу в запросе DNS, какие алгоритмы цифровой подписи и / или хеширования они поддерживают. Это делается с использованием новых опций механизмов расширения для DNS (EDNS0), указанных ниже в разделе 2 для использования в мета-RR OPT [RFC6891]. Эти три новых кода опции EDNS0 являются необязательными для реализации и использования.
Эти предложенные варианты EDNS0 служат для измерения принятия и использования новых алгоритмов цифровой подписи. Эти параметры сигнализации могут использоваться администраторами зон в качестве индикатора для измерения успешного развертывания кода, который реализует недавно развернутый алгоритм цифровой подписи, хэш DS и алгоритм хеширования NSEC3, используемый с DNSSEC. Администратор зоны может определить, когда следует прекратить подписывание с помощью замененного алгоритма, когда сервер видит, что значительное число его клиентов сигнализирует о том, что они могут принять новый алгоритм. Обратите внимание, что это обследование может проводиться в течение нескольких лет, прежде чем наступит переломный момент.
Этот документ не стремится представить другой процесс для включения новых алгоритмов для использования с DNSSEC. В нем также не рассматривается вопрос о том, какие алгоритмы должны быть включены в какой-либо официальный список обязательных или рекомендуемых криптографических алгоритмов для использования с DNSSEC. Скорее этот документ определяет средства, с помощью которых клиентский запрос может сигнализировать набор алгоритмов и хэшей, которые он реализует.
2. Требования к языку
Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].
3. Сигнализация DNSSEC Алгоритм Понятно (DAU), DS Хэш-Понятно (DHU), и NSEC3 Хэш-Понятно (N3U) Используя EDNS
Спецификация EDNS0, изложенная в [RFC6891], определяет способ включения новых опций с использованием стандартизированного механизма. Эти параметры содержатся в RDATA мета-RR OPT. Этот документ определяет три новых варианта EDNS0 для клиента, чтобы указать, какие алгоритмы цифровой подписи и / или хэш-функции клиент поддерживает. Эти опции могут использоваться независимо друг от друга и МОГУТ появляться в любом порядке в OPT RR. Каждый код опции может появляться только один раз в OPT RR.
На рисунке ниже показано, как каждый параметр определяется в RDATA OPR RR, указанной в [RFC6891]:
OPTION-CODE — это код для данной опции сигнализации. Варианты:
- Опция DNSSEC Algorithm Understood (DAU) для алгоритмов цифровой подписи DNSSEC. Его значение установлено на 5.
- Опция DS Hash Understood (DHU) для алгоритмов хеширования DS RR. Его значение установлено на 6.
- NSEC3 Hash Understood (N3U) опция для алгоритмов хэширования NSEC3. Его значение зафиксировано на уровне 7.
LIST-LENGTH — длина списка цифровых подписей или кодов алгоритмов хеширования в октетах. Каждый код алгоритма занимает один октет.
ALG-CODE — это список назначенных значений алгоритмов подписания зоны DNSSEC, алгоритмов хеширования DS или алгоритмов хеширования NSEC3 (в зависимости от используемого OPTION-CODE), который клиент объявляет поддерживаемым. Порядок значений кода может быть произвольным и НЕ ДОЛЖЕН использоваться для определения предпочтения.
Если все OPT включены в OPR RR, существует вероятность того, что OPT RR займет значительный размер в сообщении DNS. Однако в практическом плане включение всех трех параметров может занимать 22-32 октета (в среднем 6-10 алгоритмов цифровой подписи, 3-5 алгоритмов хеширования DS и 1-5 алгоритмов хеширования NSEC3), включая коды параметров EDNS0 и варианты длины в потенциальных будущих примерах.
4. Вопросы клиентов
Проверяющий распознаватель конечной системы устанавливает опцию DAU, DHU и / или N3U или их комбинацию в мета-RR OPT при отправке запроса. Проверяющий распознаватель конечной системы ДОЛЖЕН также установить бит DNSSEC OK [RFC4035], чтобы указать, что он хочет получить RR DNSSEC в ответе.
Обратите внимание, что коды цифровой подписи PRIVATEDNS (253) и / или PRIVATEOID (254) охватывают потенциально широкий спектр алгоритмов и, вероятно, бесполезны для сервера. У клиента нет веских причин включать эти коды в свой список DAU. Аналогично, клиенты НЕ ДОЛЖНЫ включать ЗАБРОНИРОВАННЫЕ коды в любую из опций. Кроме того, клиент не обязан перечислять каждый алгоритм, который он реализует, и МОЖЕТ выбрать перечисление только тех алгоритмов, которые клиент желает сигнализировать, как понял.
Поскольку параметры DAU, DHU и / или N3U задаются только в запросе, если клиент видит эти параметры в ответе, никаких действий предпринимать не нужно, и клиент ДОЛЖЕН игнорировать значения параметров.
4.1. Заглушки резольверов
Как правило, средства разрешения заглушки полагаются на рекурсивный сервер (или кэш) восходящего потока для предоставления ответа. Таким образом, оптимальная настройка параметров DAU, DSU и N3U зависит от того, выберет ли преобразователь заглушки свою собственную проверку.
4.1.1. Проверка правильности резольверов
Подтверждающий преобразователь заглушки устанавливает бит DNSSEC OK (DO) [RFC4035], чтобы указать, что он хочет получить дополнительные RR DNSSEC (то есть RRSIG) в ответе. Такие проверяющие распознаватели ДОЛЖНЫ включать DAU, DHU и / или опцию (и) N3U в OPT RR при отправке запроса.
4.1.2. Непроверяемые заглушки резольверов
Опции DAU, DHU и N3U EDNS0 НЕ ДОЛЖНЫ включаться в непроверяющие средства разрешения заглушек.
4.2. Рекурсивные резольверы
4.2.1. Проверка рекурсивных резольверов
Проверяющий рекурсивный распознаватель устанавливает параметры DAU, DHU и / или N3U при выполнении рекурсии на основе своего списка алгоритмов и любых списков параметров DAU, DHU и / или N3U в запросе клиента-заглушки. Когда рекурсивный сервер получает запрос с одной или несколькими из установленных опций, рекурсивный сервер ДОЛЖЕН установить список алгоритмов для любых исходящих итеративных запросов для этой цепочки разрешений на объединение списка клиента-заглушки и списка проверяющего рекурсивного преобразователя. Например, если список алгоритмов рекурсивного распознавателя для опции DAU равен (3, 5, 7), а список алгоритмов заглушки — (7, 8), окончательный список алгоритмов DAU будет (3, 5, 7, 8).
Если клиент включил биты DO и Checking Disabled (CD), но не включил опции (опции) DAU, DHU и / или N3U в запрос, проверяющий рекурсивный преобразователь МОЖЕТ включать эту опцию (ы) со своим собственным списком в полном объеме. Если один или несколько параметров отсутствуют, проверяющий рекурсивный преобразователь МОЖЕТ включать отсутствующие параметры с полным списком.
Валидация рекурсивных распознавателей НЕ ДОЛЖНА устанавливать опции DAU, DHU и / или N3U в окончательном ответе клиенту-заглушке.
4.2.2. Не проверяющие рекурсивные резольверы
Рекурсивные распознаватели, которые не выполняют проверку, ДОЛЖНЫ скопировать опцию (-и) DAU, DHU и / или N3U, видимые в полученных запросах, поскольку они представляют пожелания проверяющего преобразователя нисходящего потока, который выдал исходный запрос.
5. Промежуточные системные соображения
Промежуточные прокси (см. Раздел 4.4.2 [RFC5625]), которые понимают, что DNS РЕКОМЕНДУЕТСЯ вести себя как сопоставимый рекурсивный преобразователь при работе с опциями DAU, DHU и N3U.
6. Особенности сервера
Когда авторитетный сервер видит в запросе опции (опции) DAU, DHU и / или N3U в мета-RR OPT, следует обычный алгоритм для обслуживания запросов. Опции НЕ ДОЛЖНЫ запускать какую-либо специальную обработку (например, фильтрацию RRSIG в ответах) на стороне сервера.
Если параметры присутствуют, но бит DO не установлен, сервер не выполняет обработку DNSSEC, которая включает в себя любую запись параметра (ов).
Если сервер видит одну (или несколько) опций, установленных со значениями RESERVED, сервер МОЖЕТ игнорировать перекодирование этих значений.
Авторитетные серверы НЕ ДОЛЖНЫ устанавливать опции DAU, DHU и / или N3U для каких-либо ответов. Эти значения устанавливаются только в запросах.
7. Анализ трафика
Администраторы зоны, которые планируют или выполняют операцию переноса криптографического алгоритма, должны отслеживать трафик DNS-запросов и записывать количество запросов, наличие OPT RR в запросах и значения параметра (ов) DAU / DHU / N3U. ) (если представить). Этот мониторинг можно использовать для измерения развертывания клиентского кода, который реализует (и сигнализирует) конкретные алгоритмы. Описание методов, используемых для захвата трафика DNS и измерения принятия нового алгоритма, выходит за рамки этого документа.
Администраторы зон, которым необходимо соблюдать изменения в политике безопасности своей организации (в отношении использования криптографического алгоритма), могут использовать эти данные, чтобы установить контрольные даты выполнения ролловера алгоритма. Например, администраторы зоны могут использовать данные, чтобы определить, когда устаревшие алгоритмы могут быть выведены из эксплуатации без нарушения работы значительного числа клиентов. Чтобы свести это нарушение к минимуму, администраторы зоны должны дождаться завершения переключения алгоритма, пока подавляющее большинство клиентов не сообщит, что они распознают новый алгоритм. Это может быть порядка лет, а не месяцев.
Обратите внимание, что клиенты, которые не реализуют эти параметры, вероятно, будут более старыми реализациями, которые также не будут реализовывать какой-либо недавно развернутый алгоритм.
8. Соображения IANA
Коды алгоритмов, используемые для идентификации алгоритмов DNSSEC, алгоритмов хеширования DS RR и алгоритмов хеширования NSEC3, уже установлены IANA. Этот документ не стремится каким-либо образом изменить этот реестр.
IANA выделила коды опций 5, 6 и 7 для опций DAU, DHU и N3U, соответственно, в реестре «Коды опций DNS EDNS0 (OPT)». Три варианта имеют статус «стандарт».
9. Вопросы безопасности
Этот документ определяет способ для клиента передать свою цифровую подпись и информацию об алгоритме хеширования в кэш или сервер. Он не предназначен для обсуждения превосходства алгоритмов. Сигналы являются необязательными кодами, содержащимися в мета-RR OPT, используемом с EDNS. Цель этих опций — сигнализировать о новом использовании алгоритма в клиентском коде, чтобы администраторы зон знали, когда можно завершить перенос алгоритма в зоне, подписанной DNSSEC.
Существует вероятность того, что подслушиватель или сервер может сделать вывод о том, что клиент использует валидатор по наличию опций AU и / или списка кодов алгоритма. Эта утечка информации сама по себе не очень полезна для потенциального злоумышленника, но ее можно использовать для идентификации валидатора или для сужения возможных реализаций валидатора, используемых клиентом, которые могут иметь известную уязвимость, которая может быть использована злоумышленником.
10. Нормативные документы
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.
[RFC5625] Bellis, R., «DNS Proxy Implementation Guidelines», BCP 152, RFC 5625, August 2009.
[RFC6891] Damas, J., Graff, M., and P. Vixie, «Extension Mechanisms for DNS (EDNS(0))», STD 75, RFC 6891, April 2013.
Адрес автора
Steve Crocker
Shinkuro Inc.
5110 Edgemoor Lane
Bethesda, MD 20814
USA
EMail: steve@shinkuro.com
Scott Rose
NIST
100 Bureau Dr.
Gaithersburg, MD 20899
USA
Phone: +1-301-975-8439
EMail: scottr.nist@gmail.com
