✖


Jump to content

IPsec

(Перенаправлено с IPSEC )
IPsec
Безопасность интернет-протокола
Год начался 1996
Организация Целевая группа по интернет-инжинирингу
Базовые стандарты Различные, см. главу документации IETF.
Набор интернет-протоколов
Прикладной уровень
Транспортный уровень
Интернет-слой
Слой связи

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

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

История

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

Начиная с начала 1970-х годов, Агентство перспективных исследовательских проектов спонсировало серию экспериментальных устройств шифрования ARPANET , сначала для собственного шифрования пакетов ARPANET , а затем для TCP/IP шифрования пакетов ; некоторые из них были сертифицированы и внедрены. С 1986 по 1991 год АНБ спонсировало разработку протоколов безопасности для Интернета в рамках своей программы Secure Data Network Systems (SDNS). [ 2 ] Это объединило различных поставщиков, включая Motorola , которая выпустила устройство сетевого шифрования в 1988 году. Работа была открыто опубликована примерно с 1988 года NIST , и из них протокол безопасности на уровне 3 (SP3) в конечном итоге превратился в стандартный протокол безопасности сетевого уровня ISO. (НЛСП). [ 3 ]

США Исследовательскую лабораторию ВМС В 1992 году DARPA CSTO финансировала (NRL) для внедрения IPv6, а также для исследования и внедрения IP-шифрования в 4.4 BSD , поддерживающего архитектуры процессоров SPARC и x86. DARPA предоставило бесплатный доступ к своей реализации через MIT. NRL, финансируемой DARPA В рамках исследовательской работы , NRL разработала спецификации стандартов IETF (RFC 1825–RFC 1827) для IPsec. [ 4 ] Реализация IPsec компании NRL была описана в их статье в материалах конференции USENIX 1996 года . [ 5 ] Реализация IPsec с открытым исходным кодом NRL была размещена в Интернете MIT и стала основой для большинства первоначальных коммерческих реализаций. [ 4 ]

( В 1992 году Инженерная группа Интернета IETF) сформировала Рабочую группу по IP-безопасности. [ 6 ] стандартизировать открыто указанные расширения безопасности для IP, называемые IPsec . [ 7 ] Стандарты, разработанные NRL, были опубликованы IETF под номерами RFC-1825–RFC-1827. [ 8 ]

Архитектура безопасности

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

Первоначальный пакет IPv4 был разработан с небольшим количеством мер безопасности. В рамках усовершенствования IPv4 IPsec представляет собой уровня 3 модель OSI или интернет-уровня схему сквозной безопасности . Напротив, в то время как некоторые другие широко используемые системы интернет-безопасности работают выше сетевого уровня , такие как Transport Layer Security (TLS), который работает над транспортным уровнем , и Secure Shell (SSH), который работает на уровне приложений , IPsec может автоматически защищать приложения. на уровне Интернета .

IPsec — это открытый стандарт , являющийся частью пакета IPv4, который использует следующие протоколы для выполнения различных функций: [ 9 ] [ 10 ]

Заголовок аутентификации

[ редактировать ]
Использование формата заголовка аутентификации IPsec в туннельном и транспортном режимах

Заголовок аутентификации безопасности (AH) был разработан в Исследовательской лаборатории ВМС США в начале 1990-х годов и частично основан на предыдущих разработках стандартов IETF для аутентификации протокола простого сетевого управления (SNMP) версии 2. Заголовок аутентификации (AH) член набора протоколов IPsec. AH обеспечивает целостность без установления соединения с помощью хэш-функции и секретного общего ключа в алгоритме AH. AH также гарантирует происхождение данных путем аутентификации IP- пакетов . При необходимости порядковый номер может защитить содержимое пакета IPsec от атак повторного воспроизведения . [ 18 ] [ 19 ] используя технику скользящего окна и отбрасывая старые пакеты.

  • В IPv4 AH предотвращает атаки с вставкой опций. В IPv6 AH защищает как от атак с вставкой заголовка, так и от атак с вставкой опций.
  • В IPv4 AH защищает полезную нагрузку IP и все поля заголовка IP-дейтаграммы, за исключением изменяемых полей (т. е. тех, которые могут быть изменены при передаче), а также таких параметров IP, как опция IP Security Option (RFC 1108). Изменяемыми (и, следовательно, неаутентифицированными) полями заголовка IPv4 являются DSCP / ToS , ECN , Flags, Fragment Offset , TTL и Контрольная сумма заголовка . [ 12 ]
  • В IPv6 AH защищает большую часть базового заголовка IPv6, сам AH, неизменяемые заголовки расширения после AH и полезную нагрузку IP. Защита заголовка IPv6 исключает изменяемые поля: DSCP , ECN , Flow Label и Hop Limit. [ 12 ]

AH работает непосредственно поверх IP, используя протокол IP номер 51 . [ 20 ]

