RFC 3631 | Механизмы безопасности для интернета

Аннотация

Безопасность должна быть встроена в интернет-протоколы, чтобы эти протоколы могли безопасно предоставлять свои услуги. Многие проблемы безопасности могут быть связаны с неправильной реализацией. Однако даже у правильной реализации будут проблемы с безопасностью, если основной протокол сам по себе может быть использован. Как именно безопасность должна быть реализована в протоколе, будет зависеть от структуры самого протокола. Однако существует много протоколов, для которых уже могут применяться стандартные разработанные механизмы безопасности в Интернете. Точный, который подходит в любой конкретной ситуации, может варьироваться. Мы рассмотрим ряд различных вариантов, объясняя свойства каждого из них.

Скачать оригинальный документ на английском языке RFC 3631 PDF

1. Введение
2. Факторы принятия решений
2.1. Модель угрозы
2.2. Слово об обязательных механизмах
2.3. Зернистость защиты
2.4. Уровень реализации
3. Стандартные механизмы безопасности
3.1. Одноразовые пароли
3.2. HMAC
3.3. IPsec
3.4. TLS
3.5. SASL
3.6. GSS-API
3.7. DNSSEC
3.8. Security/Multipart
3.9. Цифровые подписи
3.10. OpenPGP and S/MIME
3.11. Межсетевые экраны и топология
3.12. Kerberos
3.13. SSH
4. Механизмы незащищенности
4.1. Незашифрованные пароли
4.2. Аутентификация на основе адресов
4.3. Аутентификация на основе имени
5. Вопросы безопасности
6. Вопросы IANA
7. Подтверждения
8. Информационные ссылки
9. Заявление об интеллектуальной собственности
10. Информация об авторе
11. Заявление об авторском праве

Статус этой заметки

Эта памятка содержит информацию для интернет-сообщества. Он не определяет интернет-стандарт любого вида. Распространение этой заметки не ограничено.

Уведомление об авторских правах

1. Введение

Компрометации Internet Security можно разделить на несколько классов, от отказа в обслуживании до компрометации хоста. Атаки типа «отказ в обслуживании», основанные на большом объеме трафика, выходят за рамки этого документа, хотя они являются предметом многочисленных постоянных дискуссий и исследований. Важно отметить, что многие подобные атаки усложняются благодаря надлежащим мерам безопасности. Компромисс хоста (чаще всего вызванный необнаруженными переполнениями буфера) представляет недостатки в отдельных реализациях, а не недостатки в протоколах. Тем не менее, тщательно разработанные протоколы могут снизить вероятность возникновения таких недостатков и усложнить их использование.

Тем не менее, существуют нарушения безопасности, которым способствуют сами протоколы, используемые в Интернете. Если в протоколе заложена проблема безопасности, никакая реализация не сможет предотвратить проблему.

Поэтому жизненно важно, чтобы протоколы, разработанные для Интернета, обеспечивали эту фундаментальную безопасность.

Как именно протокол должен быть защищен, зависит от самого протокола, а также от требований безопасности протокола. Тем не менее, мы разработали ряд стандартных механизмов безопасности в IETF. Во многих случаях надлежащее применение этих механизмов может обеспечить необходимую безопасность протокола.

Ряд возможных механизмов может быть использован для обеспечения безопасности в Интернете. Какой из них выбрать, зависит от множества различных факторов. Здесь мы попытаемся дать руководство, изложив факторы и стандартизированные в настоящее время (или близкие к стандартизации) решения, как обсуждалось на семинаре по архитектуре безопасности IAB [RFC2316].

Однако безопасность — это искусство, а не наука. Попытка слепо следовать рецепту может привести к катастрофе. Как всегда, хороший вкус в разработке протокола должен быть осуществлен.

Наконец, механизмы безопасности не являются волшебной пылью, которую можно разбрызгивать по законченным протоколам. Это редко, что безопасность может быть закреплена позже. Хорошие проекты — то есть безопасные, чистые и эффективные проекты — возникают, когда механизмы безопасности создаются вместе с протоколом. Ни одно мыслимое упражнение в криптографии не может обеспечить протокол с ошибочными семантическими допущениями.

2. Факторы принятия решений

2.1. Модель угрозы

Наиболее важным фактором при выборе механизма безопасности является модель угрозы. То есть кто может атаковать какой ресурс, используя какие механизмы? Цель с низкой стоимостью, такая как веб-сайт, который предлагает только публичную информацию, может не заслуживать особой защиты. И наоборот, ресурс, который в случае взлома может обнажить значительную часть инфраструктуры Интернета, скажем, главный магистральный маршрутизатор или сервер доменных имен высокого уровня, должен быть защищен очень сильными механизмами. Ценность цели для атакующего зависит от цели атаки. Если целью является получение доступа к конфиденциальной информации, все системы, которые обрабатывают эту информацию или обеспечивают доступ к ней, являются ценными. Если цель состоит в том, чтобы нанести ущерб, системы, от которых зависят большие части Интернета, чрезвычайно ценны. Даже если на веб-сайте размещена только общедоступная информация, изменение его содержимого может вызвать замешательство у его владельца и привести к значительному ущербу. Трудно при разработке протокола предсказать, что будет когда-либо использовать этот протокол.

