Курс лекций «Проблемы безопасности в информационных технологиях»


Обеспечение безопасности уровня IP – набор протоколов IPSec



жүктеу 4.51 Mb.
бет25/44
Дата13.09.2017
өлшемі4.51 Mb.
түріКурс лекций
1   ...   21   22   23   24   25   26   27   28   ...   44

Обеспечение безопасности уровня IP – набор протоколов IPSec


IPSec (сокращение от IP Security) — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет. Чаще всего применяется для организации VPN-соединений.

IPSec – это очень большой, весьма «тяжёлый» и объёмный набор стандартов. Достаточно взглянуть на список RFC, описывающих семейство протоколов IPSec:


  • RFC 2401 (Security Architecture for the Internet Protocol) — Архитектура защиты для протокола IP.

  • RFC 2402 (IP Authentication header) — Аутентификационный заголовок IP.

  • RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) — Использование алгоритма хэширования MD-5 для создания аутентификационного заголовка.

  • RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) — Использование алгоритма хэширования SHA-1 для создания аутентификационного заголовка.

  • RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) — Использование алгоритма шифрования DES.

  • RFC 2406 (IP Encapsulating Security Payload (ESP)) — Шифрование данных.

  • RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) — Область применения протокола управления ключами.

  • RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP)) — Управление ключами и аутентификаторами защищенных соединений.

  • RFC 2409 (The Internet Key Exchange (IKE)) — Обмен ключами.

  • RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) — Нулевой алгоритм шифрования и его использование с IPSec.

  • RFC 2411 (IP Security Document Roadmap) — Дальнейшее развитие стандарта.

  • RFC 2412 (The OAKLEY Key Determination Protocol) — Проверка соответствия ключа.

Протоколы IPsec работают на сетевом уровне (уровень 3 модели OSI). Это делает IPsec более универсальным и гибким, так как он может использоваться для защиты любых протоколов, базирующихся на TCP, UDP, ICMP. IPsec обеспечивает безопасность для двух конечных IP-узлов, между двумя шлюзами безопасности или между IP-узлом и шлюзом безопасности. Протокол является "надстройкой" над IP-протоколом. IPsec может обеспечивать целостность и/или конфиденциальность данных передаваемых по сети.

Архитектура семейства протоколов IPsec включает в себя множество компонентов. Цель данного семейства протоколов состоит в том, чтобы обеспечить различные сервисы безопасности на уровне IP в окружении как IPv4, так и IPv66:


  • Authentication Header (АН) – обеспечивает целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и дополнительную функцию по предотвращению повторной передачи пакетов.

  • Encapsulating Security Payload (ESP) – обеспечивает конфиденциальность (шифрование) передаваемой информации. Кроме этого, он может обеспечить целостность виртуального соединения (передаваемых данных), аутентификацию источника информации и дополнительную функцию по предотвращению повторной передачи пакетов (Всякий раз, когда применяется ESP, в обязательном порядке должен использоваться тот или иной набор данных услуг по обеспечению безопасности).

  • Security Association (SA) – обеспечивают связку алгоритмов и данных, которые предоставляют параметры, необходимые для работы AH и/или ESP. Internet Security Association and Key Management Protocol (ISAKMP) обеспечивает основу для аутентификации и обмена ключами, проверки подлинности ключей.

  • Internet Key Exchange (IKE) – управление ключом, ручное и автоматическое.

  • Алгоритмы, используемые для аутентификации и шифрования.

Концепция «безопасных ассоциаций» (SA, "Security Association") является фундаментальным понятием в архитектуре IPSec. SA представляет собой симплексное (однонаправленное) соединение, которое формируется для транспортирования по нему соответствующего трафика. При реализации услуг безопасности формируется SA на основе использования протоколов AH или ESP (либо их комбинации). SA определена в соответствии с концепцией соединения «точка-точка» (point-to-point) и может функционировать в двух режимах: транспортный режим и режим туннелирования. Транспортный режим реализуется при SA между двумя конечными IP-узлами. Другим режимом SA является режим туннелирования. Если хотя бы одним из концов соединения является шлюз безопасности, то SA обязательно должна выполняться в туннелирующем режиме. SA между двумя шлюзами безопасности всегда находится в туннелирующем режиме, так же, как и SA между конечным узлом и шлюзом безопасности. Два конечных IP-узла могут при желании так же установить туннелирующий режим.

