ПРОТОКОЛИ ISAKMP І IKE

Протокол ISAKMP (Internet Security Association Key Management Protocol - протокол управління ключами і контекстами безпеки в Internet) був розроблений IETF для вирішення завдань узгодження параметрів і управління ключами при формуванні захищеного каналу. ISAKMP описує загальну схему взаємодії, але не містить конкретних криптоалгоритмів розподілу ключів. Тому він використовується спільно з протоколом OAKLEY, заснованому на алгоритмі Діффі-Хеллмана [13]. Протокол IKE (англ. «Internet Key Exchange» - обмін ключами в Internet) визначає спільне використання протоколів ISAKMP з OAKLEY і SKEMI (англ. «Secure Key Exchange Mechanism for Internet» - безпечний механізм обміну ключами в Інтернет) для вирішення даного завдання. Порівнюючи протоколи SKIP і IKE, треба відзначити, що останній більш складний в реалізації, але вважається більш надійним і гнучким.

Протокол ISAKMP визначає дві фази узгодження параметрів взаємодії:

ПО

  • - узгодження глобальних параметрів захищеного каналу (в термінах IPSec такі параметри називаються керуючим контекстом);
  • - узгодження параметрів кожного захищеного з'єднання (вони утворюють контекст захисту - SA).

З точки зору моделі стека TCP / IP, протокол ISAKMP є протоколом прикладного рівня. У разі його використання спільно з IPSec специфікація встановлює використання в якості протоколу нижнього рівня UDP з номером порту 500.

Протокол ISAKMP визначає наступну послідовність дій по формуванню керуючого контексту (сторони взаємодії, наприклад, це можуть бути два шлюзу безпеки, називаються «Ініціатор» і «Партнер») -.

  • 1) «Ініціатор» -> «Партнер»: заявка на контекст, що включає пропоновані алгоритми і їх параметри;
  • 2) «Партнер» «Ініціатор»: прийняті алгоритми і параметри (зі списку, отриманого на кроці 1; для кожної функції захисту - генерація і розподіл ключів, шифрування, аутентифікація - використовується один алгоритм і його параметри);
  • 3) «Ініціатор» -> «Партнер»: ключовий матеріал і одноразовий номер ініціатора;
  • 4) «Партнер» -> «Ініціатор»: ключовий матеріал і одноразовий номер партнера;
  • 5) «Ініціатор» -> «Партнер»: підписана ініціатором зашифроване повідомлення, що містить його ідентифікатор;
  • 6) «Партнер» -> «Ініціатор»: підписана партнером зашифроване повідомлення, що містить його ідентифікатор.

Якщо використовується протокол OAKLEY, на кроці 3 і 4 сторони надсилають один одному свої відкриті ключі разом з випадковими числами, службовцями для захисту від повтору. Для забезпечення контролю справжності відкритих ключів можуть бути використані сертифікати Х.509. У відповідності зі схемою Діффі-Хеллмана розраховується загальний секретний ключ. На його основі виробляються значення:

SKEYlD_d - ключовий матеріал, який використовується для генерації тимчасових ключів для захищених з'єднань;

SKEYlD_a - сеансові ключі, які використовуються для аутентифікації сторін і узгоджується параметрів;

SKEYID_e - сеансові ключі, які використовуються для шифрування узгоджувати параметрів.

П'ятий і шостий кроки служать для обміну ідентифікаційної інформацією, захищеною і завіреної на ключах SKEYID_e і SKEYID_a.