Все подключенные к Интернету системы требуют минимального уровня защиты. Начиная с 2000 года и по настоящее время, мы стали свидетелями появления нового типа атаки на интернет-безопасность: интернет-червя, которая ищет и автоматически атакует системы, уязвимые для компрометации, с помощью ряда атак, встроенных в червя. Сама программа Эти программы-черви могут скомпрометировать буквально тысячи систем за очень короткий промежуток времени. Обратите внимание, что первым интернет-червем был «червь Моррис» 1988 года. Однако в течение 12 лет подобные программы не отслеживались!

На момент написания этого документа все эти черви воспользовались ошибками программирования при реализации в противном случае достаточно безопасных протоколов. Тем не менее, нетрудно представить атаку, нацеленную на фундаментальный недостаток безопасности в широко распространенном протоколе. Поэтому крайне важно, чтобы мы стремились свести к минимуму такие недостатки в протоколах, которые мы разрабатываем.

Ценность цели для атакующего может зависеть от того, где она находится. Станция сетевого мониторинга, которая физически подключена к магистральному кабелю, является основной целью, поскольку ее можно легко превратить в подслушивающую станцию. Тот же компьютер, если он расположен в сети-заглушке (stub net) и используется для обработки текстов, будет гораздо менее полезен искушенному злоумышленнику и, следовательно, будет подвергаться значительно меньшему риску.

Необходимо также учитывать, какие виды атак можно ожидать. Как минимум, подслушивание должно рассматриваться как серьезная угроза; По крайней мере, с 1993 года таких инцидентов было очень много. Часто активные атаки, то есть атаки, включающие вставку или удаление пакетов злоумышленником, также представляют собой риск. Стоит отметить, что такие атаки могут быть запущены с помощью готовых инструментов, и на самом деле они наблюдаются «в дикой природе». Особый интерес представляет форма атаки, называемая «перехват сеанса», когда кто-то, находящийся на линии связи между двумя связывающимися сторонами, ожидает завершения аутентификации, а затем выдает себя за одну из сторон и продолжает соединение с другой.

Одним из наиболее важных инструментов, доступных нам для защиты протоколов, является криптография. Криптография позволяет нам применять различные виды защиты к данным, когда они пересекают сеть, без необходимости зависеть от каких-либо конкретных свойств безопасности самой сети. Это важно, потому что Интернет по своему распределенному управлению и контролю сам по себе не может считаться надежным средством массовой информации. Его безопасность проистекает из механизмов, которые мы встраиваем в сами протоколы, независимо от базовых медиа или сетевых операторов.

Наконец, конечно, для криптографа есть издержки для защитника. Эта стоимость быстро падает; Закон Мура, а также легкая доступность криптографических компонентов и наборов инструментов позволяет относительно легко использовать надежные методы защиты. Несмотря на то, что есть исключения, операции с открытым ключом все еще дороги, возможно, чрезмерно, поэтому, если стоимость каждой операции с открытым ключом распространяется на слишком мало транзакций, тщательная разработка может, как правило, позволить нам распределить эту стоимость на многие транзакции.

В целом, по умолчанию сегодня следует использовать самую сильную криптографию, доступную в любом протоколе. Сильная криптография часто стоит не больше, а иногда и дешевле, чем более слабая криптография. Фактические затраты на производительность алгоритма часто не связаны с безопасностью, которую он обеспечивает. В зависимости от доступного оборудования криптография может выполняться с очень высокой скоростью (1 + Гбит / с), и даже в программном обеспечении ее влияние на производительность со временем уменьшается.

2.2. Слово об обязательных механизмах

Мы разработали в IETF понятие «обязательное внедрение» механизмов. Эта философия вытекает из нашего основного стремления обеспечить взаимодействие между различными реализациями протокола. Если протокол предлагает много вариантов того, как выполнить конкретную задачу, но не обеспечивает хотя бы одну, которую все должны реализовать, возможно, что это приведет к нескольким не совместимым реализациям. Это является следствием выбора непересекающихся механизмов, используемых в разных реализациях.

Хотя данный протокол может использовать только один или несколько механизмов безопасности, сами эти механизмы часто могут использовать несколько криптографических систем. Различные криптографические системы различаются по силе и производительности. Однако во многих протоколах нам нужно указать «обязательный для реализации» (mandatory to implement), чтобы гарантировать, что любые две реализации в конечном итоге смогут согласовать общую криптографическую систему между ними.

Есть несколько протоколов, которые изначально были предназначены для работы в очень ограниченном домене. Часто утверждают, что область реализации для конкретного протокола достаточно хорошо определена и безопасна, так что сам протокол не должен обеспечивать какие-либо механизмы безопасности.

История показала, что этот аргумент неверен. Неизбежно, успешные протоколы — даже если они разработаны для ограниченного использования — в конечном итоге используются в более широкой среде, где первоначальные предположения о безопасности не выполняются.