Все SA хранятся в базе данных SADB (Security Associations Database) IPsec-модуля. Каждая SA имеет уникальный маркер, состоящий из трех элементов:


  • индекса параметра безопасности (SPI)

  • IP-адреса назначения

  • идентификатора протокола безопасности (ESP или AH)

IPsec-модуль по этим трём параметрам отыскивает в SADB запись о конкретной SA. В список компонентов SA входят:




  • Последовательный номер – 32-битовое значение, которое используется для формирования поля Sequence Number в заголовках АН и ESP.

  • Переполнение счетчика порядкового номера – флаг, который сигнализирует о переполнении счетчика последовательного номера.

  • Окно для подавления атак воспроизведения – используется для определения повторной передачи пакетов. Если значение в поле Sequence Number не попадает в заданный диапазон, то пакет уничтожается.

  • Информация AH – используемый алгоритм аутентификации, необходимые ключи, время жизни ключей и другие параметры.

  • Информация ESP – алгоритмы шифрования и аутентификации, необходимые ключи, параметры инициализации (например, IV), время жизни ключей и другие параметры.

  • Режим работы IPsec – туннельный или транспортный.

  • MTU – максимальный размер пакета, который можно передать по виртуальному каналу без фрагментации.

Так как «безопасные ассоциации» (SA) являются симплексными (однонаправленными), то для организации дуплексного (двунаправленного) канала, как минимум, нужны две SA. Помимо этого, каждый протокол (ESP/AH) должен иметь свою собственную SA для каждого направления, то есть, связка AH+ESP требует наличия четырех SA. Все эти данные располагаются в SADB.

В SADB содержатся:


  • AH: алгоритм аутентификации.

  • AH: секретный ключ для аутентификации

  • ESP: алгоритм шифрования.

  • ESP: секретный ключ шифрования.

  • ESP: использование аутентификации (да/нет).

  • Параметры для обмена ключами.

  • Ограничения маршрутизации.

  • IP политика фильтрации.

Помимо базы данных SADB, реализации IPsec поддерживают базу данных SPD (Security Policy Database – «база данных политик безопасности»). Запись в SPD состоит из набора значений полей IP-заголовка и полей заголовка протокола верхнего уровня. Эти поля называются селекторами. Селекторы используются для фильтрации исходящих пакетов, с целью поставить каждый пакет в соответствие с определённой SA. Когда формируется пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся в SPD и находятся соответствующие SA. Затем определяется SA (в случае, если она имеется) для пакета и сопряженный с ней индекс параметров безопасности (SPI). После чего выполняются операции IPSec (операции протокола AH или ESP).

Примеры селекторов, которые содержатся в SPD:


  • IP-адрес места назначения

  • IP-адрес отправителя

  • Протокол IPSec (AH, ESP или AH+ESP)

  • Порты отправителя и получателя

Дальше в тексте будет приведено описание протоколов AH и ESP, работающих в транспортной и туннельной моде.




Рис.60 Стандартная IPv4 дейтаграмма
Поле proto указывает на тип IP-протокола. Значение этого поля определяет и стандартизирует IANA. Некоторые коды IP-протоколов приведены в таблице ниже:


Код протокола

Описание

1

ICMP — Internet Control Message Protocol

2

IGMP — Internet Group Management Protocol

4

IP в IP (вариант инкапсуляции)

6

TCP — Transmission Control Protocol

17

UDP — User Datagram Protocol

41

IPv6

47

GRE — Generic Router Encapsulation (используется протоколом PPTP)

50

