Strong Security Requirements for Internet Engineering Task Force Standard Protocols
О документе
Рабочая группа сети J. Schiller
Request for Comments: 3365 Massachusetts Institute of Technology
BCP: 61 Август 2002
Категория: Лучшая современная практика
Жёсткие требования безопасности для
стандартных протоколов Internet Engineering Task Force
1. Введение
Цель этого документа — зафиксировать консенсус IETF о требованиях
безопасности для протоколов, а также предоставить предысторию и
обоснование этих требований.
Интернет является глобальной сетью независимо управляемых сетей и
хостов. Поэтому не существует центрального органа, ответственного за
эксплуатацию сети. Также не существует центрального органа,
ответственного за обеспечение безопасности во всей сети.
Безопасность необходимо обеспечивать сквозным способом или между
хостами. Роль IETF в области безопасности заключается в том, чтобы
гарантировать наличие у стандартных протоколов IETF функций,
необходимых для обеспечения надлежащей безопасности приложения при
его использовании через Интернет. Обязательные к реализации механизмы
должны обеспечивать достаточную безопасность для защиты важных
бизнес-приложений.
2. Терминология
Хотя в этом документе мы не определяем стандарт протокола, мы будем
использовать термины MUST, MAY, SHOULD и родственные им в значениях,
определённых в [RFC2119].
3. Службы безопасности
[RFC2828] содержит исчерпывающий перечень служб межсетевой
безопасности и их определений. Ниже приведены три существенных
определения:
* Служба аутентификации: служба безопасности, которая проверяет
идентичность, заявленную сущностью или от имени сущности — будь то
процесс, компьютерная система или человек. На межсетевом уровне это
включает проверку того, что дейтаграмма поступила оттуда, откуда она
заявляет, что происходит. На уровне приложения это включает проверку
того, что сущность, выполняющая операцию, является тем, за кого себя
выдаёт.
* Служба конфиденциальности данных: служба безопасности, которая
защищает данные от несанкционированного раскрытия неуполномоченным
лицам или процессам. (В документах Internet Standards НЕ СЛЕДУЕТ
(SHOULD NOT) использовать «конфиденциальность данных» как синоним
«приватности», поскольку это иное понятие. Приватность относится к
праву сущности, обычно человека, действующего от собственного имени,
определять степень своего взаимодействия с окружающей средой,
включая степень, в которой сущность готова делиться сведениями о себе
с другими.)
* Служба целостности данных: служба безопасности, которая защищает от
несанкционированных изменений данных, включая как преднамеренное
изменение (включая уничтожение), так и случайное изменение (включая
утрату), обеспечивая обнаруживаемость изменений данных.
4. Некоторые свойства Интернета
Как упоминалось ранее, Интернет не обеспечивает встроенной
безопасности. Существуют изолированные сетевые среды, в которых
пользователи полагают, что безопасность обеспечивается самой средой.
Примером может быть корпоративная сеть, не подключённая к глобальному
Интернету.
Можно представить, что протоколам, предназначенным для работы в такой
изолированной среде, не требуются какие-либо службы безопасности,
поскольку безопасность обеспечивается средой.
История показала, что приложения, работающие с использованием стека
протоколов TCP/IP, в итоге начинают использоваться через Интернет. Это
верно даже тогда, когда изначально не предполагалось, что приложение
будет использоваться в интернет-среде «глобальной сети». Если
приложение не спроектировано для обеспечения безопасности,
пользователи приложения обнаруживают свою уязвимость к атаке.
5. Технологии безопасности IETF
У IETF имеется несколько протоколов и стандартов безопасности. IP
Security (IPsec [RFC2411]) и Transport Layer Security (TLS [RFC2246])
являются двумя хорошо известными протоколами. Simple Authentication and
Security Layer (SASL [RFC2222]) и Generic Security Service Application
Programming Interface (GSSAPI [RFC2743]) предоставляют службы в
контексте «хостового» протокола. Их можно рассматривать как «наборы
инструментов» для использования внутри другого протокола.
Один из критически важных выборов, который должен сделать разработчик
протокола, — использовать ли один из существующих протоколов,
спроектировать собственный протокол для использования одного из
стандартных инструментов или сделать нечто совершенно иное.
Не существует одного правильного ответа для всех протоколов, и
разработчикам действительно необходимо рассмотреть угрозы для
собственного протокола и спроектировать надлежащие меры
противодействия. Цель раздела «Security Considerations», обязательного
к наличию в RFC на Internet Standards Track, — предоставить место, где
разработчики протоколов могут документировать угрозы и объяснить логику
своего проектирования безопасности.
6. Доктрина Данверса
На 32-й встрече IETF, состоявшейся в Данверсе, штат Массачусетс, в
апреле 1995 года, IESG запросила у пленарного заседания консенсус о
силе безопасности, которая должна обеспечиваться стандартами IETF.
Хотя непосредственным вопросом перед IETF было, следует ли
поддерживать в стандартах безопасность экспортного уровня (то есть
слабую безопасность), этот вопрос поднял общий вопрос безопасности в
целом.
Подавляющим консенсусом было то, что IETF следует стандартизировать
использование наилучшей доступной безопасности независимо от
национальных политик. Этот консенсус часто называют «доктриной
Данверса».
Со временем мы расширили толкование доктрины Данверса так, что оно
подразумевает, что все протоколы IETF должны работать безопасно. Как
можно с этим спорить?
С 1995 года Интернет всё чаще подвергается атакам различных
злоумышленных субъектов. В 2000 году значительное внимание прессы было
уделено атакам Distributed Denial of Service. Однако многие из этих
атак запускались после первоначальной компрометации подключённой к
Интернету компьютерной системы. Обычно для запуска существенной
распределённой атаки компрометируют множество систем.
Из всего этого можно сделать вывод, что, если мы не обеспечим
безопасные протоколы, Интернет станет менее полезным для предоставления
международной коммуникационной инфраструктуры, которая, по-видимому,
является его предназначением.
Один из постоянно звучащих аргументов против встраивания безопасности
в протоколы состоит в том, что данный протокол предназначен только для
использования в «защищённых» средах, где безопасность не будет
проблемой.
Однако очень трудно предсказать, как протокол будет использоваться в
будущем. То, что может быть предназначено только для ограниченной
среды, вполне может в итоге быть развёрнуто в глобальном Интернете. Мы
не можем ждать до этого момента, чтобы «исправить» проблемы
безопасности. К тому времени, когда мы осознаем такое развёртывание,
будет уже слишком поздно.
Решение состоит в том, что мы ДОЛЖНЫ (MUST) реализовывать надёжную
безопасность во всех протоколах, чтобы подготовиться к слишком часто
наступающему дню, когда протокол получит широкое применение в
глобальном Интернете.
7. MUST — для реализаторов
Мы часто говорим, что безопасность ДОЛЖНА (MUST) быть реализована.
Стоит отметить, что между MUST implement и MUST use существует
существенное различие.
Как упоминалось ранее, некоторые протоколы могут развёртываться в
защищённых изолированных средах, для которых безопасность не является
проблемой, а обработка протоколов безопасности может приводить к
существенному снижению производительности. Поэтому вполне разумно,
чтобы функции безопасности были опцией, которую конечный пользователь
протокола может решить отключить. Отметим, что здесь мы используем
расплывчатое определение «конечного пользователя». Мы подразумеваем не
только конечного пользователя в буквальном смысле, но и любого
развёртывающего технологию, которым может быть целое предприятие.
Однако безопасность должна быть обязательной к реализации (MUST
IMPLEMENT), чтобы у конечных пользователей была возможность включить
её, когда того потребует ситуация.
8. Является ли шифрование MUST?
Не обязательно. Однако здесь нам нужно быть несколько точнее. То,
какие именно службы безопасности подходят для данного протокола, в
значительной степени зависит от реализуемого им приложения. Многие
люди считают, что шифрование означает конфиденциальность. Иными
словами, шифрование содержимого сообщений протокола.
Однако существует много приложений, где конфиденциальность не является
требованием, а аутентификация и целостность являются.
Одним примером может быть приложение управления зданием, где мы
используем IP-технологию для управления отоплением и вентиляцией.
Вероятно, нет требования защищать конфиденциальность сообщений,
предписывающих вентиляционным заслонкам открываться и закрываться.
Однако аутентификация и целостность, вероятно, важны, если мы хотим
защитить здание от злоумышленного субъекта, произвольно повышающего или
понижающего температуру.
Тем не менее для реализации аутентификации и целостности сообщений
протокола нам часто требуется криптографическая технология. Поэтому,
если вопрос звучит как «ДОЛЖНЫ (MUST) ли мы реализовывать
конфиденциальность?», ответ будет: «зависит». Однако, если вопрос
звучит как «ДОЛЖНЫ (MUST) ли мы использовать криптографическую
технологию?», ответ: «вероятно».
9. Похоже, у криптографии плохая репутация
Упоминание криптографической технологии на многих форумах IETF
приводит к тому, что у слушателей стекленеют глаза и усиливается
сопротивление.
Многие люди, похоже, связывают слово «криптография» с такими опасениями,
как экспортный контроль и производительность. Некоторые просто не
понимают её и поэтому избегают её использования. Однако многие из этих
опасений необоснованны.
Сегодня экспортный контроль, по крайней мере со стороны большей части
развитого мира, становится меньшей проблемой. И даже там, где он
является проблемой, опасение связано не с самой криптографией, а с её
использованием для обеспечения конфиденциальности.
При использовании криптографической технологии возникают вопросы
производительности. Однако в IETF мы гордимся тем, что являемся
инженерами. Определение надлежащего способа использовать
криптографическую технологию, чтобы устранить или по крайней мере
минимизировать влияние использования криптографии в рамках данного
протокола, является инженерной задачей.
Наконец, что касается понимания криптографии, вам не обязательно её
понимать. Иными словами, чтобы эффективно использовать
криптографическую технологию, вам не нужно становиться криптографом.
Вместо этого вы используете существующие хорошо понятные шифры и
наборы шифров, чтобы решить стоящую перед вами инженерную задачу.
Одна из наших целей в Security Area IETF — подготовить руководства,
чтобы реализаторы протоколов могли выбирать подходящую технологию без
необходимости понимать мелкие детали.
10. Соображения безопасности
Этот документ посвящён требованию IETF учитывать безопасность при
реализации протоколов. Поэтому он целиком посвящён безопасности!
11. Благодарности
Автор хотел бы отметить вклад Security Area Advisory Group и, в
частности, Rob Shirey, Ran Atkinson, Steve Bellovin, Marc Blanchet,
Steve Kent, Randy Bush, Dave Crocker, Stephen Farrell, Paul Hoffman,
Russ Housley, Christian Huitema, Melinda Shore, Adam Shostack и Kurt D.
Zeilenga.
12. Ссылки
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1.", RFC 2743, January 2000.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828,
May 2000.
13. Адрес автора
Jeffrey I. Schiller
MIT Room W92-190
77 Massachusetts Avenue
Cambridge, MA 02139-4307
USA
Phone: +1 (617) 253-8400
EMail: jis@mit.edu
14. Полное заявление об авторских правах
Copyright (C) The Internet Society (2002). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, которые комментируют или иным
образом разъясняют его либо содействуют его реализации, могут
подготавливаться, копироваться, публиковаться и распространяться
полностью или частично без каких-либо ограничений при условии, что
приведённое выше уведомление об авторских правах и этот абзац
включаются во все такие копии и производные работы. Однако сам этот
документ не допускается каким-либо образом изменять, например путём
удаления уведомления об авторских правах или ссылок на Internet
Society либо другие интернет-организации, за исключением случаев,
когда это необходимо для целей разработки интернет-стандартов, в
которых должны соблюдаться процедуры в отношении авторских прав,
определённые процессом разработки Internet Standards, или когда это
требуется для перевода документа на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и
не будут отозваны Internet Society либо её правопреемниками или
цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на
условиях "КАК ЕСТЬ", И INTERNET SOCIETY И INTERNET ENGINEERING TASK
FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, И ЛЮБЫЕ
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ
ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.