Протокол kerberos

Протокол Kerberos (з англ. Цербер), орієнтований в основному на клієнт-серверну архітектуру, пропонує механізм взаємної аутентифікації двох співрозмовників (хостів) перед встановленням зв'язку між ними в умовах незахищеного каналу. Kerberos - це також пакет вільного програмного забезпечення розробленого в Массачусетському технологічному інституті, що реалізовує цей протокол. Повідомлення протоколу Kerberos захищені проти прослуховування мережі та повторних атак (англ. replayattack).

Kerberos базується на симетричних алгоритмах шифрування та для своєї роботи потребує довірену третю сторону. Деякі модифікації протоколу можуть використовувати елементи всиметричного шифрування.

Історія і розвиток

Протокол Kerberos розроблявся інститутом MIT для забезпечення безпеки сервісів проекту Афіна, метою якого було забезпечення доступності навчальних матеріалів із будь-якої станції. Назва протоколу походить від грецької міфічної триголової потвори Цербера, захисника підземного царства. Існує декілька версій протоколу Включно із третьою були доступні лише для внутрішнього користування у МІТ.

Стів Міллер (англ. SteveMiller) та Кліффорд Ньюман (англ.CliffordNeuman), основні архітектори четвертої версії Kerberos, опублікували її у кінці 1980-х, хоча вона також розроблялась в основному для проекту Афіна. П'ята версія протоколу, розроблена Джоном Колем (англ.JohnKohl) та Кліффордом Ньюманом, з'явилась у 1993 році як рекомендація на стандарт RCF 1510, оновлена 2005 року у RCF 4120.

Ранні версії Kerberos (c 1 по 3) були створені всередині МIT і використовувалися в цілях тестування. Ці реалізації містили істотні обмеження і були корисні тільки для вивчення нових ідей і виявлення проблем, які могли виникнути під час розробки.

Kerberos 4

Kerberos 4 вперше була опубліковано 24 січня 1989 року. Вона стала першою версією, поширюваної за межами MIT, підготовленої для декількох виробників, які включили її в свої операційні системи. Крім того , інші великі проекти з розподіленим системам (наприклад AFS) використовували ідеї Kerberos 4 для своїх систем аутентифікації. Основними розробниками даної версії були Стів Міллер (Steve Miller) і Кліффорд Ньюман (Clifford Neuman) . Основи того, що повинно було стати Kerberos 4, були описані в технічному плані Афіна, а остаточний варіант був закріплений у вихідному коді еталонної реалізації, опублікованій MIT. Однак через обмеження на експорт програмного забезпечення, що використовує шифрування, накладене американським урядом, Kerberos 4 не міг бути поширений за межами Сполучених Штатів. Так як Kerberos 4 використовував DES шифрування, організації за межами США не могли за законом можна використовувати програмне забезпечення. У відповідь на це команда розробників з MIT створила спеціальну версію Kerberos 4, виключивши з неї весь код, який стосується шифрування. Дані заходи дозволили обійти обмеження на експорт. Пізніше Еррол Янг ( Errol Young ) в Університеті зв'язку Австралії ( Bond University of Australia ) додав в цю версію власну реалізацію DES. Вона називалася «E-Bones» (скорочення від Encrypted Bones) і могла вільно поширюватися за межами США. У 2006 році було оголошено про припинення підтримки Kerberos

Kerberos 5

З метою подолання проблем безпеки попередньої версії Джоном Коулом (John Kohl) і Клиффордом Ньюманом (Clifford Neuman) була розроблена 5 версія протоколу, яка в 1993 році була опублікована в RFC 1510. З плином часу, в 2005 специфікацією почала займатися IETF Kerberos work group. Опубліковані ними документи включають в себе:

• Характеристики шифрування і контрольної суми (RFC 3961)

• Просунутий стандарт шифрування Advanced Encryption Standard (AES) (RFC 3962)

• Kerberos 5 «The Kerberos Network Authentication Service ( V5 )» (RFC 4120), уточнює деякі аспекти RFC 1510, і має намір використовуватися для більш докладного і чіткого опису.