Чтобы решить эту проблему, IETF требует, чтобы протоколы * ALL * обеспечивали соответствующие механизмы безопасности, даже если их область применения вначале считается очень ограниченной.

Важно понимать, что обязательные механизмы являются обязательными для * реализации *. Не обязательно, чтобы конечные пользователи действительно использовали эти механизмы. Если конечный пользователь знает, что он развертывает протокол в «защищенной» сети, он может отключить механизмы безопасности, которые, по их мнению, добавляют недостаточную ценность по сравнению с затратами на производительность. (Мы, как правило, скептически относимся к разумности отключения сильной безопасности даже тогда, но это выходит за рамки этого документа.)

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

2.3. Зернистость защиты

Некоторые механизмы безопасности могут защитить всю сеть. Хотя это экономит аппаратное обеспечение, оно может оставить внутреннюю часть таких сетей открытой для атак изнутри. Другие механизмы могут обеспечить защиту отдельного пользователя машины с временным разделением, хотя, возможно, существует риск подмены пользователя, если машина была взломана.

При оценке желаемой степени детализации защиты разработчики протоколов должны учитывать вероятные схемы использования, уровни реализации (см. Ниже) и возможности развертывания. Если протокол, вероятно, будет использоваться только из защищенного кластера машин (скажем, Сетевого операционного центра), может оказаться целесообразной детализация подсети. В отличие от этого, механизм безопасности, свойственный одному приложению, лучше всего встроен в это приложение, а не в TCP; в противном случае развертывание будет очень сложным.

2.4. Уровень реализации

Механизмы безопасности могут быть расположены на любом уровне. В целом, размещение механизма на нижнем уровне защищает более широкий спектр протоколов более высокого уровня, но может и не защитить их. Шифратор канального уровня может защищать не только IP, но даже пакеты ARP. Однако его охват — это всего лишь одна ссылка. И наоборот, подписанное сообщение электронной почты защищено, даже если оно отправлено через многие почтовые шлюзы хранения и пересылки, может идентифицировать фактического отправителя, и подпись может быть проверена еще долго после доставки сообщения. Однако защищен только этот тип сообщений. Сообщения аналогичных форматов, такие как некоторые сообщения Netnews, не защищены, если механизм не будет специально адаптирован и затем реализован в программах обработки новостей.

3. Стандартные механизмы безопасности

3.1. Одноразовые пароли

Схемы одноразовых паролей, такие как описанные в [RFC2289], намного сильнее, чем обычные пароли. Хост не должен хранить копию пароля пользователя, и при этом он никогда не передается по сети. Однако есть некоторые риски. Поскольку передаваемая строка получена из пароля, введенного пользователем, атаки с угадыванием все еще могут быть осуществимы. (Действительно, программа, запускающая только эту атаку, легко доступна.) Кроме того, возможность входа пользователя обязательно истекает после заранее определенного количества использований. Хотя во многих случаях это является функцией, реализация, скорее всего, должна предоставить способ для повторной инициализации базы данных аутентификации, не требуя, чтобы новый пароль передавался в открытом виде по сети.

Есть коммерческие аппаратные токены аутентификации. Помимо проблемы перехвата сеанса, поддержка таких токенов (особенно токенов запроса / ответа, когда сервер отправляет различное случайное число для каждой попытки аутентификации) может потребовать дополнительных протокольных сообщений.

3.2. HMAC

HMAC [RFC2104] является предпочтительным методом аутентификации с общим секретным ключом. Если обе стороны знают один и тот же секретный ключ, HMAC можно использовать для аутентификации любого произвольного сообщения. Это включает в себя случайные проблемы, что означает, что HMAC можно адаптировать для предотвращения повторов старых сеансов.

К сожалению, недостаток использования HMAC для аутентификации соединения заключается в том, что секрет должен быть открытым в открытом доступе обеими сторонами, что делает это нежелательным, когда ключи являются долгосрочными.

Когда это целесообразно, HMAC следует использовать в предпочтении старым методам, особенно хеш-функциям с ключами. Хэши с простыми ключами на основе MD5 [RFC1321], такие как те, что используются в механизме безопасности сеансов BGP [RFC2385], особенно следует избегать в новых протоколах, учитывая намеки на слабость в MD5.

HMAC может быть реализован с использованием любой защищенной хеш-функции, включая MD5 и SHA-1 [RFC3174]. SHA-1 предпочтительнее для новых протоколов, потому что он чаще используется для этой цели и может быть более безопасным.

Важно понимать, что механизм, основанный на HMAC, должен использоваться в каждом протокольном блоке данных (он же пакет). Ошибочно использовать систему на основе HMAC для аутентификации начала сеанса TCP, а затем отправлять все оставшиеся данные без какой-либо защиты.

Существуют программы атак, которые позволяют украсть сеанс TCP. Злоумышленнику просто нужно использовать такой инструмент для кражи сеанса после выполнения шага HMAC.

3.3. IPsec

