✖


Jump to content

Интернет-обмен ключами

(Перенаправлено с IKEv2 )

В вычислительной технике обмен ключами через Интернет ( IKE , версии IKEv1 и IKEv2 ) — это протокол, используемый для настройки ассоциации безопасности (SA) в наборе протоколов IPsec . IKE основан на протоколе Oakley и ISAKMP . [1] IKE использует сертификаты X.509 для аутентификации — либо предварительно общие, либо распространяемые с использованием DNS (предпочтительно с DNSSEC ) — и обмен ключами Диффи-Хеллмана для настройки общего секрета сеанса, из которого криптографические ключи . извлекаются [2] [3] Кроме того, политика безопасности для каждого узла, который будет подключаться, должна поддерживаться вручную. [2]

История

[ редактировать ]

Инженерная группа Интернета (IETF) первоначально определила IKE в ноябре 1998 года в серии публикаций ( Запрос комментариев ), известных как RFC 2407, RFC 2408 и RFC 2409:

  • RFC   2407 определил домен интерпретации IP-безопасности Интернета для ISAKMP. [4]
  • RFC   2408 определил ассоциацию безопасности Интернета и протокол управления ключами (ISAKMP). [5]
  • RFC   2409 определил обмен ключами в Интернете (IKE). [6]

RFC   4306 обновил IKE до второй версии (IKEv2) в декабре 2005 года. [7] В октябре 2006 года RFC   4718 разъяснил некоторые открытые детали. [8] RFC   5996 объединил эти два документа вместе с дополнительными пояснениями в обновленный IKEv2. [9] опубликовано в сентябре 2010 года. В более позднем обновлении документ был повышен с «Предлагаемого стандарта» до «Интернет-стандарта» , опубликованного как RFC   7296 в октябре 2014 г.

Материнская организация IETF, Интернет-сообщество (ISOC), сохранила авторские права на эти стандарты как свободно доступные интернет-сообществу.

Архитектура

[ редактировать ]

Большинство реализаций IPsec состоят из демона IKE , который работает в пользовательском пространстве , и стека IPsec в ядре , который обрабатывает фактические IP- пакеты.

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

Протокол IKE использует пакеты UDP , обычно через порт 500, и обычно требует 4–6 пакетов с 2–3 обратными проходами для создания ISAKMP ассоциации безопасности (SA) с обеих сторон. Согласованный ключевой материал затем передается в стек IPsec. Например, это может быть ключ AES , информация, идентифицирующая конечные точки IP и порты, которые необходимо защитить, а также тип туннеля IPsec, который был создан. Стек IPsec, в свою очередь, перехватывает соответствующие IP-пакеты, если и где это необходимо, и выполняет шифрование/дешифрование по мере необходимости. Реализации различаются в зависимости от того, как осуществляется перехват пакетов — например, некоторые используют виртуальные устройства, другие берут часть брандмауэра и т. д.

IKEv1 состоит из двух фаз: фазы 1 и фазы 2. [10]

Фазы IKEv1

[ редактировать ]

Целью первого этапа IKE является создание безопасного аутентифицированного канала связи с использованием алгоритма обмена ключами Диффи-Хеллмана для генерации общего секретного ключа для шифрования дальнейших сообщений IKE. В результате этого согласования создается одна двунаправленная ассоциация безопасности ISAKMP. [11] Аутентификация может выполняться с использованием предварительного общего ключа (общего секрета), подписей или шифрования с открытым ключом. [12] Фаза 1 работает либо в основном режиме, либо в агрессивном режиме. Основной режим защищает личность одноранговых узлов и хэш общего ключа путем их шифрования; Агрессивный режим этого не делает. [10]

На втором этапе IKE одноранговые узлы IKE используют безопасный канал, установленный на этапе 1, для согласования ассоциаций безопасности от имени других служб, таких как IPsec . В результате согласования создаются как минимум две однонаправленные ассоциации безопасности (одна входящая и одна исходящая). [13] Фаза 2 работает только в быстром режиме. [10]

Проблемы с ИКЕ

[ редактировать ]

Первоначально IKE имел множество вариантов конфигурации, но не имел общих средств для автоматического согласования общеизвестного варианта по умолчанию, который реализуется повсеместно. Следовательно, обе стороны IKE должны были точно согласовать тип ассоциации безопасности, которую они хотели создать – вариант за вариантом – иначе соединение не могло быть установлено. Дальнейшие сложности возникли из-за того, что во многих реализациях выходные данные отладки было трудно интерпретировать, если вообще существовало какое-либо средство для создания диагностических данных.

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