• Нове видання GSS - API специфікації «The Kerberos Version 5 Generic Security Service Application Program Interface (GSS - API) Mechanism: Version 2.» (RFC 4121)

У червні 2006 року був представлений RFC 4556 описує розширення для п'ятої версії під назвою PKINIT (Public Key Cryptography for Initial Authentication in Kerberos). Даний RFC описував , як використовувати асиметричне шифрування на етапі аутентифікації клієнта. На наступний рік (2007) MIT сформували Kerberos Консорціум (Kerberos Consortium) щодо сприяння подальшому розвитку.

Використання та поширенняПоширення реалізації Kerberos відбувається в рамках авторського права аналогічного прав для BSD. В даний час безліч ОС підтримують даний протокол, в число яких входять:

• Windows 2000 і більш пізні версії, які використовують Kerberos як метод аутентифікації в домені між учасниками. Деякі доповнення до цього протоколу відображені в RFC 3244 «Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols». Документ RFC 4757 описує використання RC4 Kerberos в Windows

• Різні UNIX і UNIX подібні ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При цьому існує дві найбільш використовувані реалізації з відкритим вихідним кодом - MIT Kerberos і Heimdal, остання з яких була спочатку створена у Швеції через обмежень на експорт криптографічного ПО із США (англ.).

Принцип роботи

Kerberos 4

Kerberos 4 в значній мірі заснований на протоколі Нідхема-Шредера, але з двома істотними змінами:

• Перша зміна протоколу зменшувало кількість повідомлень пересилаються між клієнтом і сервером аутентифікації.

• Друге, більш істотна зміна базового протоколу, полягає у веденні TGT (Ticket Granting Ticket - квиток для отримання квитка) концепції, що дозволяє користувачам аутентифицироваться на кілька сервісів використовуючи свої довірливі дані тільки один раз.

Малюнок №1. Етапи аутентифікації клієнта

Як результат, протокол Kerberos 4 містить два логічних компоненти: Сервер аутентифікації (СА) і сервер видачі квитків (TGS - Ticket Granting Server). Зазвичай ці компоненти поставляються як єдина програма, яка запускається на центрі розподілу ключів (ЦРК - містить базу даних логінів/паролів для користувачів і сервісів використовують Kerberos). Сервер аутентифікації виконує одну функцію: отримує запит, що містить ім'я клієнта, що запитує аутентифікацію, і повертає йому зашифрований TGT. Потім користувач може використовувати цей TGT для запиту подальших квитків на інші сервіси. У більшості реалізацій Kerberos час життя TGT 8-10 годин. Після цього клієнт знову повинен запросити його у СА. Перше повідомлення, що відправляється центру розподілу ключів - запит до СА, так само відомий як AS_REQ. Це повідомлення відправляється відкритим текстом і містить ідентифікаційні дані клієнта, мітку часу клієнта і ідентифікатор сервера надає квиток (TGS). Коли ЦРК отримує AS_REQ повідомлення, він перевіряє, що клієнт, від якого прийшов запит, існує, і його мітка часу близька до локального часу ЦРК (зазвичай ± 5 хвилин). Дана перевірка проводиться не для захисту від повторів (повідомлення посилається відкритим текстом), а для перевірки відповідності часу. Якщо хоча б одна з перевірок не проходить, то клієнтові відправляється повідомлення про помилку, і він не автентифіковані. У випадку вдалої перевірки СА генерує випадковий сеансовий ключ, який буде спільно використовуватися клієнтом і TGS (даний ключ захищає подальші запити квитків у TGS на інші сервіси). ЦРК створює 2 копії сесійного ключа: одну для клієнта і одну для TGS. Потім ЦРК відповідає клієнту повідомленням сервера аутентифікації (AS_REP) зашифрованим довгостроковим ключем клієнта. Яке включає TGT зашифрований TGS ключем (TGT містить: копію сесійного ключа для TGS, ідентифікатор клієнта, час життя квитка, мітку часу ЦРК, IP адреса клієнта), копію сесійного ключа для клієнта, час життя квитка та ідентифікатор TGS.

Малюнок №2. Етап авторизації клієнта на TGS

