Протоколи тунелювання і основні вимоги до тунелювання

           Оскільки ці протоколи базуються на добре визначеному протоколі PPP, то протоколи Рівня 2 (такі як PPTP і L2TP) успадкували систему корисних характеристик. Ці характеристики та їх відповідники Рівня 3 визначають основні вимоги VPN:

q Автентифікація користувачів. Протоколи тунелювання Рівня 2 успадковують схеми автентифікації користувачів, включно з методом розширюваного протоколу автентифікації (Extensible Authentification Protocol – EAP), який розглянено нижче. Більшість схем тунелювання Рівня 3 приймають, що кінцеві пункти добре відомі та автентифіковані перед встановленням тунелю. Вийнятком із цього є ISAKMP-узгодження в протоколі IPSec, яке передбачає взаємну автентифікацію кінцевих пунктів тунелю. Відзначимо, що більшість впроваджень IPSec підтримує тільки сертифікацію комп ’ютерів замість сертифікації користувачів. Внаслідок цього будь-який користувач, який має доступ до одного із комп’ютерів у кінцевих пунктах, може використовувати тунель. Цей потенційний недолік у забезпеченні захисту можна усунути, якщо IPSec працює разом із протоколом Рівня 2, таким як L2TP.

q Підтимка карт-жетонів (token card). З використанням протоколу EAP протоколи тунелювання Рівня 2 можуть підтримувати різноманітні методи автентифікації, включно з одноразовими паролями, криптографічними калькуляторами та інтелектуальними картками (smart card). Протоколи тунелювання Рівня 3 можуть використовувати подібні методи; наприклад, IPSec визначає автентифікацію сертифікату з публічним ключем у своєму ISAKMP/Oakley-узгодженні.

q Динамічне призначення адрес. Тунелювання на Рівні 2 підтримує динамічне призначення адрес клієнтів, базоване на механізмі узгодження протоколу управління мережею (Network Control Protocol – NCP). Загалом схеми тунелювання Рівня 3 приймають, що що адреси завжди призначені заздалегідь перед ініціюванням тунелю. Схеми призначення адрес в тунельному режимі IPSec ще опрацьовуються і тепер відсутні.

q Компресія даних. Протоколи тунелювання Рівня 2 підтримують схеми компресії, базовані на протоколі PPP. IETF опрацьовує подібні механізми (такі, як IP-компресія) для протоколів тунелювання Рівня 3.

q Шифрування даних. Протоколи тунелювання Рівня 2 підтримують механізми шифрування, базовані на протоколі PPP; подібні схеми використовуються у протоколах тунелювання Рівня 3.

q Управління ключами. Протокол тунелювання Рівня 2 MPPE (Microsoft Point-to-Point Encryption) полягає на початковому генеруванні ключа при автентифікації користувача і наступному періодичному оновленні його. IPSec явно узгоджує поточний ключ протягом ISAKMP-узгодження і також перідично його оновлює.

q Багатопротокольна підтримка. Тунелювання Рівня 2 підтримує багато протоколів для корисного навантаження, що робить його простим для клієнтів тунелювання при доступі до корпоративних мереж, які вживають IP, IPX, NetBEUI і подібні протоколи. Навпаки, протоколи тунелювання Рівня 3 звичайно підтримують тільки ті доцільові мережі, які вживають протокол IP.

Протокол PPP

           Оскільки протоколи Рівня 2 явно залежать від характеристик, початково визначених для PPP, має сенс вивчити цей протокол більш детально. PPP опрацьований для пересилання даних через комутовані або виділені сполучення типу “пункт-пункт”. PPP інкапсулює пакети IP, IPX та NetBEUI в рамки PPP і тоді пересилає PPP-інкапсульовані пакети через сполучення “пункт-пункт”. PPP використовується між клієнтом і сервером мережевого доступу. Існують чотири різні фази узгодження при встановленні PPP-сесії через комутовані лінії. Кожна із цих чотирьох фаз мусить успішно закінчитися, перш ніж PPP-сполучення буде готове до пересилання даних користувача.

q Фаза 1: встановлення PPP-зв ’язку. PPP використовує протокол управління каналом (Link Control Protocol – LCP) для встановлення, обслуговування і припинення фізичного сполучення. Протягом початкової фази LCP вибираються основні комунікаційні опції. Відзначимо, що протягом фази встановлення зв’язку (Фаза1) протоколи автентифікації вибираються, але не використовуються до початку фази автентифікації сполучення (Фаза 2). Подібно, протягом дії LCP вирішується, хто із двох партнерів у сполученні буде узгоджувати параметри компресії і/або шифрування даних, однак остаточний вибір алгоритмів компресії/шифрування та інші подробиці з’ясовуються протягом Фази 4.

q Фаза 2:автентифікація користувача. У другій фазі комп’ютер клієнта подає повноваження користувача до сервера віддаленого доступу. Схема надійної автентифікації передбачає захист проти (replay attack) та імітації віддаленого клієнта (Remote client impersonation). Replay attack з’являється тоді, коли третя сторона моніторує успішне сполучення і використовує захоплений пакет для відтворення відповіді віддаленого клієнта, щоб добитися автентифікованого сполучення. Remote client impersonation з’являється тоді, коли третя сторона перехоплює автентифіковане сполучення. Порушник чекає, доки сполучення буде автентифіковане і тоді виловлює інформаційний обмін, від’єднує автентифікованого користувача і перехоплює управління автентифікованим сполученням.