IPsec: ESP — Encapsulating Security Payload

51

IPsec: AH — Authentication Header



Протокол AH


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


Рис.61 Заголовок IPSec AH



  • next hdr (8 bits) – тип заголовка протокола, идущего после заголовка AH. По этому полю приемный IP-sec модуль узнает о защищаемом протоколе верхнего уровня. Значения этого поля для разных протоколов можно посмотреть в RFC1700.

  • AH len (Payload Len) (8 bits) – это поле определяет общий размер АН-заголовка в 32-битовых словах, минус 2. Несмотря на это, при использовании IPv6 длина заголовка должна быть кратна 8 байтам.

  • Reserved (16 bits) – зарезервировано. Заполняется нулями.

  • SPI (Security Parameters Index) (32 bits) – индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяется безопасной ассоциацией (SA) для данного пакета. Диапазон значений SPI 1...255 зарезервирован IANA.

  • Sequence Number (32 bits) – в последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может отказаться от услуги по защите от повторной передачи пакетов, оно является обязательным и всегда присутствует в AH-заголовке. Передающий IPsec-модуль всегда использует это поле, но получатель может его не обрабатывать.

  • Authentication Data (ICV, Integrity Check Value) – контрольная сумма, вычисляемая для всего фрейма, включая большую часть его заголовка. Получатель вычисляет эту же сумму (хеш) и, в случае несовпадения, отбрасывает пакет, считая его повреждённым (нарушение целостности), или не имеющим надлежащий секретный ключ.

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



Рис.62 IPSec в транспортной моде AH. Жёлтым цветом выделены защищаемые с помощью AH данные.
В транспортной моде AH IP-дейтаграмма незначительно модифицируется, чтобы включить новый заголовок AH между IP заголовком и данными протокола (TCP, UDP), перестановкой кода протокола связывая различные заголовки вместе.

После доставки пакета до места назначения и прохождения валидации, заголовок AH удаляется и поле proto=AH в IP-заголовке заменяется сохранённым значением оригинального содержимого поля "Next Protocol" (TCP, UDP). Эта процедура возвращает IP-дейтаграмму в исходное состояние, и она может быть передана для обработки ожидающему процессу.

Туннельная мода организует более знакомую по VPN функциональность, когда IP-пакет полностью инкапсулируется вовнутрь другого IP-пакета и в таком виде доставляется до места назначения.

Подобно транспортной моде, пакет защищается с помощью поля Integrity Check Value, который служит для аутентификации отправителя и для предотвращения модификаций содержимого пре пересылке. Но, в противоположность транспортной моде, в туннельном режиме инкапсулируется полный IP заголовок исходной дейтаграммы, а также её полезная нагрузка (данные). Это позволяет исходному адресу и адресу назначения не совпадать с адресами охватывающего пакета, собственно, так и формируется туннель.




Рис.63 IPSec в туннельной моде AH.
Когда пакет в туннельной моде достигает места назначения, он проходит проверку на аутентификацию, как любой AH-пакет, после успешного прохождения которой удаляется «внешний» IP-заголовок и заголовок AH. Полностью восстановленная исходная дейтаграмма далее обрабатывается обычным образом.

Большинство реализаций рассматривают конечную точку туннельной моды как виртуальный сетевой интерфейс — как ещё один Ethernet-интерфейс или localhost, соответственно приём и отправка трафика через этот интерфейс трактуется с точки зрения обычных процедур маршрутизации.

Восстановленный пакет может быть доставлен на локальную машину или отмаршрутизирован далее (в соответствии с IP-адресом назначения инкапсулированного пакета), но в любом случае в этот момент он уже не будет защищён технологией IPSec, т.к. представляет собой после восстановления обычную IP-дейтаграмму.

Транспортная мода используется исключительно для защиты соединия точка-точка между двумя узлами, тогда как туннельная мода чаще всего используется между шлюзами (маршрутизаторами, межсетевыми экранами, автномными VPN устройствами) для организации Virtual Private Network (VPN).