Улучшения с IKEv2

[ редактировать ]

Протокол IKEv2 был описан в Приложении A к RFC 4306 в 2005 году. Были решены следующие проблемы:

  • Меньше запросов на комментарии (RFC). Спецификации IKE были описаны как минимум в трех RFC, а если принять во внимание прохождение NAT и другие широко используемые расширения, то и больше. IKEv2 объединяет их в одном RFC, а также вносит улучшения в поддержку обхода NAT ( трансляция сетевых адресов (NAT)) и обхода брандмауэра в целом.
  • Стандартная поддержка мобильности: существует стандартное расширение для IKEv2 под названием [rfc:4555 Протокол мобильности и множественной адресации] (MOBIKE) (см. также IPsec ), используемое для поддержки мобильности и множественной адресации для него, а также инкапсуляции полезной нагрузки безопасности (ESP). Благодаря этому расширению IKEv2 и IPsec могут использоваться мобильными и многосетевыми пользователями.
  • Обход NAT : инкапсуляция IKE и ESP в протоколе пользовательских датаграмм (порт UDP 4500) позволяет этим протоколам проходить через устройство или брандмауэр, выполняющий NAT . [14]
  • Поддержка протокола передачи управления потоком (SCTP): IKEv2 поддерживает протокол SCTP , используемый в протоколе интернет-телефонии, Voice over IP (VoIP).
  • Простой обмен сообщениями: IKEv2 имеет один механизм начального обмена с четырьмя сообщениями, при этом IKE предоставляет восемь совершенно разных механизмов начального обмена, каждый из которых имеет небольшие преимущества и недостатки.
  • Меньше криптографических механизмов: IKEv2 использует криптографические механизмы для защиты своих пакетов, которые очень похожи на те, которые IPsec ESP использует для защиты пакетов IPsec. Это привело к упрощению реализации и сертификации по общим критериям и FIPS 140-2 ( Федеральный стандарт обработки информации (FIPS), который требует отдельной проверки каждой криптографической реализации.
  • Надежность и управление состоянием. IKEv2 использует порядковые номера и подтверждения для обеспечения надежности и требует некоторой логистики обработки ошибок и совместного управления состоянием. IKE мог оказаться в мертвом состоянии из-за отсутствия таких мер надежности, когда обе стороны ожидали, что другая инициирует действие, чего так и не произошло. Обходные пути (такие как Dead-Peer-Detection ) были разработаны, но не стандартизированы. Это означало, что различные реализации обходных решений не всегда были совместимы.
  • Устойчивость к атакам типа «отказ в обслуживании» (DoS): IKEv2 не выполняет большую обработку, пока не определит, действительно ли существует запрашивающая сторона. Это решило некоторые проблемы DoS, с которыми столкнулся IKE, который выполнял большую часть дорогостоящей криптографической обработки из поддельных мест.
Предположим, HostA имеет индекс параметров безопасности (SPI) A и HostB имеет SPI ​ B, сценарий будет выглядеть так: 
HostA -------------------------------------------------- HostB
     |HDR(A,0),sai1,kei,Ni-------------------------->   |
     |   <----------------------------HDR(A,0),N(cookie)|
     |HDR(A,0),N(cookie),sai1,kei,Ni---------------->   |
     |   <--------------------------HDR(A,B),SAr1,ker,Nr|
Если HostB (ответчик) испытывает большое количество полуоткрытых соединений IKE, он отправит незашифрованное ответное сообщение IKE_SA_INIT HostA (инициатору) с уведомляющим сообщением типа COOKIEи будет ожидать, что HostA отправит IKE_SA_INIT запросите это значение cookie в полезной нагрузке уведомления для HostB . Это необходимо для того, чтобы инициатор действительно мог обработать ответ IKE от ответчика.

Расширения протокола

[ редактировать ]

Рабочая группа IETF ipsecme стандартизировала ряд расширений с целью модернизации протокола IKEv2 и лучшей адаптации его к большим объемам, производственные среды. Эти расширения включают в себя:

  • Возобновление сеанса IKE : возможность возобновить неудачный «сеанс» IKE/IPsec после сбоя без необходимости проходить весь процесс настройки IKE ( RFC 5723 ).
  • Перенаправление IKE : перенаправление входящих запросов IKE, позволяющее просто балансировать нагрузку между несколькими конечными точками IKE ( RFC 5685 ).
  • Видимость трафика IPsec : специальная маркировка пакетов ESP, которые аутентифицированы, но не зашифрованы, с целью облегчить промежуточным устройствам (таким как системы обнаружения вторжений ) анализ потока ( RFC 5840 ).
  • Взаимная аутентификация EAP : поддержка аутентификации только EAP (т. е. без сертификатов) обоих узлов IKE; цель состоит в том, чтобы позволить аутентификации на основе пароля ( использовать современные методы RFC 5998 ).
  • Быстрое обнаружение сбоев : минимизация времени до тех пор, пока одноранговый узел IKE не обнаружит, что его противоположный одноранговый узел вышел из строя ( RFC 6290 ).
  • Расширения высокой доступности : улучшение синхронизации протоколов уровня IKE/IPsec между кластером конечных точек IPsec и одноранговым узлом, чтобы уменьшить вероятность разрыва соединений после события переключения при сбое ( RFC 6311 ).

Реализации

[ редактировать ]

IKE поддерживается как часть реализации IPsec в Windows 2000 , Windows XP , Windows Server 2003 , Windows Vista и Windows Server 2008 . [15] Реализация ISAKMP/IKE была разработана совместно Cisco и Microsoft. [16]

Microsoft Windows 7 и Windows Server 2008 R2 частично поддерживают IKEv2 ( RFC 7296) as well as MOBIKE (RFC 4555 ) через функцию VPN Reconnect (также известную как Agile VPN ).

Существует несколько реализаций IPsec с открытым исходным кодом и соответствующими возможностями IKE. В Linux реализации Libreswan Openswan , StrongSwan и . предоставляют демон IKE, который может настраивать (т. е. устанавливать SA) стеки IPsec на основе ядра KLIPS или XFRM/NETKEY XFRM/NETKEY — это собственная реализация IPsec для Linux, доступная начиная с версии 2.6.

Компания Berkeley Software Distributions также реализует IPsec и демон IKE через OpenBSD Cryptographic Framework (OCF), что значительно упрощает поддержку криптографических ускорителей . OCF недавно был портирован на Linux.

Ряд поставщиков сетевого оборудования создали свои собственные демоны IKE (и реализации IPsec) или лицензировали стек друг у друга.

Существует ряд реализаций IKEv2, и некоторые компании, занимающиеся сертификацией IPsec и тестированием совместимости, начинают проводить семинары по тестированию, а также обновляют сертификационные требования для тестирования IKEv2.

Доступны следующие реализации IKEv2 с открытым исходным кодом:

Уязвимости

[ редактировать ]

Утечка презентаций АНБ , опубликованная в 2014 году журналом Der Spiegel, показывает, что IKE неизвестным образом используется для расшифровки трафика IPsec, как и ISAKMP. [19] Исследователи, обнаружившие атаку Logjam , заявляют, что взлом 1024-битной группы Диффи-Хеллмана приведет к поломке 66% VPN-серверов, 18% из миллиона крупнейших доменов HTTPS и 26% SSH-серверов, что, по утверждению исследователей, соответствует утечки. [20] Это утверждение было опровергнуто в 2015 году Эялем Роненом и Ади Шамиром в их статье «Критический обзор несовершенной прямой секретности». [21] и Пол Воутерс из Либресуана в статье 2015 года «66% VPN на самом деле не сломаны» [22]

Конфигурации IPsec VPN, которые позволяют согласовывать несколько конфигураций, подвергаются MITM на основе атакам на понижение версии между предлагаемыми конфигурациями как с IKEv1, так и с IKEv2. [23] Этого можно избежать путем тщательного разделения клиентских систем на несколько точек доступа к услугам с более строгими конфигурациями.

Обе версии стандарта IKE подвержены атаке по словарю в автономном режиме, когда используется пароль с низкой энтропией. Для IKEv1 это справедливо для основного и агрессивного режимов. [24] [25] [26]

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Интернет-обмен ключами (IKE), RFC 2409, §1 Аннотация
  2. ^ Jump up to: а б Томас, М. (июнь 2001 г.), RFC 3129: Требования к керберизованному согласованию ключей в Интернете , Рабочая группа по разработке Интернета , стр. 1, номер домена : 10.17487/RFC3129
  3. ^ Ричардсон, М.; Редельмейер, Д.Х. (июнь 2001 г.), RFC 4322: Оппортунистическое шифрование с использованием обмена ключами в Интернете (IKE) , Рабочая группа по разработке Интернета , стр. 5, номер домена : 10.17487/RFC4322
  4. ^ Область интерпретации IP-безопасности Интернета для ISAKMP . дои : 10.17487/RFC2407 . РФК 2407 .
  5. ^ Ассоциация интернет-безопасности и протокол управления ключами (ISAKMP) . дои : 10.17487/RFC2408 . РФК 2408 .
  6. ^ Д. Харкинс. Интернет-обмен ключами (IKE) . дои : 10.17487/RFC2409 . РФК 2409 .
  7. ^ К. Кауфман (Microsoft) (декабрь 2005 г.). Протокол обмена ключами в Интернете (IKEv2) . дои : 10.17487/RFC4306 . RFC 4306 .
  8. ^ Эронен, П.; Хоффман, П. (октябрь 2006 г.). Пояснения и рекомендации по внедрению IKEv2 . дои : 10.17487/RFC4718 . РФК 4718 .
  9. ^ Кауфман, К.; Хоффман, П.; Нир, Ю.; Эронен, П. (сентябрь 2010 г.). Протокол обмена ключами в Интернете (IKEv2) . дои : 10.17487/RFC5996 . РФК 5996 .
  10. ^ Jump up to: а б с «RFC 2409 Интернет-обмен ключами (IKE)», Рабочая группа по разработке Интернета (IETF), стр. 5
  11. ^ «RFC 2409 Интернет-обмен ключами (IKE)», Рабочая группа по разработке Интернета (IETF), стр. 6
  12. ^ «RFC 2409 Интернет-обмен ключами (IKE)», Рабочая группа по разработке Интернета (IETF), стр. 10-16
  13. ^ «Протокол обмена ключами в Интернете (IKEv2) RFC 4306», Рабочая группа по проектированию Интернета (IETF), стр. 11,33
  14. ^ «RFC 4306: Протокол обмена ключами в Интернете (IKEv2)», Рабочая группа по проектированию Интернета (IETF), стр. 38-40.
  15. ^ Обмен ключами в Интернете: Безопасность интернет-протокола (IPsec): Technet
  16. ^ Использование IPSec в Windows 2000 и XP, часть 1.
  17. ^ «ОпенИКЕв2» . Гитхаб . Проверено 21 июня 2023 г.
  18. ^ «iked(8) — страницы руководства OpenBSD» . man.openbsd.org . Проверено 21 июня 2023 г.
  19. ^ Полевые возможности: Обзор конструкции сквозной VPN SPIN9 (PDF) , АНБ через «Der Spiegel», стр. 5
  20. ^ Адриан, Дэвид; Бхаргаван, Картикеян; Дурумерик, Закир; Годри, Пьеррик; Грин, Мэтью; Халдерман, Дж. Алекс; Хенингер, Надя ; Спринголл, Дрю; Томе, Эммануэль; Валента, Люк; ВандерСлот, Бенджамин; Вустроу, Эрик; Занелла-Бегелен, Сантьяго; Циммерманн, Пол (октябрь 2015 г.). Несовершенная прямая секретность: как Диффи-Хеллман терпит неудачу на практике (PDF) . 22-я конференция ACM по компьютерной и коммуникационной безопасности (CCS '15). Денвер . Проверено 15 июня 2016 г.
  21. ^ Ронен, Эяль; Шамир, Ади (октябрь 2015 г.). «Критический обзор несовершенной прямой секретности» (PDF) .
  22. ^ Воутерс, Пол (октябрь 2015 г.). «66% VPN на самом деле не сломаны» .
  23. ^ Бхаргаван, Картикеян; Бржуска, Кристина; Фурне, Седрик; Кольвайс, Маркульф; Занелла-Бегелен, Сантьяго; Грин, Мэтью (январь 2016 г.). «Понижение устойчивости протоколов обмена ключами» (PDF) .
  24. ^ Плиам, Джон (2 октября 1999 г.). «Уязвимости аутентификации в IKE и Xauth со слабыми предварительными секретами» . Университет Джонса Хопкинса . Архивировано из оригинала 10 июня 2002 года . Проверено 5 февраля 2020 г.
  25. ^ МакГрю, Дэвид (5 июля 2011 г.). «Отличный шифр, но где вы взяли этот ключ» . Блог Cisco . Архивировано из оригинала 9 июля 2011 года . Проверено 11 февраля 2020 г.
  26. ^ Фельш, Деннис (август 2018 г.). Опасности повторного использования ключей: практические атаки на IPsec IKE . ISBN  9781939133045 . Проверено 11 февраля 2020 г. {{cite book}}: |website= игнорируется ( помогите )
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Internet_Key_Exchange&oldid=1182945936"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 020574450c4849e9341a5ffaf078d311__1698824100
URL1:https://arc.ask3.ru/arc/aa/02/11/020574450c4849e9341a5ffaf078d311.html
Заголовок, (Title) документа по адресу, URL1:
Internet Key Exchange - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)