Коли користувач захоче отримати доступ до сервісу, він підготує повідомлення для TGS (TGS_REQ) містить 3 частини: ідентифікатор сервісу, копію TGT отриману раніше і аутентифікатор (Аутентифікатор складається з мітки часу зашифрованою сесійним ключем отриманим від СА і служить для захисту від повторів). При отриманні запиту квитка від клієнт, ЦРК формує новий сесійний ключ для взаємодії клієнт/сервіс. Потім відправляє відповідь повідомлення (TGS_REP) зашифроване сесійним ключем отриманим від СА. Це повідомлення містить новий сеансовий ключ, квиток сервісу (Service ticket містить: копію нового сесійного ключа, ідентифікатор клієнта, час життя квитка, локальний час ЦРК, IP клієнта) зашифрований довготривалим ключем сервісу, ідентифікатор сервісу і час життя квитка. Деталі останнього кроку - відправки квитка служби сервера додатків не стандартизувалися Kerberos 4, тому його реалізація повністю залежить від програми.

Kerberos 5

Kerberos 5 є розвитком четвертої версії, включає всю попередню функціональність і містить безліч розширень. Однак, з точки зору реалізації, Kerberos 5 є абсолютно новим протоколом. Основною причиною появи п'ятої версії була неможливість розширення. З часом, атака повним перебором на DES використовуваному в Kerberos 4 стала актуальна, але використовувані поля в повідомленнях мали фіксований розмір і використовувати більш стійкий алгоритм шифрування не представлялося можливим. Для вирішення даної проблеми було вирішено створити розширюваний протокол з можливістю використання на різних платформах на основі технології ASN.1. Це дозволило використовувати в транзакціях різні типи шифрування. Завдяки цьому була реалізована сумісність з попередньою версією. Крім того у ЦРК з'являється можливість вибирати найбільш безпечний протокол шифрування підтримуваний беруть участь сторонами. Крім того оригінальний протокол Kerberos 4 схильний перебору за словником. Дана уразливість пов'язана з тим, що ЦРК видає на вимогу зашифрований TGT будь-якому клієнту. Важливість даної проблеми так само підкреслює те, що користувачі зазвичай вибирають прості паролі. Щоб ускладнити проведення даної атаки, в Kerberos 5 було введено попереднє встановлення автентичності. На даному етапі ЦРК вимагає, щоб користувач засвідчив свою особистість перш , ніж йому буде виданий квиток. За попередню аутентифікацію відповідає політика ЦРК, якщо вона потрібна, то користувач при першому запиті до СА отримає повідомлення KRB_ERROR. Це повідомлення скаже клієнтові, що необхідно відправляти AS_REQ запит зі своїми даними для встановлення автентичності. Якщо ЦРК не опізнані їх, то користувач отримає інше повідомлення KRB_ERROR, що повідомляє про помилку і TGT не буде видано.

Схема роботи Kerberos 5 в даний час відбувається наступним чином: Вхід користувача в систему:

1. Користувач вводить ім'я та пароль на клієнтській машині.

2. Клієнтська машина виконує над паролем односторонню функцію (зазвичай хеш), і результат стає секретним ключем клієнта/користувача.

Малюнок №3.Схема роботи Kerberos 5

Аутентифікація клієнта:

1. Клієнт відсилає запит (AS_REQ) на СА для отримання аутентифікаційних вірчих даних і подальшого їх надання TGS серверу (згодом він буде їх використовувати для отримання квитків без додаткових запитів на застосування секретного ключа користувача.) Даний запит містить:

• Ідентифікатор клієнта, його мітка часу та ідентифікатор сервера.

2. Якщо політика ЦРК вимагає попередньої аутентифікації, то користувач отримує повідомлення KRB_ERROR, у відповідь на яке посилає повторний запит, але з уже даними для встановлення автентичності.

3. СА перевіряє, чи є такий клієнт в базі. Якщо є, то назад СА відправляє повідомлення (AS_REP) включає:

• Сесійна ключ клієнт/TGS, ідентифікатор TGS і час життя квитка зашифровані секретним ключем клієнта.