Такий порядок взаємодії реалізується при використанні основного або базового режиму (англ. «Main Mode»). Він більш повільний, але і більш безпечний. Існує також «агресивний» режим (англ. «Aggressive Mode») при якому для збільшення швидкості взаємодії ряд параметрів передається у відкритому вигляді, і зменшено число кроків взаємодії (з 6 до 3 за рахунок того, що на першому і другому кроці відразу передається більше параметрів) (111.

Повідомлення ISAKMP складається з заголовка і наступних за ним полів даних. Формат заголовка наведено на рис. 3.10.

Тема ISAKMP

Мал. 3.10. Тема ISAKMP

Виходячи із значення поточного часу, сторони формують ідентифікатори (cookie), які включають в заголовок пакета (на кроці 1 присутня тільки ідентифікатор боку-ініціатора з'єднання, на наступних - ідентифікатори обох сторін). Присутність цих ідентифікаторів дозволяє захиститися від атак шляхом повторних посилок перехоплених повідомлень.

Поле «Наступні дані» містить ідентифікатор, який вказує на тип вмісту області даних. Наприклад, 1 - контекст захисту (SA), 2 - пропозиція (використовується при узгодженні параметрів); 6 - сертифікат, 7 - запит сертифіката і т. Д.

Тип обміну вказує на тип інформаційного обміну (режим, в якому працює протокол). Наприклад, 0 - немає обміну, 1 - базовий, 4 - агресивний і т. Д.

Прапори дозволяють вказати додаткові настройки. Наприклад, один з прапорів вказує на те, що всі дані, що йдуть за заголовком, зашифровані.

Ідентифікатор повідомлення - унікальний ідентифікатор повідомлення.

Довжина - довжина повідомлення (заголовка і даних).

Отже, описана фаза протоколу дозволяє сформувати загальний захищений канал і узгодити його параметри.

Після створення загального захищеного каналу параметри кожного захищеного з'єднання, створюваного в рамках цього каналу, узгоджуються на основі сформованих глобальних параметрів каналу і утворюють контекст захисту. Кожне захищене з'єднання є односпрямованим, і в ньому може використовуватися один з двох протоколів - ESP або АН (крім того, на базі загального захищеного каналу можуть бути створені захищені з'єднання, що використовують відмінний від IPSec протокол). Якщо передбачається організувати захищається ESP двостороння взаємодія, знадобляться два з'єднання (і два SA), якщо використовувати і протокол АН, і ESP, то потрібні чотири SA.

До складу узгоджуваних параметрів, що утворюють SA, входять [13J:

  • - номер протоколу криптозахисту (АН, ESP, інший);
  • - номера алгоритмів криптографічного захисту й їх параметри;
  • - режим протоколу (транспортний або тунельний);
  • - сеансові ключі (діючі для поточного з'єднання);
  • - термін існування захищеного з'єднання (може здаватися часом або об'ємом переданого графіка; наприклад, термін існування каналу - 6 годин, з'єднання в рамках цього каналу - 1 година);
  • - максимальний розмір пакетів;
  • - додаткові параметри (параметри лічильника і т. Д.) Для захисту від повтору, затримки, видалення пакетів повідомлення.

Користувачами захищених з'єднань, як правило, є прикладні процеси. І між двома вузлами мережі може існувати довільне число з'єднань, сформованих в рамках одного захищеного каналу.

Захищене з'єднання, яке відповідає специфікаціям протоколу IPSec, ідентифікується цільовим IP-адресою, використовуваним протоколом криптозахисту (ESP або АН) і індексом SPI.

Для вироблення параметрів «Ініціатор» і « Партнер » обмінюються наступними повідомленнями.

  • 1) «Ініціатор» -> «Партнер» (захищене повідомлення):
    • - заявка на створення захищеного з'єднання (пропоновані алгоритми і їх параметри);
    • - одноразовий номер ініціатора.
  • 2) « Партнер » « Ініціатор » (захищене повідомлення):
    • - прийняті алгоритми і параметри;
    • - одноразовий номер партнера.
  • 3) « Ініціатор » -> «Партнер» (захищене повідомлення):
    • - одноразовий номер ініціатора;
    • - одноразовий номер партнера.

Для захисту переданих повідомлень використовуються ключі, вироблені при формуванні захищеного каналу: SKEYID_a - для аутентифікації, SKEYID_e - для шифрування. Для аутентифікації використовується хеш-функція, як аргументи якої виступають аутентіфіціруемое повідомлення і ключ SKEYID_a.

Тимчасові ключі захищеного з'єднання генеруються шляхом застосування хеш-функції до значення SKEYID_d з додатковими параметрами, в число яких входять одноразові ідентифікатори ініціатора і партнера.

Приймаюча сторона з'єднання задасть для формованого SA номер SPI, за яким він буде ідентифікуватися.

 
Переглянути оригінал
< Попер   ЗМІСТ   ОРИГІНАЛ   Наст >