IPsec [RFC2401], [RFC2402], [RFC2406], [RFC2407], [RFC2411] — это общий протокол шифрования и аутентификации IP-уровня. Таким образом, он защищает все верхние уровни, включая как TCP, так и UDP. Обычная степень детализации защиты — хост-хост, хост-шлюз и шлюз-шлюз. Спецификация разрешает защиту гранулярности пользователя, но это сравнительно редко. Таким образом, IPsec в настоящее время не подходит, если гранулярность хоста слишком велика.

Поскольку IPsec устанавливается на уровне IP, он довольно навязчив для сетевого кода. Для его реализации обычно требуется либо новое оборудование, либо новый стек протоколов. С другой стороны, он довольно прозрачен для приложений. Приложения, работающие через IPsec, могут иметь повышенную безопасность, не меняя свои протоколы вообще. Но по крайней мере до тех пор, пока IPsec не будет развернут более широко, большинство приложений не должны предполагать, что они работают поверх IPsec в качестве альтернативы указанию своих собственных механизмов безопасности. Большинство современных операционных систем имеют IPsec; большинство маршрутизаторов не имеют, по крайней мере, для пути управления. Приложение, использующее TLS, с большей вероятностью сможет утверждать специфическое для приложения, чтобы использовать преимущества своей аутентификации.

Управление ключами для IPsec может использовать либо сертификаты, либо общие секреты. По всем очевидным причинам сертификаты являются предпочтительными; однако они могут представлять большую головную боль для системного менеджера.

Существует большой потенциал для конфликта между IPsec и NAT [RFC2993]. NAT нелегко сосуществует с любым протоколом, содержащим встроенный IP-адрес; с IPsec каждый пакет для каждого протокола содержит такие адреса, хотя бы только в заголовках. Иногда можно избежать конфликта, используя туннельный режим, но это не всегда подходящий выбор по другим причинам. Продолжается работа по упрощению прохождения IPsec через NAT [NATIKE].

Наиболее распространенное использование IPsec для виртуальных частных сетей. Предполагая, что другие ограничения соблюдаются, IPsec является предпочтительным протоколом безопасности для ситуаций, подобных VPN, включая сценарий удаленного доступа, когда одна машина туннелирует обратно в свою домашнюю сеть через Интернет с использованием IPsec.

3.4. TLS

TLS [RFC2246] предоставляет зашифрованный канал с проверкой подлинности, который работает поверх TCP. Хотя TLS изначально был разработан для использования веб-браузерами, он ни в коем случае не ограничен этим. В целом, однако, каждое приложение, которое желает использовать TLS, должно быть преобразовано индивидуально.

Как правило, сторона сервера всегда аутентифицируется сертификатом. Клиенты могут также иметь сертификаты, обеспечивающие взаимную аутентификацию, хотя это редко разворачивается. К сожалению, реальность заключается в том, что даже аутентификация на стороне сервера не так безопасна на практике, как это может сделать криптография, поскольку большинство реализаций позволяют пользователям игнорировать ошибки аутентификации (нажимая кнопку ОК для предупреждения), и большинство пользователей обычно делают это [Bell98]. Таким образом, разработчики должны с осторожностью относиться к требованию паролей в незашифрованном виде, даже для соединений, защищенных TLS. (Это требование может быть смягчено, если существует вероятность того, что реализации смогут проверить подлинность и авторизацию сертификата сервера.)

Хотя для использования TLS обычно требуется модификация приложения, существуют наборы инструментов, как бесплатные, так и коммерческие, которые предоставляют реализации. Они предназначены для включения в код приложения. Приложение, использующее TLS, с большей вероятностью сможет утверждать политики сертификатов для конкретного приложения, чем приложение, использующее IPsec.

3.5. SASL

SASL [RFC2222] — это структура для согласования механизма аутентификации и шифрования, который будет использоваться в потоке TCP. Как таковые, его защитные свойства являются свойствами согласованного механизма. В частности, если согласованный механизм не аутентифицирует все последующие сообщения или не используется базовый протокол защиты, такой как TLS, соединения TCP уязвимы для кражи сеанса.

Если вам нужно использовать TLS (или IPSec) под SASL, зачем вообще беспокоиться о SASL? Почему бы просто не использовать средства аутентификации TLS и покончить с этим?

Ответ здесь тонкий. TLS широко использует сертификаты для аутентификации. При обычном развертывании только серверы имеют сертификаты, в то время как клиенты не проходят проверку подлинности (по крайней мере, самой обработкой TLS).

SASL разрешает использование более традиционных технологий аутентификации клиента, таких как пароли (одноразовые или иные). Мощная комбинация — это TLS для базовой защиты и аутентификации сервера, а также система на основе SASL для аутентификации клиентов. Необходимо проявлять осторожность, чтобы избежать уязвимости «человек посередине», когда разные методы аутентификации используются в разных направлениях.

3.6. GSS-API