На следующей диаграмме пакетов AH показано, как создается и интерпретируется пакет AH: [ 11 ] [ 12 ]

заголовка аутентификации Формат
Смещения Октет 16 0 1 2 3
Октет 16 Бит 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Следующий заголовок Полезная нагрузка Лен Сдержанный
4 32 Индекс параметров безопасности (SPI)
8 64 Порядковый номер
С 96 Значение проверки целостности (ICV)
...
... ...
Следующий заголовок (8 бит)
Тип следующего заголовка, указывающий, какой протокол верхнего уровня был защищен. Значение берется из списка номеров IP-протокола .
Полезная нагрузка Len (8 бит)
Длина этого заголовка аутентификации в модулях по 4 октета минус 2. Например, значение AH, равное 4, равно 3 × (32-битные поля AH фиксированной длины) + 3 × (32-битные поля ICV) − 2 и, таким образом, значение AH, равное 4, означает 24 октета. Хотя размер измеряется в блоках по 4 октета, длина этого заголовка должна быть кратна 8 октетам, если он передается в пакете IPv6. Это ограничение не распространяется на заголовок аутентификации, содержащийся в пакете IPv4.
Зарезервировано (16 бит)
Зарезервировано для будущего использования (до этого все нули).
Индекс параметров безопасности (32 бита)
Произвольное значение, которое используется (вместе с IP-адресом назначения) для идентификации ассоциации безопасности принимающей стороны.
Порядковый номер (32 бита)
Монотонно строго возрастающий порядковый номер (увеличивается на 1 для каждого отправленного пакета) для предотвращения атак повторного воспроизведения . Если включено обнаружение повтора, порядковые номера никогда не используются повторно, поскольку перед попыткой увеличить порядковый номер сверх его максимального значения необходимо повторно согласовать новую ассоциацию безопасности. [ 12 ]
Значение проверки целостности (кратное 32 битам)
Проверочное значение переменной длины. Он может содержать дополнения для выравнивания поля по границе в 8 октетов для IPv6 или по границе в 4 октета для IPv4 .

Инкапсуляция полезных данных безопасности

[ редактировать ]
Использование IPsec, инкапсулирующей полезную нагрузку безопасности (ESP) в туннельном и транспортном режимах

Полезная нагрузка безопасности, инкапсулирующая IP (ESP) [ 21 ] был разработан в Военно-морской исследовательской лаборатории в 1992 году в рамках исследовательского проекта, спонсируемого DARPA , и был открыто опубликован IETF SIPP. [ 22 ] Рабочая группа разработала в декабре 1993 года как расширение безопасности для SIPP. Этот ESP Министерства обороны США изначально был основан на протоколе SP3D , а не на основе протокола безопасности сетевого уровня ISO (NLSP). Спецификация протокола SP3D была опубликована NIST в конце 1980-х годов, но разработана в рамках проекта Secure Data Network System Министерства обороны США . Инкапсуляция полезных данных безопасности (ESP) является членом набора протоколов IPsec. Он обеспечивает подлинность источника источника посредством аутентификации , целостность данных посредством хеш-функций и конфиденциальность посредством шифрования IP- пакетов . ESP также поддерживает конфигурации «только шифрование» и «только аутентификация» , но использование шифрования без аутентификации настоятельно не рекомендуется, поскольку оно небезопасно. [ 23 ] [ 24 ] [ 25 ]

В отличие от заголовка аутентификации (AH) , ESP в транспортном режиме не обеспечивает целостность и аутентификацию всего IP-пакета . Однако в туннельном режиме , когда весь исходный IP-пакет инкапсулируется с добавлением нового заголовка пакета, защита ESP предоставляется всему внутреннему IP-пакету (включая внутренний заголовок), в то время как внешний заголовок (включая любые внешние параметры IPv4 или расширения IPv6) заголовки) остается незащищенным.

ESP работает непосредственно поверх IP, используя протокол IP номер 50. [ 20 ]

На следующей диаграмме пакетов ESP показано, как создается и интерпретируется пакет ESP: [ 1 ] [ 26 ]