• TGT (який включає ідентифікатор і мережевий адресу клієнта, мітку часу ЦРК, період дії квитка та сесійний ключ Клієнт/TGS), зашифрований секретним ключем TGS.

1. Якщо ж ні, то клієнт отримує нове повідомлення, яке говорить про помилку, що відбулася.

2. Отримавши повідомлення, клієнт розшифровує свою частину для отримання Сесійної Ключа Клієнт/TGS. Цей сесійний ключ використовується для подальшого обміну з сервером TGS. (Важливо: Клієнт не може розшифрувати TGT, так як воно зашифровано секретним ключем TGS).У цей момент у користувача достатньо даних, щоб авторизуватися на TGS.

Авторизація клієнта на TGS

1. Для запиту сервісу клієнт формує запит на TGS (TGS_REQ) містить такі дані:

• TGT, отриманий раніше і ідентифікатор сервісу.

• Аутентифікатор (складений з ID клієнта і тимчасового штампа) , зашифрований на Сесійній Ключі Клієнт/TGS .

2. Після отримання TGS_REQ, TGS витягує з нього TGT і розшифровує його використовуючи секретний ключ TGS. Це дає йому Сесійна Ключ Клієнт/TGS. Їм він розшифровує аутентифікатор. Потім він генерує сесійний ключ клієнт/сервіс і посилає відповідь (TGS_REP) включає:

• Квиток сервісу (який містить ID клієнта, мережевий адресу клієнта, мітку часу ЦРК, час дії квитка та Сесійна Ключ клієнт/сервіс) зашифрований секретним ключем сервісу.

• Сесійна ключ клієнт/сервіс, ідентифікатор сервісу і час життя квитка, зашифровані на Сесійній Ключі Client/TGS.

Запит сервіса з клієнтом

1. Після отримання TGS_REP, у клієнта достатньо інформації для авторизації на сервісі. Клієнт з'єднується з ним і посилає повідомлення містить:

• Зашифрований квиток сервісу отриманий раніше.

• Новий аутентифікатор, зашифрований на сесійному ключі клієнт/сервіс, і включає ID клієнта і мітку часу.

2. Сервіс розшифровує квиток використовуючи свій секретний ключ і отримує сесійний ключ клієнт/сервіс. Використовуючи новий ключ, він розшифровує аутентифікатор і посилає клієнту таке повідомлення для підтвердження готовності обслужити клієнта і показати, що сервер дійсно є тим, за кого себе видає:

• Мітку часу, зазначену клієнтом + 1, зашифровану на сесійному ключі клієнт/сервіс.

3. Клієнт розшифровує підтвердження, використовуючи сесійний ключ клієнт/сервіс і перевіряє, чи дійсно мітка часу коректно оновлена. Якщо це так, то клієнт може довіряти серверу і може почати посилати запити на сервер.

4. Сервер надає клієнтові необхідний сервіс.

PKINIT

Розширення PKINIT торкнулося етап попередньої аутентифікації клієнта. Після чого вона стала відбуватися таким чином:

1. Користувач ідентифікується в системі і пред'являє свій закритий ключ.

2. Клієнтська машина формує запит на СА (AS_REQ), в якому вказує, що буде використовуватися асиметричне шифрування. Відмінність даного запиту полягає в тому, що він підписується (за допомогою закритого ключа клієнта) і крім стандартної інформації містить сертифікат відкритого ключа користувача.

3. Отримавши запит, ЦРК спочатку перевіряє достовірність сертифіката користувача, а потім електронний підпис (використовуючи отриманий відкритий ключ користувача). Після цього ЦРК перевіряє локальне час, прислане в запиті (для захисту від повторів).

4. Упевнившись у справжності клієнта, ЦРК формує відповідь (AS_REP), в якому на відміну від стандартної версії, сеансовий ключ зашифрована відкритим ключем користувача. Крім того відповідь містить сертифікат ЦРК і підписується його закритим ключем (аналогічно запитом клієнта).

5. Отримавши відповідь, користувач перевіряє підпис ЦРК і розшифровує свій сеансовий ключ (використовуючи свій закритий) Подальші етапи відбуваються згідно стандартному опису Kerberos V5.