GSS-API [RFC2744] предоставляет платформу для приложений, когда они требуют аутентификации, целостности и / или конфиденциальности. В отличие от SASL, GSS-API может легко использоваться с приложениями на основе UDP. Он предусматривает создание непрозрачных токенов аутентификации (также называемых кусками памяти), которые могут быть встроены в блоки данных протокола. Обратите внимание, что безопасность протоколов, защищенных GSS-API, зависит от базового механизма безопасности; это должно оцениваться независимо. Конечно, аналогичные соображения применимы и к взаимодействию.

3.7. DNSSEC

DNSSEC [RFC2535] снабжает цифровую подпись записями DNS. Это важный инструмент для защиты от атак на кэш DNS [Bell95]; они, в свою очередь, могут использоваться для победы над аутентификацией на основе имен и для перенаправления трафика на злоумышленника или за него. Последнее делает DNSSEC важным компонентом некоторых других механизмов безопасности, особенно IPsec.

Несмотря на то, что на момент написания этого документа он не был широко распространен в Интернете, он предлагает потенциал для обеспечения безопасного механизма для сопоставления доменных имен с адресами протокола IP. Он также может быть использован для безопасного связывания другой информации с DNS-именем.

Эта информация может быть такой же простой, как услуга, поддерживаемая на данном узле, или ключом, который будет использоваться с IPsec для согласования безопасного сеанса. Обратите внимание, что концепция хранения ключей приложений общего назначения в DNS устарела [RFC3445], но стандартизация хранения ключей для конкретных приложений, в частности IPsec, продолжается.

3.8. Security/Multipart

Security/Multiparts [RFC1847] являются предпочтительным механизмом защиты электронной почты. Точнее, это среда MIME, в которую встроены шифрование и / или цифровые подписи. Оба S/MIME, и OpenPGP (см. Ниже) используют Security / Multipart для своего кодирования. Соответствующие читатели почты могут легко распознавать и обрабатывать криптографические части почты.

Security/Multiparts представляет собой одну из форм «защиты объекта», когда объект, представляющий интерес для конечного пользователя, защищен независимо от транспортного механизма, промежуточного хранилища и т. д.. В настоящее время в Интернете не существует общей формы защиты объекта.

Для хорошего примера использования S/MIME вне контекста электронной почты см. «Протокол инициации сеанса» [RFC 3261].

3.9. Цифровые подписи

Одна из самых сильных форм аутентификации по запросу / ответу основана на цифровых подписях. Использование криптографии с открытым ключом предпочтительнее схем, основанных на шифрах с секретными ключами, поскольку ни одному серверу не требуется копия секрета клиента. Скорее у клиента есть закрытый ключ; серверы имеют соответствующий открытый ключ.

Правильно использовать цифровые подписи сложно. Клиент никогда не должен подписывать точный вызов, отправленный ему, так как в таких ситуациях можно запустить несколько тонких теоретико-числовых атак.

Стандарт цифровой подписи [DSS] и RSA [RSA] — хороший выбор; у каждого есть свои преимущества. Подписание с DSA требует использования хороших случайных чисел [RFC1750]. Если противник может восстановить случайное число, используемое для любой данной подписи, или если вы используете одно и то же случайное число для двух разных документов, ваш личный ключ может быть восстановлен. DSS имеет гораздо лучшую производительность, чем RSA, для генерации новых закрытых ключей и несколько лучшую производительность для генерации подписей, в то время как RSA имеет гораздо лучшую производительность для проверки подписей.

3.10. OpenPGP and S/MIME

Цифровые подписи могут использоваться для создания приложений «объектной безопасности — object security», которые могут использоваться для защиты данных в хранилище и перенаправления протоколов, таких как электронная почта.

На момент написания этой статьи было предложено два различных безопасных почтовых протокола: OpenPGP [OpenPGP] и S/MIME [S / MIME], чтобы заменить PEM [PEM]. Непонятно, что, если либо, удастся. Хотя они предназначены для использования с защищенной почтой, оба могут быть адаптированы для защиты данных, передаваемых другими протоколами. Оба используют сертификаты для идентификации пользователей; оба могут обеспечить секретность и аутентификацию почтовых сообщений; однако форматы сертификатов очень разные. Исторически разница между почтой на основе PGP и почтой на основе S / MIME заключалась в стиле цепочки сертификатов. В S / MIME пользователи имеют сертификаты X.509; График сертификации — это дерево с очень небольшим количеством корней. В отличие от этого, PGP использует так называемую «сеть доверия — web of trust», где любой пользователь может подписать чей-либо сертификат. Этот граф сертификации действительно является произвольным графом или набором графов.

В любой схеме сертификатов доверие зависит от двух основных характеристик. Во-первых, он должен исходить из известного надежного источника, либо корня X.509, либо человека, которому верит очень доверяющий, часто он сам. Во-вторых, цепочка подписей должна быть надежной. То есть каждый узел в графе сертификации имеет решающее значение; если это нечестно или скомпрометировано, любые сертификаты, на которые он поручился, нельзя доверять. При прочих равных условиях (и они редко бывают), более короткие цепи предпочтительнее.

Некоторые из различий отражают противоречие между двумя философскими позициями, представленными этими технологиями. Другие возникли из-за наличия отдельных дизайнерских команд.