Может показаться немного странным, но явного поля «Мода» в IPSec не существует: транспортную моду от туннельной отличает значение поля next header в заголовке AH.

Если в значение next-header указан IP, это значит, что этот пакет инкапсулирует IP-дейтаграмму целиком (включая исходные адреса источника и назначения, что позволяет независимо маршрутизировать декапсулированную дейтаграмму). Это признак туннельной моды.

Любое другое значение (например, TCP, UDP, ICMP) указывает на транспортную моду, защищающую соединение точка-точка.

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



Рис.64 Определение транспортной или туннельной моды
AH вставляет значение Integrity Check Value в часть Authentication Data заголовка, обычно (но не всегда) это значение строится на базе стандартных криптографических алгоритмов, таких как MD5 или SHA-1.

Вместо использования простых контрольных сумм, которые не обеспечивают реальной защиты от преднамеренной фальсификации, AH использует Hashed Message Authentication Code (HMAC), который включает в себя некоторое секретное значение при создании ICV. Хотя злоумышленник может легко заново вычислить хеш по известному алгоритму, но без знания секретного ключа он не сможет создать правильный ICV.

HMAC описан в RFC2104, на рисунке ниже показаны процедуры, используемые при вычислении Integrity Check Value:


Рис.65 Вычисление HMAC для аутентификации AH
IPSec/AH не определяет конкретную функцию аутентификации, вместо этого она предоставляет программный каркас (framework), позволяющий использовать практически любой алгоритм, понятный обоим сторонам обмена. Возможно использовать другие аутентификационные процедуры, такие как цифровые подписи или иные криптоалгоритмы.

С протоколом AH существует довольно серьёзная проблема: он несовместим с технологией сетевой трансляции NAT. Причина в том, что NAT модифицирует поля IP-заголовка, которые защищены AH (Integrity Check Value). Т.к. ICV включает секретное значение (ключ), которое неизвестно промежуточным узлам, NAT-маршрутизатор не сможет вычислить корректный ICV.



Рис.66 Несовместимость AH и NAT
Та же проблема существует и с PAT (Port Address Translation), которая отображает множество приватных IP-адресов в один внешний. Здесь подвергаются модфикации «на-лету» не только IP-адреса, но номера UDP и TCP.

Исходя из вышеизложенного, AH в любой моде – туннельной или транспортной – несовместим с NAT, и может использоваться только в случае, если адреса источника и получателя не модифицируются «по пути».

Эти проблемы неприменимы к режиму ESP, т.к. его аутентификация и шифрование не включает исходные IP-заголовки, модифицируемые NAT-ом. Тем не менее, NAT добавляет некоторые проблемы и при работе IPSec в режиме ESP. В реальности для того, чтобы ESP-пакеты могли транслироваться через NAT, потребовалась ввести в NAT специальную поддержку, т.н. NAT traversal (NAT-T7).

Протокол ESP


Протокол ESP обеспечивает конфиденциальность трафика. Сила сервиса конфиденциальности зависит от используемого алгоритма шифрования. ESP также может дополнительно обеспечивать аутентификацию. Область аутентификации, обеспечиваемая ESP, является более узкой по сравнению с AH, т.е. IP-заголовок (заголовки), «внешние» по отношению к ESP заголовку, не защищены. Если аутентификация нужна только протоколам более высокого уровня, то аутентификация ESP является подходящей альтернативой, причем более эффективной, чем использование AH, инкапсулирующего ESP. Если для ESP SA используется аутентификация, получатель также может выбрать усиление использованием анти-replay сервиса с теми же самыми возможностями, что и AH анти-replay сервис. Хотя и конфиденциальность, и аутентификация являются необязательными, оба сервиса не могут быть опущены одновременно, по крайней мере, один из них должен присутствовать.

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

RFC, описывающие IPSec, не указывают в качестве обязательных какие-то определённые алгоритмы шифрования. Обычно в этом качестве используются DES, 3DES, AES и Blowfish. Конкретные алгоритмы и использование ключей задаются в SA.