Инкапсуляция формата полезных данных безопасности
Смещения Октет 16 0 1 2 3
Октет 16 Бит 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Индекс параметров безопасности (SPI)
4 32 Порядковый номер
8 64 Данные полезной нагрузки
... ...
... ...    
... ...   Заполнение (0–255 октетов)  
... ...   Длина колодки Следующий заголовок
... ... Значение проверки целостности (ICV)
...
... ...
Индекс параметров безопасности (32 бита)
Произвольное значение, используемое (вместе с IP-адресом назначения) для идентификации ассоциации безопасности принимающей стороны.
Порядковый номер (32 бита)
Монотонно увеличивающийся порядковый номер (увеличиваемый на 1 для каждого отправленного пакета) для защиты от атак повторного воспроизведения . Для каждой ассоциации безопасности имеется отдельный счетчик.
Данные полезной нагрузки (переменная)
Защищенное содержимое исходного IP-пакета, включая любые данные, используемые для защиты содержимого (например, вектор инициализации для криптографического алгоритма). Тип защищенного содержимого указывается в поле «Следующий заголовок» .
Заполнение (0–255 октетов)
Заполнение для шифрования, чтобы расширить полезные данные до размера, соответствующего шифрования размеру блока , и выровнять следующее поле.
Длина площадки (8 бит)
Размер заполнения (в октетах).
Следующий заголовок (8 бит)
Тип следующего заголовка. Значение берется из списка номеров IP-протокола .
Значение проверки целостности (кратное 32 битам)
Проверочное значение переменной длины. Он может содержать дополнения для выравнивания поля по границе в 8 октетов для IPv6 или по границе в 4 октета для IPv4 .

Ассоциация безопасности

[ редактировать ]
Основная статья: Ассоциация безопасности

Протоколы IPsec используют ассоциацию безопасности , при которой взаимодействующие стороны устанавливают общие атрибуты безопасности, такие как алгоритмы и ключи. Таким образом, IPsec предоставляет ряд возможностей после определения того, используется ли AH или ESP. Перед обменом данными два хоста согласовывают, какой алгоритм симметричного шифрования используется для шифрования IP-пакета, например AES или ChaCha20 , и какая хеш-функция используется для обеспечения целостности данных, например BLAKE2 или SHA256 . Эти параметры согласовываются для конкретного сеанса, для которого необходимо согласовать время жизни и ключ сеанса . [ 27 ]

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

Ассоциации безопасности IPsec устанавливаются с использованием ассоциации безопасности Интернета и протокола управления ключами (ISAKMP). ISAKMP реализуется путем ручной настройки с использованием предварительно общих секретов, Интернет-обмена ключами (IKE и IKEv2), Kerberized Интернет-согласования ключей (KINK) и использования DNS-записей IPSECKEY . [ 17 ] [ 29 ] [ 30 ] RFC 5386 определяет безопасность «лучше, чем ничего» (BTNS) как режим IPsec без аутентификации с использованием расширенного протокола IKE. К. Медоуз, К. Кремерс и другие использовали формальные методы для выявления различных аномалий, существующих в IKEv1, а также в IKEv2. [ 31 ]

Чтобы решить, какую защиту обеспечить для исходящего пакета, IPsec использует индекс параметров безопасности (SPI), индекс базы данных ассоциаций безопасности (SADB), а также адрес назначения в заголовке пакета, которые вместе однозначно идентифицируют ассоциация безопасности для этого пакета. Аналогичная процедура выполняется для входящего пакета, где IPsec собирает ключи дешифрования и проверки из базы данных ассоциаций безопасности.

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

Поддержка активности

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

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

Обнаружение мертвого узла (DPD) — это метод обнаружения неработающего узла обмена ключами в Интернете (IKE). Этот метод использует шаблоны трафика IPsec, чтобы минимизировать количество сообщений, необходимых для подтверждения доступности узла. DPD используется для восстановления потерянных ресурсов в случае, если одноранговый узел оказывается неработающим, а также для выполнения аварийного переключения однорангового узла IKE.

Поддержка активности UDP является альтернативой DPD.

Режимы работы

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

Протоколы IPsec AH и ESP могут быть реализованы в режиме транспорта между хостами, а также в режиме сетевого туннелирования.

Режимы IPsec

Вид транспорта

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

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

Средство инкапсуляции сообщений IPsec для прохождения NAT {NAT-T} определено в документах RFC, описывающих механизм NAT-T.

Туннельная мода

[ редактировать ]
Основная статья: Протокол туннелирования

В туннельном режиме весь IP-пакет шифруется и аутентифицируется. Затем он инкапсулируется в новый IP-пакет с новым IP-заголовком. Туннельный режим используется для создания виртуальных частных сетей для связи между сетями (например, между маршрутизаторами для связи сайтов), связи между хостами (например, удаленный доступ пользователей) и связи между хостами (например, приватный чат). [ 32 ]

Туннельный режим поддерживает обход NAT.

Алгоритмы

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

Алгоритмы симметричного шифрования

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

Криптографические алгоритмы, определенные для использования с IPsec, включают:

Подробности см. в RFC 8221.

Алгоритмы обмена ключами

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

Алгоритмы аутентификации

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

Реализации

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