S/MIME разработан, чтобы быть «защищенным от дурака — fool proof«. То есть, требуется очень мало настроек для конечного пользователя. В частности, конечные пользователи не должны знать о доверительных отношениях и т. д.. Идея состоит в том, что если клиент S/MIME говорит: «Эта подпись действительна — This signature is valid», пользователь должен иметь возможность «доверять — trust» этому утверждению за чистую монету, без необходимости понимать основные последствия.

Для достижения этого S/MIME обычно основан на ограниченном количестве «корневых» сертифицирующих органов (CA). Цель состоит в том, чтобы создать глобальную инфраструктуру доверенных сертификатов.

Недостатком этого подхода является то, что для его работы требуется развернутая инфраструктура открытых ключей. Два конечных пользователя могут не иметь возможности просто получить программное обеспечение с поддержкой S/MIME и начать безопасную связь. Это не ограничение протокола, а типичное ограничение конфигурации для общедоступного программного обеспечения. Один или оба из них, возможно, должны получить сертификат от взаимно доверяемого CA; Более того, этот CA уже должен доверять программному обеспечению для обработки почты. Этот процесс может включать стоимость и юридические обязательства. В конечном итоге это приводит к тому, что технологию сложнее развернуть, особенно в среде, где конечные пользователи не обязательно оценивают ценность, полученную за возникающие трудности.

Подход PGP «сеть доверия» имеет то преимущество, что два конечных пользователя могут просто получить программное обеспечение PGP и немедленно начать безопасную связь. Никакой инфраструктуры не требуется, и никакие сборы и юридические соглашения не должны быть подписаны, чтобы продолжить. Таким образом, PGP обращается к людям, которым необходимо создавать специальные ассоциации безопасности.

Недостатком PGP является то, что конечным пользователям необходимо иметь представление о базовой технологии безопасности, чтобы эффективно ее использовать. В частности, довольно легко обмануть наивных пользователей, приняв «подписанное» сообщение, которое на самом деле является подделкой.

На сегодняшний день PGP нашел широкое признание среди тех, кто заботится о безопасности, и которым необходима защищенная электронная почта в среде, в которой нет необходимой глобальной инфраструктуры.

В отличие от этого, S/MIME хорошо работает в корпоративной среде, где может быть развернута защищенная внутренняя система CA. Это не требует много знаний о безопасности конечного пользователя. S/MIME может использоваться между учреждениями путем тщательной настройки перекрестной сертификации, но это сложнее, чем кажется.

На момент написания этой статьи глобальная инфраструктура сертификатов продолжает ускользать от нас. Вопросы о подходящей бизнес-модели, а также вопросы конфиденциальности могут помешать ее появлению.

3.11. Межсетевые экраны и топология

Брандмауэры — это топологический защитный механизм. То есть они полагаются на четко определенную границу между хорошим «внутри» и плохим «снаружи» некоторого домена, а межсетевой экран обеспечивает передачу информации. Хотя брандмауэры могут быть очень полезны при правильном использовании, их возможности по защите сети ограничены.

Конечно, первое ограничение заключается в том, что брандмауэры не могут защитить от внутренних атак. Хотя фактическая частота таких атак неизвестна (и, вероятно, неизвестна), нет сомнений в том, что она существенна и, вероятно, представляет собой большинство проблем безопасности. В более общем плане, учитывая, что брандмауэры требуют четко разграниченной границы, если такая граница не существует, брандмауэры не помогают. Любые внешние соединения, будь то протоколы, которые преднамеренно проходят через брандмауэр, каналы, проходящие через туннель, незащищенные беспроводные локальные сети или прямые внешние соединения с номинально внутри узлов, ослабляют защиту. Брандмауэры, как правило, становятся менее эффективными с течением времени, так как пользователи туннелируют протоколы через них и могут иметь недостаточную безопасность на конечных точках туннеля. Если туннели зашифрованы, брандмауэр не может их подвергать цензуре. Часто упоминаемое преимущество межсетевых экранов заключается в том, что они скрывают существование внутренних хостов от посторонних глаз. Однако, учитывая количество утечек, вероятность успешного сокрытия машин довольно низкая.

С другой стороны, брандмауэры наносят вред сквозной модели Интернета и его протоколов. Действительно, не все протоколы могут быть безопасно или легко переданы через брандмауэры. Сайты, которые используют брандмауэры для обеспечения безопасности, могут оказаться отрезанными от новых и полезных аспектов Интернета.

Брандмауэры работают лучше всего, когда они используются как один элемент общей структуры безопасности. Например, строгий брандмауэр может использоваться для отделения незащищенного веб-сервера от внутренней базы данных, при этом единственный канал связи между ними открывается. Точно так же межсетевой экран, который разрешает только зашифрованный туннельный трафик, может использоваться для защиты части VPN. С другой стороны, в этом случае другой конец VPN должен быть одинаково защищен.

3.12. Kerberos