В противоположность AH, который всего лишь добавляет небольшой заголовок перед полезной нагрузкой, ESP окружает защищаемую полезную нагрузку дополнительными полями. Security Parameters Index (SPI) и Sequence Number служат для тех же целей, что и в AH, но, кроме них присутствуют также заполнение (padding), next header и опциональное поле Authentication Data в конце пакета, в ESP трейлере.

Возможно использование ESP без реального шифрования (алгоритм NULL), с которым, тем не менее, пакет будет иметь абсолютно такую же структуру. Такой вариант не обеспечивает конфиденциальности, и имеет смысл только в сочетании с опциональной аутентификацией ESP. Бессмысленно использовать ESP без шифрования или аутентификации, если только речь не идёт о тестировании протокола.

Заполнение используется для поддержки блочных алгоритмов шифрования, длина заполнения указывается в поле pad len. Поле next hdr указывает на тип протокола (IP, TCP, UDP) в полезной нагрузке.





Рис.67 ESP без аутентификации
В дополнение к шифрованию, ESP может дополнительно обеспечить аутентификацию, использую такой же HMAC, как в AH. В противоположность AH, в ESP аутентификация защищает только заголовок ESP и зашифрованную полезную нагрузку, и не покрывает весь IP-пакет. Это не существенно ослабляет безопасность аутентификации, но даёт ряд важных преимуществ.


Рис.68 ESP с аутентификацией
Когда стороннее лицо инспектирует IP-пакет, содержащий данные ESP, для него практически невозможно будет сделать какие-либо реальные предположения о содержимом, включая содержимое IP заголовка (особенно адресов источника и получателя).

Даже наличие или отсутствие Authentication Data не может быть определено при взгляде на отдельный пакет (это определение производится с помощью Security Parameters Index, указывающего на предварительный набор параметров и алгоритмов для этого соединения).

Транспортная мода ESP, как и для AH, защищает соединение «точка-точка». Исходный IP-заголовок остаётся нетронутым (за исключением заменённого поля Protocol), что означает, что IP-адреса источника и получателя не изменяются.


Рис.69 IPSec в транспортной моде ESP
ESP в туннельной моде, исходная IP-дейтаграмма полностью инкапсулируется:

Рис.70 IPSec в туннельной моде ESP
Реализация шифрованного соединения в туннельной моде очень близка к традиционным VPN, но для построения полноценной VPN требуется взаимная аутентификация. Подробности будут даны в разделе VPN.

В противоположность протоколу AH, где внешний наблюдатель может легко отличить трафик в туннельной моде от трафика в транспортной моде, эта информация в ESP недоступна: факт, что используется туннельная мода (поле next=IP), скрывается шифрованием полей полезной нагрузки.


Протокол IKE


IKE (Internet Key Exchange) — стандартный протокол семейства IPsec, используемый для обеспечения безопасности взаимодействия в виртуальных частных сетях. Предназначение IKE — защищенное согласование и доставка идентифицированного материала для ассоциации безопасности (SA).

IPSec для установления соединения требует безопасного обмена ключами участников обмена. Один из очевидных и простых путей – ручное конфигурирование, при котором сгенерированный одним участником набор ключей каким-то образом распространяется всем партнёрам, которые затем устанавливают эти ключи в свои соответствующие Security Associations в SPD.

Недостатки такой процедуры (pre-shared key) очевидны: плохое масштабирование, невозможность обеспечить безопасное распространение ключей.

IKE — Internet Key Exchange — был разработан для устранения недостатков технологии pre-shared key8. IKE использует протокол ISAKMP (Internet Security Association Key Management Protocol) как каркас, для поддержки установления SA с обоими участниками обмена.

Поддерживается множество протоколов обмена ключами, протокол Oakley один из самых широко используемых для этих целей. Для обмена ключами IPSec обычно используется 500/UDP и/или UDP/4500.