IPsec может быть реализован в стеке IP операционной системы . Этот метод реализации применяется для хостов и шлюзов безопасности. Различные IP-стеки с поддержкой IPsec доступны от таких компаний, как HP или IBM. [ 33 ] Альтернативой является так называемая реализация «bump-in-the-stack» (BITS), при которой исходный код операционной системы не требует изменения. Здесь IPsec устанавливается между стеком IP и сетевыми драйверами . Таким образом, операционные системы могут быть оснащены IPsec. Этот метод реализации также используется как для хостов, так и для шлюзов. Однако при модернизации IPsec инкапсуляция IP-пакетов может вызвать проблемы при автоматическом обнаружении MTU пути , где максимальный размер единицы передачи устанавливается (MTU) на сетевом пути между двумя IP-узлами. Если хост или шлюз имеет отдельный криптопроцессор , который распространен в армии, а также может быть найден в коммерческих системах, «bump-in-the-wire » (BITW). возможна так называемая реализация IPsec по схеме [ 34 ]

Когда IPsec реализован в ядре , управление ключами и согласование ISAKMP / IKE осуществляется из пространства пользователя. Разработанный NRL и открыто указанный «API управления ключами PF_KEY, версия 2» часто используется, чтобы позволить приложению управления ключами в пространстве приложения обновлять ассоциации безопасности IPsec, хранящиеся в реализации IPsec в пространстве ядра. [ 35 ] Существующие реализации IPsec обычно включают ESP, AH и IKE версии 2. Существующие реализации IPsec в Unix-подобных операционных системах , например, Solaris или Linux , обычно включают PF_KEY версии 2.

Встроенный IPsec можно использовать для обеспечения безопасной связи между приложениями, работающими в системах с ограниченными ресурсами, с небольшими накладными расходами. [ 36 ]

Статус стандартов

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

IPsec был разработан совместно с IPv6 и изначально должен был поддерживаться всеми соответствующими стандартам реализациями IPv6, прежде чем RFC 6434 сделал его только рекомендацией. [ 37 ] IPsec также является необязательным для IPv4 реализаций . IPsec чаще всего используется для защиты трафика IPv4. [ нужна ссылка ]

Первоначально протоколы IPsec были определены в RFC 1825–RFC 1829, которые были опубликованы в 1995 году. В 1998 году эти документы были заменены RFC 2401 и RFC 2412 с некоторыми несовместимыми техническими деталями, хотя концептуально они были идентичны. протокол взаимной аутентификации и обмена ключами Internet Key Exchange Кроме того, был определен (IKE) для создания ассоциаций безопасности и управления ими. В декабре 2005 года новые стандарты были определены в RFC 4301 и RFC 4309, которые во многом представляют собой расширенный набор предыдущих редакций со второй версией стандарта обмена ключами в Интернете IKEv2 . Эти документы третьего поколения стандартизировали сокращение IPsec на прописные буквы «IP» и строчные буквы «sec». «ESP» обычно относится к RFC 4303, который является самой последней версией спецификации.

С середины 2008 года в IETF действует рабочая группа по обслуживанию и расширению IPsec (ipsecme). [ 38 ] [ 39 ]

Предполагаемое вмешательство АНБ

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

В 2013 году в рамках утечек Сноудена выяснилось, что Агентство национальной безопасности США активно работало над «вставкой уязвимостей в коммерческие системы шифрования, ИТ-системы, сети и конечные коммуникационные устройства, используемые целями» в рамках Bullrun программы . . [ 40 ] Есть утверждения, что IPsec был целевой системой шифрования. [ 41 ]

Стек OpenBSD IPsec появился позже и также широко копировался. В письме, которое OpenBSD ведущий разработчик Тео де Раадт получил 11 декабря 2010 года от Грегори Перри, утверждается, что Джейсон Райт и другие, работающие на ФБР, внедрили «ряд бэкдоров и механизмов утечки ключей по побочным каналам » в криптографическую систему OpenBSD. код. В пересланном электронном письме от 2010 года Тео де Раадт сначала не выразил официальную позицию относительно обоснованности претензий, за исключением неявного одобрения пересылки электронного письма. [ 42 ] Ответ Джейсона Райта на обвинения: «Каждая городская легенда становится более реальной благодаря включению реальных имен, дат и времени. Электронная почта Грегори Перри попадает в эту категорию… Я четко заявляю, что я не добавлял бэкдоры в операционную систему OpenBSD. системы или криптографической инфраструктуры OpenBSD (OCF)». [ 43 ] Несколько дней спустя де Раадт прокомментировал: «Я считаю, что NETSEC, вероятно, заключила контракт на написание бэкдоров, как утверждается… Если они были написаны, я не верю, что они попали в наше дерево». [ 44 ] Это было опубликовано до утечки информации о Сноудене.

