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, тому його реалізація повністю залежить від програми.

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