Більшість впроваджень PPP використовують обмежені методи автентифікації. Звичайно це протокол автентифікації пароля (Password Authentification Protocol – PAP), Challenge Handshake Authentification Protocol – CHAP і Microsoft Challenge Handshake Authentification Protocol – MSCHAP.

· Password Authentification Protocol (PAP). Це проста автентифікаційна схема з відкритим текстом. Сервер мережевого доступу запитує ім’я користувача та його пароль і PAP повертає йому це у вигляді відкритого тексту (без шифрування). Очевидно, що ця схема автентифікації не захищена, бо третя сторона може захопити ім’я користувача та пароль і використати їх для подальшого доступу до сервера мережевого доступу і всіх ресурсів, які забезпечує цей сервер. PAP не передбачає жодного захисту проти replay attack або імітації віддаленого клієнта, після того, як пароль користувача скомпрометований.

· Challenge HandshakeAuthentification Protocol (CHAP). CHAP – це шифрований автентифікаційний механізм, який уникає пересилання чинного пароля через сполучення. Сервер мережевого доступу висилає до клієнта виклик, який містить ідентифікатор сесії та довільний рядок виклику. Віддалений клієнт повинен використати односторонній алгоритм перемішування (hashing) MD5, щоб повернути ім’я користувача і шифруваня виклику, ідентифікатора сесії та пароля клієнта. Ім’я користувача висилається без перемішування.

Рис. 6. Процес CHAP.

CHAP – це вдосконалення PAP, у якому відкритий текст пароля не пересилається через сполучення. Замість цього пароль використовується для створення зашифрованого перемішування (hash) із оригінального виклику (challenge). Сервер знає відкритий текст пароля клієнта, тому може повторити операцію і порівняти результат у паролі, який висилається у відповідь клієнту. CHAP захищає проти атаки (replay attack), використовуючи довільний рядок виклику при кожній спробі автентифікації. CHAP захищає проти фальсифікації віддаленого клієнта шляхом непрогнозованого висилання повторних викликів до віддаленого клієнта протягом періоду тривання сполучення.

· Microsoft Challenge HandshakeAuthentification Protocol (MS-CHAP). MS-CHAP – це шифрований механізм автентифікації, дуже подібний до CHAP. Подібно до CHAP, NAS висилає до клієнта виклик, який складається із ідентифікатора сесії (session ID) і довільного рядка виклику. Віддалений клієнт повинен повернути ім’я користувача, MD4-hash рядка виклику, ідентифікатор сесії і пароль, зашифрований перемішуванням MD4. Така конструкція, яка оперує перемішуванням MD4-hash пароля, забезпечує додатковий рівень безпеки, бо дозволяє серверу зберігати перемішаний пароль замість відкритого тексту пароля. MS-CHAP також забезпечує додатковий код помилки включно з кодом пароля, який втратив чинність, та додаткові шифровані повідомлення клієнт-сервер, які дозволяють користувачу змінювати свій пароль. У Microsoft-впровадженнях MS-CHAP клієнт і NAS незалежно генерують початкові ключі для наступного шифрування даних через MPPE. Останній пункт дуже важливий, бо він пояснює, чому автентифікація MS-CHAP необхідна для створення можливості шифрування даних на основі MPPE.

q Фаза 3:Зворотній виклик PPP (PPP callback c ontrol). Microsoft-впровадження PPP включають опційну фазу зворотнього виклику (Callback Control Phase). Ця фаза використовує протокол управління зворотнім викликом (Callback Control Protocol - CBCP) безпосередньо після фази автентифікації. Клієнт і NAS, якщо вони сконфігуровані для зворотнього виклику, після автентифікації переривають сполучення. Тоді NAS здійснює зворотній виклик віддаленого клієнта через визначений теелефонний номер. Це забезпечує додатковий рівень безпеки для мережевої взаємодії через комутовані телефонні канали. NAS може дозволити сполучення від віддаленого клієнта, який користується тільки визначеним телефонним номером.

q Фаза 4:активування протоколів Мережевого рівня. Як тільки попередні фази завершені, PPP активує різні протоколи управління мережею (Network Control Protocol – NCP), вибрані під час фази встановлення зв’язку (Фаза 1) для конфігурування протоколів, що використовуються віддаленим клієнтом. Наприклад, протягом цієї фази протокол управління IP (IP Control Protocol – IPCP) може призначити динамічну адресу користувачу комутованого телефонного каналу. У Microsoft-впровадженнях PPP використовується протокол управління компресією для узгодження як компресії даних із вживанням  MPPC, так і компресії даних із використанням MPPE, оскільки обидва ці потоколи впроваджені у тій самій процедурі.

q Фаза персилання даних. Коли чотири фази узгодження завершені, PPP розпочинає висилання даних між двома сторонами сполучення. Кожний пакет даних вставляється у заголовок PPP, який потім видаляється у приймальній системі. Якщо компресія даних вибрана протягом Фази 1 та узгоджена під час Фази 4, то дані стискають перед висиланням. Якщо шифрування даних вибране і узгоджене подібним чином, то дані (опційно скомпесовані) можуть бути зашифровані перед пересиланням.