Альтернативное объяснение, выдвинутое авторами атаки Logjam, предполагает, что АНБ скомпрометировало IPsec VPN, подорвав алгоритм Диффи-Хеллмана, используемый при обмене ключами. В своей статье [ 45 ] они утверждают, что АНБ специально создало вычислительный кластер для предварительного вычисления мультипликативных подгрупп для определенных простых чисел и генераторов, например, для второй группы Окли, определенной в RFC 2409. По состоянию на май 2015 года 90% адресных IPsec VPN поддерживали вторую группу Окли как часть АЙК. Если бы организация предварительно вычислила эту группу, она могла бы получить ключи, которыми обмениваются, и расшифровать трафик без использования каких-либо программных бэкдоров.

Второе альтернативное объяснение, которое было выдвинуто, заключалось в том, что Equation Group использовала эксплойты нулевого дня против VPN-оборудования нескольких производителей, которое было проверено « Лабораторией Касперского» как связанное с Equation Group. [ 46 ] и подтверждены этими производителями как настоящие эксплойты, некоторые из которых на момент раскрытия были эксплойтами нулевого дня. [ 47 ] [ 48 ] [ 49 ] Межсетевые экраны Cisco PIX и ASA имели уязвимости, которые использовались АНБ для прослушивания телефонных разговоров. [ нужна ссылка ] .

Кроме того, сети IPsec VPN, использующие настройки «агрессивного режима», отправляют хэш PSK в открытом виде. Это может быть целью АНБ, которая, по всей видимости, нацелена на использование автономных атак по словарю . [ 45 ] [ 50 ] [ 51 ]

документация IETF

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

Стандарты трека

[ редактировать ]
  • RFC 1829 : Преобразование ESP DES-CBC
  • RFC 2403 : Использование HMAC-MD5-96 в ESP и AH.
  • RFC 2404 : Использование HMAC-SHA-1-96 в ESP и AH.
  • RFC 2405 : Алгоритм шифрования ESP DES-CBC с явным IV
  • RFC 2410 : Алгоритм NULL-шифрования и его использование с IPsec
  • RFC 2451 : Алгоритмы шифрования ESP в режиме CBC
  • RFC 2857 : Использование HMAC-RIPEMD-160-96 в ESP и AH.
  • RFC 3526 : Больше модульных экспоненциальных (MODP) групп Диффи-Хеллмана для обмена ключами в Интернете (IKE).
  • RFC 3602 : Алгоритм шифрования AES-CBC и его использование с IPsec
  • RFC 3686 : Использование режима счетчика расширенного стандарта шифрования (AES) с IPsec, инкапсулирующим полезные данные безопасности (ESP)
  • RFC 3947 : Согласование NAT-обхода в IKE
  • RFC 3948 : UDP-инкапсуляция пакетов IPsec ESP
  • RFC 4106 : Использование режима Галуа/счетчика (GCM) в инкапсуляции полезных данных безопасности IPsec (ESP)
  • RFC 4301 : Архитектура безопасности для интернет-протокола.
  • RFC 4302 : заголовок IP-аутентификации.
  • RFC 4303 : IP-инкапсуляция полезных данных безопасности
  • RFC 4304 : Дополнение к расширенному порядковому номеру (ESN) к домену интерпретации IPsec (DOI) для ассоциации безопасности Интернета и протокола управления ключами (ISAKMP).
  • RFC 4307 : Криптографические алгоритмы для использования в обмене ключами в Интернете, версия 2 ( IKEv2 )
  • RFC 4308 : Криптографические наборы для IPsec.
  • RFC 4309 : использование расширенного стандарта шифрования (AES) режима CCM с IPsec, инкапсулирующей полезную нагрузку безопасности (ESP)
  • RFC 4543 : Использование кода аутентификации сообщения Галуа (GMAC) в IPsec ESP и AH.
  • RFC 4555 : Протокол мобильности и множественной адресации IKEv2 (MOBIKE)
  • RFC 4806 : Расширения протокола статуса онлайн-сертификатов (OCSP) для IKEv2
  • RFC 4868 : использование HMAC-SHA-256 , HMAC-SHA-384 и HMAC-SHA-512 с IPsec.
  • RFC 4945 : Профиль PKI IP-безопасности Интернета для IKEv1/ISAKMP, IKEv2 и PKIX.
  • RFC 5280 : Профиль сертификата инфраструктуры открытых ключей Internet X.509 и списка отзыва сертификатов (CRL)
  • RFC 5282 : Использование алгоритмов шифрования с проверкой подлинности с зашифрованной полезной нагрузкой протокола обмена ключами в Интернете версии 2 (IKEv2)
  • RFC 5386 : Безопасность «лучше, чем ничего»: режим IPsec без аутентификации
  • RFC 5529 : Режимы работы Camellia для использования с IPsec
  • RFC 5685 : Механизм перенаправления для протокола обмена ключами в Интернете версии 2 (IKEv2).
  • RFC 5723 : возобновление сеанса протокола обмена ключами Интернета версии 2 (IKEv2)
  • RFC 5857 : Расширения IKEv2 для поддержки надежного сжатия заголовков через IPsec
  • RFC 5858 : Расширения IPsec для поддержки надежного сжатия заголовков через IPsec.
  • RFC 7296 : Протокол обмена ключами в Интернете версии 2 (IKEv2).
  • RFC 7321 : Требования к реализации криптографического алгоритма и руководство по использованию для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH)
  • RFC 7383 : Фрагментация сообщений протокола обмена ключами в Интернете версии 2 (IKEv2).
  • RFC 7427 : Аутентификация подписи в обмене ключами через Интернет, версия 2 (IKEv2)
  • RFC 7634 : ChaCha20, Poly1305 и их использование в протоколе обмена ключами в Интернете (IKE) и IPsec.