Kerberos [RFC1510] предоставляет механизм для двух объектов для аутентификации друг друга и обмена ключами. На стороне клиента приложение получает Kerberos «билет — ticket» и «аутентификатор — authenticator». Эти элементы, которые следует рассматривать как непрозрачные данные, затем передаются от клиента к серверу. Затем сервер может проверить их подлинность. Затем обе стороны могут попросить программное обеспечение Kerberos предоставить им ключ сеанса, который можно использовать для защиты или шифрования данных.

Kerberos может использоваться сам по себе в протоколе. Тем не менее, он также доступен как механизм под SASL и GSSAPI. У него есть некоторые известные уязвимости [KRBATTACK] [KRBLIM] [KRB4WEAK], но его можно безопасно использовать.

3.13. SSH

SSH обеспечивает безопасное соединение между клиентом и сервером. Он работает очень похоже на TLS; однако он оптимизирован как протокол для удаленных подключений на терминальных устройствах. Одна из его более инновационных функций — поддержка туннелирования других протоколов через TCP-соединение, защищенное SSH. Эта функция позволила хорошо осведомленным специалистам по безопасности выполнять такие действия, как чтение и отправка электронной почты или новостей через незащищенные серверы через незащищенную сеть. Это не замена для настоящего VPN, но его часто можно использовать вместо одного.

4. Механизмы незащищенности

Некоторые общие механизмы безопасности являются частью проблемы, а не частью решения.

4.1. Незашифрованные пароли

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

Другая слабость возникает из-за общих методов реализации. Для хоста [MT79] считается хорошей формой хранить однонаправленный хэш паролей пользователей, а не их текстовые формы. Однако это может препятствовать переходу на более надежные механизмы аутентификации, такие как запрос / ответ на основе HMAC.

Самая сильная атака на пароли, кроме подслушивания, это угадывание пароля. При наличии подходящей программы и словаря (и они широко доступны) в большинстве сред можно угадать 20-30% паролей [Klein90].

4.2. Аутентификация на основе адресов

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

Среди угроз — ARP-спуфинг, злоупотребление локальными прокси-серверами, перенумерация, повреждение таблицы маршрутизации или атаки, DHCP, спуфинг IP-адресов (особый риск для протоколов на основе UDP), угадывание порядковых номеров и пакеты с маршрутизацией от источника. Все это может быть довольно мощным.

4.3. Аутентификация на основе имени

Проверка подлинности на основе имен связана со всеми проблемами проверки подлинности на основе адресов и добавляет новые: атаки на DNS [Bell95] и отсутствие однозначного сопоставления между адресами и именами. Как минимум, процесс, который извлекает имя хоста из DNS, должен извлечь соответствующие записи адресов и провести перекрестную проверку. Такие методы, как загрязнение DNS-кэша, часто могут свести на нет такие проверки.

DNSSEC обеспечивает защиту от такого рода атак. Тем не менее, это ничего не делает для повышения надежности базового адреса. Кроме того, техника генерирует много ложных срабатываний. Эти поиски не предоставляют надежную информацию для машины, хотя они могут быть полезным средством отладки для людей и могут быть полезны в журналах при попытке восстановить, как и как произошла атака.

5. Вопросы безопасности

Никакие механизмы безопасности не идеальны. Если ничто иное, любой сетевой механизм безопасности может быть скомпрометирован из-за компрометации конечных точек. Тем не менее, каждый из механизмов, описанных здесь, имеет свои ограничения. Любое решение принять данный механизм должно взвесить все возможные режимы отказа. Они, в свою очередь, должны быть сопоставлены с рисками до конечной точки сбоя безопасности.

6. Вопросы IANA

В отношении этого документа нет никаких замечаний IANA.

7. Благодарности

Брайан Карпентер (Brian Carpenter), Тони Хейн (Tony Hain) и Маркус Лич (Marcus Leech) сделали ряд полезных предложений. Большая часть сущности исходит от участников семинара по архитектуре безопасности IAB.

8. Информационные ссылки

[Bell95] «Using the Domain Name System for System Break-Ins». Proc. Fifth Usenix Security Conference, 1995.

[Bell98] «Cryptography and the Internet», S.M. Bellovin, in Proceedings of CRYPTO ’98, August 1998.

[DSS] «Digital Signature Standard». NIST. May 1994. FIPS 186.

[Klein90] «Foiling the Cracker: A Survey of, and Implications to, Password Security». D. Klein. Usenix UNIX Security Workshop, August 1990.

[KRBATTACK] «A Real-World Analysis of Kerberos Password Security». T. Wu. Network and Distributed System Security Symposium (NDSS ’99). January 1999.

[KRBLIM] «Limitations of the Kerberos Authentication System». Proceedings of the 1991 Winter USENIX Conference, 1991.

[KRB4WEAK] «Misplaced trust: Kerberos 4 session keys». Proceedings of the Internet Society Network and Distributed Systems Security Symposium, March 1997.

[MT79] «UNIX Password Security», R.H. Morris and K. Thompson, Communications of the ACM. November 1979.

[NATIKE] Kivinen, T., et al., «Negotiation of NAT-Traversal in the IKE», Work in Progress, June 2002.

