Strong Security Requirements for Internet Engineering Task Force Standard Protocols
RFC 3365 фиксирует консенсус IETF: стандартные протоколы IETF ОБЯЗАНЫ (MUST) использовать надлежащие сильные механизмы безопасности. Документ обосновывает это требование свойствами Интернета и практикой развёртывания протоколов за пределами первоначально предполагаемых защищённых сред. Выбор конкретных сервисов безопасности зависит от приложения и модели угроз: конфиденциальность требуется не всегда, тогда как аутентификация и целостность могут быть необходимы. Средства безопасности должны быть ОБЯЗАТЕЛЬНЫ к реализации (MUST IMPLEMENT), хотя в отдельных защищённых средах пользователь или развёртывающая сторона может отключить их использование.
Рабочая группа сети J. Schiller
Request for Comments: 3365 Massachusetts Institute of Technology
BCP: 61 Август 2002
Категория: Лучшая современная практика
Жёсткие требования безопасности для
стандартных протоколов Internet Engineering Task Force
Статус данного меморандума
Этот документ устанавливает Internet Best Current Practices для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторском праве
Copyright (C) The Internet Society (2002). All Rights Reserved.
Аннотация
В IETF достигнут консенсус о том, что стандартные протоколы IETF
ДОЛЖНЫ (MUST) использовать надлежащие надёжные механизмы
безопасности. В этом документе описаны история и обоснование этой
доктрины, а также данная доктрина устанавливается как лучшая
современная практика.
Содержание
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Терминология . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Службы безопасности . . . . . . . . . . . . . . . . . . . . . 2
4. Свойства Интернета. . . . . . . . . . . . . . . . . . . . . . 3
5. Технологии безопасности IETF. . . . . . . . . . . . . . . . . 3
6. Доктрина Данверса. . . . . . . . . . . . . . . . . . . . . . 4
7. MUST — для реализаторов. . . . . . . . . . . . . . . . . . . 5
8. Является ли шифрование MUST? . . . . . . . . . . . . . . . . 5
9. Похоже, у криптографии плохая репутация . . . . . . . . . . . 6
10. Соображения безопасности . . . . . . . . . . . . . . . . . . 6
11. Благодарности . . . . . . . . . . . . . . . . . . . . . . . 6
12. Ссылки . . . . . . . . . . . . . . . . . . . . . . . . . . 7
13. Адрес автора . . . . . . . . . . . . . . . . . . . . . . . 7
14. Полное заявление об авторском праве . . . . . . . . . . . . 8
Schiller Лучшая современная практика [Страница 1]
RFC 3365 Требования безопасности шифрования Август 2002
1. Введение
Цель этого документа — зафиксировать консенсус IETF о требованиях
безопасности для протоколов, а также предоставить предысторию и
обоснование этих требований.
Интернет является глобальной сетью независимо управляемых сетей и
хостов. Поэтому не существует центрального органа, ответственного за
эксплуатацию сети. Также не существует центрального органа,
ответственного за обеспечение безопасности во всей сети.
Безопасность необходимо обеспечивать сквозным способом или между
хостами. Роль IETF в области безопасности заключается в том, чтобы
гарантировать наличие у стандартных протоколов IETF функций,
необходимых для обеспечения надлежащей безопасности приложения при
его использовании через Интернет. Обязательные к реализации механизмы
должны обеспечивать достаточную безопасность для защиты важных
бизнес-приложений.
2. Терминология
Хотя в этом документе мы не определяем стандарт протокола, мы будем
использовать термины MUST, MAY, SHOULD и родственные им в значениях,
определённых в [RFC2119].
3. Службы безопасности
[RFC2828] содержит исчерпывающий перечень служб межсетевой
безопасности и их определений. Ниже приведены три существенных
определения:
* Служба аутентификации: служба безопасности, которая проверяет
идентичность, заявленную сущностью или от имени сущности — будь то
процесс, компьютерная система или человек. На межсетевом уровне это
включает проверку того, что дейтаграмма поступила оттуда, откуда она
заявляет, что происходит. На уровне приложения это включает проверку
того, что сущность, выполняющая операцию, является тем, за кого себя
выдаёт.
* Служба конфиденциальности данных: служба безопасности, которая
защищает данные от несанкционированного раскрытия неуполномоченным
лицам или процессам. (В документах Internet Standards НЕ СЛЕДУЕТ
(SHOULD NOT) использовать «конфиденциальность данных» как синоним
«приватности», поскольку это иное понятие. Приватность относится к
праву сущности, обычно человека, действующего от собственного имени,
определять степень своего взаимодействия с окружающей средой,
включая степень, в которой сущность готова делиться сведениями о себе
с другими.)
Schiller Лучшая современная практика [Страница 2]
RFC 3365 Требования безопасности шифрования Август 2002
* Служба целостности данных: служба безопасности, которая защищает от
несанкционированных изменений данных, включая как преднамеренное
изменение (включая уничтожение), так и случайное изменение (включая
утрату), обеспечивая обнаруживаемость изменений данных.
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, — предоставить место, где
разработчики протоколов могут документировать угрозы и объяснить логику
своего проектирования безопасности.
Schiller Лучшая современная практика [Страница 3]
RFC 3365 Требования безопасности шифрования Август 2002
6. Доктрина Данверса
На 32-й встрече IETF, состоявшейся в Данверсе, штат Массачусетс, в
апреле 1995 года, IESG запросила у пленарного заседания консенсус о
силе безопасности, которая должна обеспечиваться стандартами IETF.
Хотя непосредственным вопросом перед IETF было, следует ли
поддерживать в стандартах безопасность экспортного уровня (то есть
слабую безопасность), этот вопрос поднял общий вопрос безопасности в
целом.
Подавляющим консенсусом было то, что IETF следует стандартизировать
использование наилучшей доступной безопасности независимо от
национальных политик. Этот консенсус часто называют «доктриной
Данверса».
Со временем мы расширили толкование доктрины Данверса так, что оно
подразумевает, что все протоколы IETF должны работать безопасно. Как
можно с этим спорить?
С 1995 года Интернет всё чаще подвергается атакам различных
злоумышленных субъектов. В 2000 году значительное внимание прессы было
уделено атакам Distributed Denial of Service. Однако многие из этих
атак запускались после первоначальной компрометации подключённой к
Интернету компьютерной системы. Обычно для запуска существенной
распределённой атаки компрометируют множество систем.
Из всего этого можно сделать вывод, что, если мы не обеспечим
безопасные протоколы, Интернет станет менее полезным для предоставления
международной коммуникационной инфраструктуры, которая, по-видимому,
является его предназначением.
Один из постоянно звучащих аргументов против встраивания безопасности
в протоколы состоит в том, что данный протокол предназначен только для
использования в «защищённых» средах, где безопасность не будет
проблемой.
Однако очень трудно предсказать, как протокол будет использоваться в
будущем. То, что может быть предназначено только для ограниченной
среды, вполне может в итоге быть развёрнуто в глобальном Интернете. Мы
не можем ждать до этого момента, чтобы «исправить» проблемы
безопасности. К тому времени, когда мы осознаем такое развёртывание,
будет уже слишком поздно.
Решение состоит в том, что мы ДОЛЖНЫ (MUST) реализовывать надёжную
безопасность во всех протоколах, чтобы подготовиться к слишком часто
наступающему дню, когда протокол получит широкое применение в
глобальном Интернете.
Schiller Лучшая современная практика [Страница 4]
RFC 3365 Требования безопасности шифрования Август 2002
7. MUST — для реализаторов
Мы часто говорим, что безопасность ДОЛЖНА (MUST) быть реализована.
Стоит отметить, что между MUST implement и MUST use существует
существенное различие.
Как упоминалось ранее, некоторые протоколы могут развёртываться в
защищённых изолированных средах, для которых безопасность не является
проблемой, а обработка протоколов безопасности может приводить к
существенному снижению производительности. Поэтому вполне разумно,
чтобы функции безопасности были опцией, которую конечный пользователь
протокола может решить отключить. Отметим, что здесь мы используем
расплывчатое определение «конечного пользователя». Мы подразумеваем не
только конечного пользователя в буквальном смысле, но и любого
развёртывающего технологию, которым может быть целое предприятие.
Однако безопасность должна быть обязательной к реализации (MUST
IMPLEMENT), чтобы у конечных пользователей была возможность включить
её, когда того потребует ситуация.
8. Является ли шифрование MUST?
Не обязательно. Однако здесь нам нужно быть несколько точнее. То,
какие именно службы безопасности подходят для данного протокола, в
значительной степени зависит от реализуемого им приложения. Многие
люди считают, что шифрование означает конфиденциальность. Иными
словами, шифрование содержимого сообщений протокола.
Однако существует много приложений, где конфиденциальность не является
требованием, а аутентификация и целостность являются.
Одним примером может быть приложение управления зданием, где мы
используем IP-технологию для управления отоплением и вентиляцией.
Вероятно, нет требования защищать конфиденциальность сообщений,
предписывающих вентиляционным заслонкам открываться и закрываться.
Однако аутентификация и целостность, вероятно, важны, если мы хотим
защитить здание от злоумышленного субъекта, произвольно повышающего или
понижающего температуру.
Тем не менее для реализации аутентификации и целостности сообщений
протокола нам часто требуется криптографическая технология. Поэтому,
если вопрос звучит как «ДОЛЖНЫ (MUST) ли мы реализовывать
конфиденциальность?», ответ будет: «зависит». Однако, если вопрос
звучит как «ДОЛЖНЫ (MUST) ли мы использовать криптографическую
технологию?», ответ: «вероятно».
Schiller Лучшая современная практика [Страница 5]
RFC 3365 Требования безопасности шифрования Август 2002
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.
Schiller Лучшая современная практика [Страница 6]
RFC 3365 Требования безопасности шифрования Август 2002
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
Schiller Best Current Practice [Page 7]
RFC 3365 Encryption Security Requirements August 2002
14. Полное заявление об авторских правах
Copyright (C) The Internet Society (2002). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, которые комментируют или иным
образом разъясняют его либо содействуют его реализации, могут
подготавливаться, копироваться, публиковаться и распространяться
полностью или частично без каких-либо ограничений при условии, что
приведённое выше уведомление об авторских правах и этот абзац
включаются во все такие копии и производные работы. Однако сам этот
документ не допускается каким-либо образом изменять, например путём
удаления уведомления об авторских правах или ссылок на Internet
Society либо другие интернет-организации, за исключением случаев,
когда это необходимо для целей разработки интернет-стандартов, в
которых должны соблюдаться процедуры в отношении авторских прав,
определённые процессом разработки Internet Standards, или когда это
требуется для перевода документа на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и
не будут отозваны Internet Society либо её правопреемниками или
цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на
условиях "КАК ЕСТЬ", И INTERNET SOCIETY И INTERNET ENGINEERING TASK
FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, И ЛЮБЫЕ
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ
ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время обеспечивается
Internet Society.
Schiller Best Current Practice [Page 8]
Network Working Group J. Schiller
Request for Comments: 3365 Massachusetts Institute of Technology
BCP: 61 August 2002
Category: Best Current Practice
Strong Security Requirements for
Internet Engineering Task Force Standard Protocols
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
It is the consensus of the IETF that IETF standard protocols MUST
make use of appropriate strong security mechanisms. This document
describes the history and rationale for this doctrine and establishes
this doctrine as a best current practice.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Security Services . . . . . . . . . . . . . . . . . . . . . . 2
4. The Properties of the Internet. . . . . . . . . . . . . . . . 3
5. IETF Security Technology. . . . . . . . . . . . . . . . . . . 3
6. The Danvers Doctrine. . . . . . . . . . . . . . . . . . . . . 4
7. MUST is for Implementors. . . . . . . . . . . . . . . . . . . 5
8. Is Encryption a MUST? . . . . . . . . . . . . . . . . . . . . 5
9. Crypto Seems to Have a Bad Name . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 6
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
Schiller Best Current Practice [Page 1]
RFC 3365 Encryption Security Requirements August 2002
1. Introduction
The purpose of this document is to document the IETF consensus on
security requirements for protocols as well as to provide the
background and motivation for them.
The Internet is a global network of independently managed networks
and hosts. As such there is no central authority responsible for the
operation of the network. There is no central authority responsible
for the provision of security across the network either.
Security needs to be provided end-to-end or host to host. The IETF's
security role is to ensure that IETF standard protocols have the
necessary features to provide appropriate security for the
application as it may be used across the Internet. Mandatory to
implement mechanisms should provide adequate security to protect
sensitive business applications.
2. Terminology
Although we are not defining a protocol standard in this document we
will use the terms MUST, MAY, SHOULD and friends in the ways defined
by [RFC2119].
3. Security Services
[RFC2828] provides a comprehensive listing of internetwork security
services and their definitions. Here are three essential
definitions:
* Authentication service: A security service that verifies an
identity claimed by or for an entity, be it a process, computer
system, or person. At the internetwork layer, this includes
verifying that a datagram came from where it purports to originate.
At the application layer, this includes verifying that the entity
performing an operation is who it claims to be.
* Data confidentiality service: A security service that protects
data against unauthorized disclosure to unauthorized individuals or
processes. (Internet Standards Documents SHOULD NOT use "data
confidentiality" as a synonym for "privacy", which is a different
concept. Privacy refers to the right of an entity, normally a
person, acting in its own behalf, to determine the degree to which
it will interact with its environment, including the degree to
which the entity is willing to share information about itself with
others.)
Schiller Best Current Practice [Page 2]
RFC 3365 Encryption Security Requirements August 2002
* Data integrity service: A security service that protects against
unauthorized changes to data, including both intentional change
(including destruction) and accidental change (including loss), by
ensuring that changes to data are detectable.
4. Some Properties of the Internet
As mentioned earlier, the Internet provides no inherent security.
Enclaves of networking exist where users believe that security is
provided by the environment itself. An example would be a company
network not connected to the global Internet.
One might imagine that protocols designed to operate in such an
enclave would not require any security services, as the security is
provided by the environment.
History has shown that applications that operate using the TCP/IP
Protocol Suite wind up being used over the Internet. This is true
even when the original application was not envisioned to be used in a
"wide area" Internet environment. If an application isn't designed
to provide security, users of the application discover that they are
vulnerable to attack.
5. IETF Security Technology
The IETF has several security protocols and standards. IP Security
(IPsec [RFC2411]), Transport Layer Security (TLS [RFC2246]) are two
well known protocols. Simple Authentication and Security Layer (SASL
[RFC2222] and the Generic Security Service Application Programming
Interface (GSSAPI [RFC2743]) provide services within the context of a
"host" protocol. They can be viewed as "toolkits" to use within
another protocol.
One of the critical choices that a protocol designer must make is
whether to make use of one of the existing protocols, engineer their
own protocol to use one of the standard tools or do something
completely different.
There is no one correct answer for all protocols and designers really
need to look at the threats to their own protocol and design
appropriate counter-measures. The purpose of the "Security
Considerations" Section required to be present in an RFC on the
Internet Standards Track is to provide a place for protocol designers
to document the threats and explain the logic to their security
design.
Schiller Best Current Practice [Page 3]
RFC 3365 Encryption Security Requirements August 2002
6. The Danvers Doctrine
At the 32cd IETF held in Danvers, Massachusetts during April of 1995
the IESG asked the plenary for a consensus on the strength of
security that should be provided by IETF standards. Although the
immediate issue before the IETF was whether or not to support
"export" grade security (which is to say weak security) in standards
the question raised the generic issue of security in general.
The overwhelming consensus was that the IETF should standardize on
the use of the best security available, regardless of national
policies. This consensus is often referred to as the "Danvers
Doctrine".
Over time we have extended the interpretation of the Danvers Doctrine
to imply that all IETF protocols should operate securely. How can
one argue against this?
Since 1995 the Internet has increasingly come under attack from
various malicious actors. In 2000 significant press coverage was
devoted to Distributed Denial of Service attacks. However many of
these attacks were launched by first compromising an Internet
connected computer system. Usually many systems are compromised in
order to launch a significant distributed attack.
A conclusion we can draw from all of this is that if we fail to
provide secure protocols, then the Internet will become less useful
in providing an international communications infrastructure, which
appears to be its destiny.
One of the continuing arguments we hear against building security
into protocols is the argument that a given protocol is intended only
for use in "protected" environments where security will not be an
issue.
However it is very hard to predict how a protocol will be used in the
future. What may be intended only for a restricted environment may
well wind up being deployed in the global Internet. We cannot wait
until that point to "fix" security problems. By the time we realize
this deployment, it is too late.
The solution is that we MUST implement strong security in all
protocols to provide for the all too frequent day when the protocol
comes into widespread use in the global Internet.
Schiller Best Current Practice [Page 4]
RFC 3365 Encryption Security Requirements August 2002
7. MUST is for Implementors
We often say that Security is a MUST implement. It is worth noting
that there is a significant different between MUST implement and MUST
use.
As mentioned earlier, some protocols may be deployed in secure
enclaves for which security isn't an issue and security protocol
processing may add a significant performance degradation. Therefore
it is completely reasonable for security features to be an option
that the end user of the protocol may choose to disable. Note that
we are using a fuzzy definition of "end user" here. We mean not only
the ultimate end user, but any deployer of a technology, which may be
an entire enterprise.
However security must be a MUST IMPLEMENT so that end users will have
the option of enabling it when the situation calls for it.
8. Is Encryption a MUST?
Not necessarily. However we need to be a bit more precise here.
Exactly what security services are appropriate for a given protocol
depends heavily on the application it is implementing. Many people
assume that encryption means confidentiality. In other words the
encryption of the content of protocol messages.
However there are many applications where confidentiality is not a
requirement, but authentication and integrity are.
One example might be in a building control application where we are
using IP technology to operate heat and vent controls. There is
likely no requirement to protect the confidentiality of messages that
instruct heat vents to open and close. However authentication and
integrity are likely important if we are to protect the building from
a malicious actor raising or lowering the temperature at will.
Yet we often require cryptographic technology to implement
authentication and integrity of protocol messages. So if the
question is "MUST we implement confidentiality?" the answer will be
"depends". However if the question is "MUST we make use of
cryptographic technology?" the answer is "likely".
Schiller Best Current Practice [Page 5]
RFC 3365 Encryption Security Requirements August 2002
9. Crypto Seems to Have a Bad Name
The mention of cryptographic technology in many IETF forums causes
eyes to glaze over and resistance to increase.
Many people seem to associate the word "cryptography" with concerns
such as export control and performance. Some just plain do not
understand it and therefore shy away from its use. However many of
these concerns are unfounded.
Today export control, at least from most of the developed world, is
becoming less of a concern. And even where it is a concern, the
concern is not over cryptography itself but in its use in providing
confidentiality.
There are performance issues when you make use of cryptographic
technology. However we pride ourselves in the IETF as being
engineers. It is an engineering exercise to figure out the
appropriate way to make use of cryptographic technology so as to
eliminate or at least minimize the impact of using cryptography
within a given protocol.
Finally, as to understanding cryptography, you don't have to. In
other words, you do not need to become a cryptographer in order to
effectively make use of cryptographic technology. Instead you make
use of existing well understood ciphers and cipher suites to solve
the engineering problem you face.
One of the goals that we have in the Security Area of the IETF is to
come up with guides so that protocol implementers can choose
appropriate technology without having to understand the minutiae.
10. Security Considerations
This document is about the IETF's requirement that security be
considered in the implementation of protocols. Therefore it is
entirely about security!
11. Acknowledgements
The author would like to acknowledge the participation of the
Security Area Advisory Group and in particular 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 and Kurt D. Zeilenga.
Schiller Best Current Practice [Page 6]
RFC 3365 Encryption Security Requirements August 2002
12. References
[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. Author's Address
Jeffrey I. Schiller
MIT Room W92-190
77 Massachusetts Avenue
Cambridge, MA 02139-4307
USA
Phone: +1 (617) 253-8400
EMail: jis@mit.edu
Schiller Best Current Practice [Page 7]
RFC 3365 Encryption Security Requirements August 2002
14. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schiller Best Current Practice [Page 8]