Экспериментальные RFC

[ редактировать ]
  • RFC 4478 : Повторная аутентификация в протоколе обмена ключами в Интернете (IKEv2).

Информационные RFC

[ редактировать ]
  • RFC 2367 : Интерфейс PF_KEY
  • RFC 2412 : Протокол определения ключей OAKLEY.
  • RFC 3706 : метод обнаружения мертвых узлов обмена ключами в Интернете (IKE) на основе трафика
  • RFC 3715 : Требования совместимости IPsec-трансляции сетевых адресов (NAT)
  • RFC 4621 : Разработка протокола мобильности и множественной адресации IKEv2 (MOBIKE).
  • RFC 4809 : Требования к профилю управления сертификатами IPsec
  • RFC 5387 : Положение о проблеме и применимости для системы безопасности «лучше, чем ничего» (BTNS)
  • RFC 5856 : Интеграция надежного сжатия заголовков в ассоциации безопасности IPsec.
  • RFC 5930 : Использование стандартного режима счетчика расширенного шифрования (AES-CTR) с протоколом Интернет-обмена ключами версии 02 (IKEv2).
  • RFC 6027 : Постановка проблемы кластера IPsec
  • RFC 6071 : Дорожная карта документа IPsec и IKE
  • RFC 6379 : Suite B для IPsec Криптографические пакеты
  • RFC 6380 : Профиль Suite B для безопасности интернет-протокола (IPsec)
  • RFC 6467 : Структура безопасных паролей для обмена ключами в Интернете версии 2 (IKEv2)

Лучшие современные практики RFC

[ редактировать ]
  • RFC 5406 : Рекомендации по использованию IPsec версии 2.

Устаревшие/исторические RFC

[ редактировать ]
  • RFC 1825 : Архитектура безопасности для интернет-протокола (устарело из-за RFC 2401).
  • RFC 1826 : заголовок IP-аутентификации (устарело из-за RFC 2402).
  • RFC 1827 : Полезная нагрузка безопасности, инкапсулирующая IP (ESP) (устарело из-за RFC 2406)
  • RFC 1828 : Аутентификация IP с использованием ключа MD5 (исторический)
  • RFC 2401 : Архитектура безопасности для интернет-протокола (обзор IPsec) (устарело из-за RFC 4301)
  • RFC 2406 : Полезная нагрузка безопасности, инкапсулирующая IP (ESP) (устарело из-за RFC 4303 и RFC 4305)
  • RFC 2407 : домен интерпретации IP-безопасности Интернета для ISAKMP (устарел RFC 4306)
  • RFC 2409 : Интернет-обмен ключами (устарело из-за RFC 4306).
  • RFC 4305 : Требования к реализации криптографического алгоритма для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH) (устарело в RFC 4835)
  • RFC 4306 : протокол обмена ключами в Интернете (IKEv2) (устарел благодаря RFC 5996).
  • RFC 4718 : Разъяснения и рекомендации по реализации IKEv2 (устарело из-за RFC 7296)
  • RFC 4835 : Требования к реализации криптографического алгоритма для инкапсуляции полезной нагрузки безопасности (ESP) и заголовка аутентификации (AH) (устарело в RFC 7321)
  • RFC 5996 : протокол обмена ключами в Интернете версии 2 (IKEv2) (устарел из-за RFC 7296).

См. также

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

Ссылки

