Kerberos 5. 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. Сервер надає клієнтові необхідний сервіс.

Дата добавления: 2014-12-25