[RFC1321] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, April 1992.

[RFC1510] Kohl, J. and C. Neuman, «The Kerberos Network Authentication Service (V5)», RFC 1510, September 1993.

[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, «Randomness Recommendations for Security», RFC 1750, December 1994.

[RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, «Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted», RFC 1847, October 1995.

[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[RFC2222] Myers, J., «Simple Authentication and Security Layer (SASL)», RFC 2222, October 1997.

[RFC2246] Dierks, T. and C. Allen, «The TLS Protocol Version 1.0», RFC 2246, January 1999.

[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, «A One-Time Password System», STD 61, RFC 2289, February 1998.

[RFC2316] Bellovin, S., «Report of the IAB Security Architecture Workshop», RFC 2316, April 1998.

[RFC2385] Hefferman, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401, November 1998.

[RFC2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 2402, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406, November 1998.

[RFC2407] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407, November 1998.

[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, «IP Security Document Roadmap», RFC 2411, November 1998.

[RFC2535] Eastlake, D., «Domain Name System Security Extensions», RFC 2535, March 1999.

[RFC2744] Wray, J., «Generic Security Service API Version 2: Cbindings», RFC 2744, January 2000.

[RFC2993] Hain, T., «Architectural Implications of NAT», RFC 2993, November 2000.

[RFC3174] Eastlake, D. and P. Jones, «US Secure Hash Algorithm 1 (SHA1)», RFC 3174, September 2001.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, R., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261, June 2002.

[RFC3445] Massey, D. and S. Rose, «Limiting the Scope of the KEY Resource Record (RR)», RFC 3445, December 2002.

[RSA] Rivest, R., Shamir, A. and L. Adleman, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems», Communications of the ACM, February 1978.

9. Заявление об интеллектуальной собственности

IETF не занимает никакой позиции относительно действительности или объема какой-либо интеллектуальной собственности или других прав, которые могут быть заявлены как относящиеся к внедрению или использованию технологии, описанной в этом документе, или степени, в которой любая лицензия в рамках таких прав может или не может быть имеется в наличии; это также не означает, что оно приложило какие-либо усилия для выявления таких прав. Информацию о процедурах IETF в отношении прав в документации по стандартам и соответствующей документации можно найти в BCP-11. Могут быть получены копии заявлений о правах, предоставленных для публикации, и любых гарантий лицензий, которые должны быть предоставлены, или в результате попытки получения общей лицензии или разрешения на использование таких прав собственности разработчиками или пользователями данной спецификации. из Секретариата IETF.

IETF предлагает любой заинтересованной стороне довести до ее сведения любые авторские права, патенты или патентные заявки или другие права собственности, которые могут охватывать технологии, которые могут потребоваться для применения этого стандарта. Пожалуйста, отправьте информацию исполнительному директору IETF.

10. Информация об авторе

Этот документ является публикацией Совета по архитектуре Интернета. Членами Совета по архитектуре Интернета на момент подготовки этого документа были:

Bernard Aboba
Harald Alvestrand
Rob Austein
Leslie Daigle, Chair
Patrik Faltstrom
Sally Floyd
Jun-ichiro Itojun Hagino
Mark Handley
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Michael StJohns

Internet Architecture Board
EMail: iab@iab.org

Steven M. Bellovin, Editor
EMail: bellovin@acm.org

Jeffrey I. Schiller, Editor
EMail: jis@mit.edu

Charlie Kaufman, Editor
EMail: charliek@microsoft.com

11. Заявление об авторском праве

Этот документ и его переводы могут быть скопированы и предоставлены другим лицам, а производные работы, которые комментируют или иным образом объясняют его или помогают в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, полностью или частично, без каких-либо ограничений. при условии, что вышеупомянутое уведомление об авторских правах и этот параграф включены во все такие копии и производные работы. Однако сам этот документ не может быть изменен каким-либо образом, например, путем удаления уведомления об авторских правах или ссылок на Интернет-сообщество или другие интернет-организации, за исключением случаев, когда это необходимо для разработки стандартов Интернета, и в этом случае процедуры для авторских прав, определенные в необходимо придерживаться процесса интернет-стандартов или по мере необходимости переводить его на другие языки, кроме английского.

Предоставленные выше ограниченные разрешения являются бессрочными и не будут аннулированы Обществом Интернета или его правопреемниками или правопреемниками.

Этот документ и информация, содержащаяся в настоящем документе, предоставляются на условиях «КАК ЕСТЬ», и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖЕНЕРНАЯ ЗАДАЧА ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, НО ОГРАНИЧИВАЯСЬ, НИ ОДНОЙ ГАРАНТИИ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ БУДЕТ НАРУШИТЬ ЛЮБЫЕ ПРАВА ИЛИ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОГО ОБЕСПЕЧЕНИЯ ИЛИ ПРИГОДНОСТИ ДЛЯ ОСОБЫХ ЦЕЛЕЙ.

Подтверждение

Финансирование функции RFC Editor в настоящее время обеспечивается Обществом Интернета (Internet Society).