[ редактировать ]
  1. ^ Jump up to: а б с Кент, С.; Аткинсон, Р. (ноябрь 1998 г.). Полезная нагрузка безопасности, инкапсулирующая IP (ESP) . IETF . дои : 10.17487/RFC2406 . РФК 2406 .
  2. ^ Дхалл, Хитеш; Дхалл, Долли; Батра, Соня; Рани, Пуджа (2012). «Реализация протокола IPSec» . 2012 Вторая международная конференция по передовым вычислительным и коммуникационным технологиям . ИИЭЭ . стр. 176–181. дои : 10.1109/ACCT.2012.64 . ISBN  978-1-4673-0471-9 . S2CID   16526652 .
  3. ^ Гилмор, Джон. «Сетевое шифрование – история и патенты» . Архивировано из оригинала 3 сентября 2014 г. Проверено 18 февраля 2014 г.
  4. ^ Jump up to: а б «Страница распространения IPv6 + IPSEC + ISAKMP» . web.mit.edu .
  5. ^ «ЕЖЕГОДНАЯ ТЕХНИЧЕСКАЯ КОНФЕРЕНЦИЯ USENIX 1996 ГОДА» . www.usenix.org .
  6. ^ «Протокол IP-безопасности (ipsec) —» . datatracker.ietf.org .
  7. ^ Со, Карен; Кент, Стивен (декабрь 2005 г.). Архитектура безопасности Интернет-протокола . Сетевая рабочая группа IETF. п. 4. дои : 10.17487/RFC4301 . РФК 4301 . Написание «IPsec» является предпочтительным и используется в этом и всех связанных стандартах IPsec. Все другие варианты написания IPsec [...] с заглавной буквы устарели.
  8. ^ «Достижения NRL ITD — IPSec и IPv6» (PDF) . Исследовательские лаборатории ВМС США . Архивировано (PDF) из оригинала 15 сентября 2015 г.
  9. ^ Тайер, Р.; Дорасвами, Н.; Гленн, Р. (ноябрь 1998 г.). Дорожная карта документа по IP-безопасности . IETF . дои : 10.17487/RFC2411 . РФК 2411 .
  10. ^ Хоффман, П. (декабрь 2005 г.). Криптографические пакеты для IPsec . IETF . дои : 10.17487/RFC4308 . RFC 4308 .
  11. ^ Jump up to: а б Кент, С.; Аткинсон, Р. (ноябрь 1998 г.). Заголовок IP-аутентификации . IETF . дои : 10.17487/RFC2402 . РФК 2402 .
  12. ^ Jump up to: а б с д и Кент, С. (декабрь 2005 г.). Заголовок IP-аутентификации . IETF . дои : 10.17487/RFC4302 . РФК 4302 .
  13. ^ Интернет -обмен ключами (IKE), RFC 2409, §1 Аннотация
  14. ^ Харкинс, Д.; Каррел, Д. (ноябрь 1998 г.). Интернет-обмен ключами (IKE) . IETF . дои : 10.17487/RFC2409 . РФК 2409 .
  15. ^ Кауфман, К. (ред.). ИКЕ версии 2 . IETF . дои : 10.17487/RFC4306 . RFC 4306 .
  16. ^ Сакане, С.; Камада, К.; Томас, М.; Вилхубер, Дж. (ноябрь 1998 г.). Керберизованное Интернет-согласование ключей (KINK) . IETF . дои : 10.17487/RFC4430 . РФК 4430 .
  17. ^ Jump up to: а б Ричардсон, М. (февраль 2005 г.). Метод хранения данных ключей IPsec в DNS . IETF . дои : 10.17487/RFC4025 . РФК 4025 .
  18. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. п. 270. ИСБН  9780852969823 .
  19. ^ Р. Ширей (август 2007 г.). Глоссарий по интернет-безопасности, версия 2 . Сетевая рабочая группа. дои : 10.17487/RFC4949 . РФК 4949 . Информационный.
  20. ^ Jump up to: а б «Номера протоколов» . ИАНА . 27 мая 2010 г. Архивировано из оригинала 29 мая 2010 г.
  21. ^ «Инкапсуляция полезной нагрузки безопасности SIPP» . Рабочая группа IETF SIPP. 1993. Архивировано из оригинала 9 сентября 2016 г. Проверено 7 августа 2013 г.
  22. ^ Диринг, Стив Э. (1993). «Проект спецификации SIPP» . IETF. п. 21.
  23. ^ Белловин, Стивен М. (1996). «Проблемные области протоколов IP-безопасности» ( PostScript ) . Материалы шестого симпозиума по безопасности Usenix Unix . Сан-Хосе, Калифорния. стр. 1–16 . Проверено 9 июля 2007 г.
  24. ^ Патерсон, Кеннет Г.; Яу, Арнольд К.Л. (24 апреля 2006 г.). «Криптография в теории и практике: случай шифрования в IPsec» (PDF) . Eurocrypt 2006, Конспекты лекций по информатике, том. 4004 . Берлин. стр. 12–29 . Проверено 13 августа 2007 г.
  25. ^ Дегабриэль, Жан Поль; Патерсон, Кеннет Г. (9 августа 2007 г.). «Атака на стандарты IPsec в конфигурациях только с шифрованием» (PDF) . Симпозиум IEEE по безопасности и конфиденциальности, Компьютерное общество IEEE . Окленд, Калифорния. стр. 335–349 . Проверено 13 августа 2007 г.
  26. ^ Кент, С. (декабрь 2005 г.). Полезная нагрузка безопасности, инкапсулирующая IP (ESP) . IETF . дои : 10.17487/RFC4303 . RFC 4303 .
  27. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. п. 271. ИСБН  9780852969823 .
  28. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. стр. 272–3. ISBN  9780852969823 .
  29. ^ RFC 2406, §1, стр. 2
  30. ^ Томас, М. (июнь 2001 г.). Требования к керберизованному согласованию ключей в Интернете . дои : 10.17487/RFC3129 . РФК 3129 .
  31. ^ К. Кремерс (2011). Возвращение к обмену ключами в IPsec: формальный анализ IKEv1 и IKEv2, ESORICS 2011 . Конспекты лекций по информатике. Спрингер. стр. 315–334. дои : 10.1007/978-3-642-23822-2_18 . hdl : 20.500.11850/69608 . ISBN  9783642238222 . S2CID   18222662 .
  32. ^ Уильям С. и Столлингс В. (2006). Криптография и сетевая безопасность, 4/Э. Пирсон Образовательная Индия. п. 492-493
  33. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. п. 266. ИСБН  9780852969823 .
  34. ^ Питер Уиллис (2001). IP-сети операторского масштаба: проектирование и эксплуатация сетей Интернет . ИЭПП. п. 267. ИСБН  9780852969823 .
  35. ^ RFC 2367, API управления ключами PF_KEYv2 , Дэн Макдональд, Бао Фан и Крейг Мец (июль 1998 г.)
  36. ^ Хамад, Мохаммед; Превелакис, Василис (2015). «Внедрение и оценка производительности встроенного IPsec в микроядерной ОС». Всемирный симпозиум по компьютерным сетям и информационной безопасности (WSCNIS) 2015 г. IEEE. стр. 1–7. дои : 10.1109/wscnis.2015.7368294 . ISBN  9781479999064 . S2CID   16935000 .
  37. ^ RFC 6434, «Требования к узлу IPv6», Э. Янкевич, Дж. Лоуни, Т. Нартен (декабрь 2011 г.)
  38. ^ «Устав ipsecme» . Проверено 26 октября 2015 г.
  39. ^ «статус ipsecme» . Проверено 26 октября 2015 г.
  40. ^ «Секретные документы раскрывают кампанию АНБ против шифрования» . Нью-Йорк Таймс .
  41. ^ Джон Гилмор. «Re: [Криптография] Вступительная дискуссия: Спекуляции на тему «BULLRUN» » .
  42. ^ Тео де Раадт. «Обвинения относительно OpenBSD IPSEC» .
  43. ^ Джейсон Райт. «Обвинения относительно OpenBSD IPSEC» .
  44. ^ Тео де Раадт. «Обновленная информация по обвинению в бэкдоре OpenBSD IPSEC» .
  45. ^ Jump up to: а б Адриан, Дэвид; Бхаргаван, Картикеян; Дурумерик, Закир; Годри, Пьеррик; Грин, Мэтью; Халдерман, Дж. Алекс; Хенингер, Надя; Спринголл, Дрю; Томе, Эммануэль; Валента, Люк; Вандерслот, Бенджамин; Вустроу, Эрик; Занелла-Бегелен, Сантьяго; Циммерманн, Пол (2015). «Несовершенная прямая секретность» . Материалы 22-й конференции ACM SIGSAC по компьютерной и коммуникационной безопасности . стр. 5–17. дои : 10.1145/2810103.2813707 . ISBN  9781450338325 . S2CID   347988 .
  46. ^ Гудин, Дэн (16 августа 2016 г.). «Подтверждено: утечка хакерского инструмента произошла от «всемогущей» группы, связанной с АНБ» . Арс Техника . Проверено 19 августа 2016 г.
  47. ^ Томсон, Иэн (17 августа 2016 г.). «Cisco подтверждает, что две уязвимости «АНБ» Shadow Brokers реальны» . Регистр . Проверено 16 сентября 2016 г.
  48. ^ Паули, Даррен (24 августа 2016 г.). «Эксплойт Equation Group поражает новую версию Cisco ASA, Juniper Netscreen» . Регистр . Проверено 16 сентября 2016 г.
  49. ^ Чиргвин, Ричард (18 августа 2016 г.). «Fortinet следует за Cisco в подтверждении уязвимости Shadow Broker» . Регистр . Проверено 16 сентября 2016 г.
  50. ^ «Обмен ключами. Каковы проблемы агрессивного режима IKEv1 (по сравнению с основным режимом IKEv1 или IKEv2)?» . Обмен стеками криптографии .
  51. ^ «Пока не прекращайте использовать IPsec» . Никаких шляп . 29 декабря 2014 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=IPsec&oldid=1234760931"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: ccd2544b994cf1499fa9bf36f8951ce1__1721080380
URL1:https://arc.ask3.ru/arc/aa/cc/e1/ccd2544b994cf1499fa9bf36f8951ce1.html
Заголовок, (Title) документа по адресу, URL1:
IPsec - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)