ISAKMP определяет концепцию управления и обмена ключами, управления и установления SA. ISAKMP определяет процедуры аутентификации участников, создания и управления SA, определяет технику генерации ключей и обеспечения защиты от угроз.

Работа ISAKMP разбивается на две отдельные фазы. Во время первой фазы для защиты дальнейших коммуникаций между участниками устанавливаются ISAKMP SA. Во второй фазе устанавливаются SA для IPSec. Одна ISAKMP SA может использоваться для нескольких SA других протоколов.

Протокол Oakley описывает серии обмена ключами, называемые режимами (modes), и детализирует сервисы, предоставляемые каждым режимом (такие как perfect forward secrecy для ключей, защита подлинности, аутентификации). В основе работы протокола лежит алгоритм обмена ключами Diffie-Hellman.

IKE не реализует протокол Oakley. IKE использует только подмножество функций необходимых для достижения своих целей, но оно не является полным соответствием спецификации Oakley. В этом смысле у IKE нет зависимости от Oakley. Некоторые возможности Oakley, использованные в IPSec:


  • Использует специальный механизм cookies для предотвращения т.н. атак «засорения» (clogging).

  • Позволяет участникам согласовать группы (глобальные параметры DH).

  • Использует nonce для предотвращения replay-атак.

  • Аутентифицирует обмен DH, чтобы избежать атак «человек посередине».

Для защиты от атак «засорения» используется механизм обмена cookies. Это запрос, в котором каждая из сторон посылает псевдослучайное число (cookie) в начальном сообщении, которое другая сторона подтверждает. Если источник поддельный, то атакующий сможет только вынудить принимающую сторону генерировать подтверждения, но не выполнять полноценные ресурсоёмкие вычисления для DH.




Рис.71 Атака «засорения»
Фазы в IKE такие же, как фазы в ISAKMP. Во время первой фазы создаются IKE SA для защиты второй фазы, а во время второй фазы создаются SA для IPsec. Участники могут меняться ролями между фазами. Инициатор первой фазы может быть ответчиком во время второй фазы.



Рис.72 Фазы IKE
Для первой фазы возможны 2 режима: основной и агрессивный. В основном режиме происходят 3 обмена: в первом узлы договариваются о правилах, во втором обмениваются открытыми значениями Диффи-Хеллмана и вспомогательными данными, в третьем происходит подтверждение обмена Диффи-Хеллмана.


Рис.73 Основная мода
В агрессивном режиме в первом обмене устанавливаются правила, передаются открытые значения Диффи-Хеллмана и вспомогательная информация. Причем во втором сообщении первого обмена происходит идентификация отвечающей стороны (responder). Третье сообщение идентифицирует инициатора и подтверждает участие в обмене. Последнее (четвертое) сообщение может быть не послано.


Рис.74 Агрессивная мода
Для обоих этих методов возможны четыре типа различных методов идентификации: цифровая подпись, два типа шифрования открытым ключом и разделяемый ключ (pre-shared key).

Во второй фазе быстрый режим не является полным обменом (так как он неразрывно связан с обменами в 1-ой фазе), хотя и используется как часть процесса согласования SA, доставляя материалы ключей и согласуя правила для SA, не являющихся ISAKMP SA. Все сообщения должны быть защищены ISAKMP SA. Это значит, что все части сообщений, за исключением заголовка ISAKMP, шифруются.




Рис.75 Быстрый режим
Режим новой группы не должен быть использован до установления SA ISAKMP. Описание новой группы должно следовать только после согласования в фазе 1 (хотя сам режим новой группы не относится к фазе 2).



Рис.76 Режим новой группы
В группах OAKLEY происходит согласование Диффи-Хеллмана. В RFC2409 определены 4 группы. Впервые эти группы были описаны в протоколе OAKLEY, поэтому они получили такое название.




Достарыңызбен бөлісу:
1   ...   21   22   23   24   25   26   27   28   ...   44


©kzref.org 2019
әкімшілігінің қараңыз

    Басты бет