Система автентифікації в інформаційній системі на базі протоколу Kerberos

З точки зору клієнта, білет TGT майже нічим не відрізняється від звичайного. Перед підключенням до будь-якої службі, клієнт, перш за все, звертається до кеш-пам'ять посвідчень і дістає звідти сеансовий білет для цієї служби. Якщо його немає, він починає шукати в цій же кеш-пам'яті білет TGT. Знайшовши його, клієнт отримує звідти ж відповідний сеансовий ключ реєстрації і готує з його допомогою автентифікатор, який разом з TGT висилає до KDC. Одночасно туди направляється запит на сеансовий білет для необхідної служби. Іншими словами, організація безпечного доступу до KDC нічим не відрізняється від організації такого доступу до будь-якої іншої службі домену - вона вимагає сеансового ключа, автентифікатором та білета.

З точки ж зору служби KDC, білети TGT дозволяють прискорити обробку запитів на отримання білетів, заощадивши кілька наносекунд на пересиланні кожного з них. Центр розподілу ключів KDC звертається до довготривалого ключа користувача тільки один раз, коли надає клієнту початковий білет TGT. У всіх подальших транзакціях з цим клієнтом центр KDC розшифровує білети TGT за допомогою власного довгострокового ключа і витягує з нього сеансовий ключ реєстрації, який використовує для перевірки автентичності автентифікатора клієнта.

 

1. Автентифікація за межами домену

Функції центру KDC можна  розділити на дві категорії: службу автентифікації, у завдання якої входить генерація білетів TGT, і службу видачі білетів, створює сеансові білети. Такий поділ праці дозволяє застосовувати протокол Kerberos і за межами його «рідного» домену. Клієнт, який отримав білет TGT зі служби автентифікації одного домену, може скористатися ним для отримання сеансових білетів в службах видачі білетів інших доменів.

Щоб краще зрозуміти принцип  міждоменної автентифікації, розглянемо для початку найпростішу мережу, яка містить усього два домени - «Схід» і «Захід». Припустимо, що адміністратори цих доменів є співробітниками однієї організації або у них є які-небудь інші вагомі причини зрівняти користувачів другого домену зі своїми власними. У будь-якому з цих випадків налагодити автентифікацію між доменами неважко, для цього достатньо домовитися про єдиний міждоменний ключ. Як тільки ключ створений, служба видачі білетів кожного домену реєструється в центрі KDC іншого домену в якості головного абонента безпеки. У результаті служба видачі білетів кожного з доменів починає розглядати службу видачі білетів другого домену, як ще одну свою службу. Завдяки цьому клієнт, що пройшов автентифікацію і зареєструвався в системі, може запитувати і отримувати сеансові білети для неї.

А тепер розглянемо, що відбувається, коли користувач з обліковим  записом в домені «Схід» запитує  доступ до сервера з домену «Захід». Перш за все, клієнт Kerberos, встановлений на робочій станції користувача, надсилає запит до служби видачі білетів свого домену, в якому просить видати сеансовий білет для доступу на потрібний сервер. Служба видачі білетів домену «Схід» перевіряє список своїх абонентів безпеки і переконується, що такого сервера серед них немає. Тому вона направляє клієнтові так званий білет переадресації (referral ticket), який представляє собою TGT, зашифрований за допомогою міждоменного ключа, спільного для служб KDC доменів «Схід» і «Захід». Отримавши білет переадресації, клієнт використовує його для підготовки іншого запиту на сеансовий ключ. Однак на цей раз запит пересилається в службу видачі білетів того домену, де знаходиться обліковий запис потрібного сервера, тобто, домену «Захід». Його служба видачі білетів намагається розшифрувати білет переадресації за допомогою власної копії Міждомена ключа. Якщо спроба вдається, центр KDC направляє клієнтові сеансовий білет на доступ до відповідного серверу свого домену.

Процес переадресації  запиту дещо ускладнюється у мережах, де розгорнуто більше двох доменів. Теоретично служба KDC кожного домену може встановити безпосередній зв'язок з аналогічними службами всіх доменів мережі, домовившись з кожною з них про індивідуальний міждоменний ключ. Однак на практиці кількість і складність подібних взаємозв'язків дуже швидко зростають до такої міри, що стають просто некерованими, особливо в складних мережах. Протокол Kerberos вирішує цю проблему, роблячи непотрібними прямі зв'язки між доменами. Клієнт одного домену може отримати білет на доступ до сервера іншого домену через один або кілька проміжних серверів, кожен з яких видасть йому білет переадресації.

В якості прикладу розглянемо мережу, що складається з трьох  доменів: «Схід», «Захід» і «Штаб-квартира». У службі KDC домену «Схід» немає міждоменного ключа для аналогічної служби домену «Захід», але центри розподілу ключів обох доменів налагодили обмін білетами з доменом «Штаб-квартира». Коли користувач з обліковим записом в домені «Схід» хоче підключитися до сервера з домену «Захід», його запит буде переадресовано двічі. Спочатку він пройде через службу KDC «рідного» домену, потім - через проміжний домен «Штаб-квартира» і, нарешті, досягне центру розподілу ключів домену «Захід», якому відомий ключ потрібного сервера. Таким чином, клієнт тут посилає сеансові білети тричі на три різні служби KDC.

1. Клієнт запитує у служби KDC домену «Схід» білет на доступ до сервера домена «Захід».

Служба KDC домену «Схід» спрямовує клієнту білет переадресації в службу KDC домену «Штаб-квартира», зашифрований з міждоменним ключем, загальним для доменів «Схід» і «Штаб-квартира».

2. Клієнт звертається до служби KDC домену «Штаб-квартира» з проханням про білет на доступ до сервера домена «Захід».

Служба KDC домену «Штаб-квартира»  спрямовує клієнту білет переадресації в службу KDC домену «Захід», зашифрований з Міждомена ключем, загальним для доменів «Штаб-квартира» та «Захід».

3. Клієнт звертається до служби KDC домену «Захід» з проханням про білет на доступ до сервера домена «Захід».

Служба KDC домену «Захід»  спрямовує клієнту білет на доступ до потрібного сервера.

 

 

• Підпротоколи

Протокол Kerberos містить  у собі три підпротоколи:

• Перший з них використовується службою KDC для передачі клієнту сеансового ключа реєстрації та білета TGT. Він називається Authentication Service Exchange (обмін зі службою автентифікації) або, скорочено AS Exchange.
• Другий подпротокол під назвою Ticket-Granting Service Exchange (обмін зі службою видачі білетів) або TGS Exchange служить для розсилки службових сеансових ключів і сеансових ключів самої служби KDC.
• Третій подпротокол, Client / Server Exchange (клієнт-серверний обмін) або CS Exchange, використовується клієнтом для пересилання сеансового білета доступу до служб.

Щоб краще розібратися  в тому, як ці під протоколи взаємодіють  між собою, давайте подивимося, що відбувається, коли Олена, користувач робочої станції, звертається до Сергія, мережевої служби.

 

• Підпротокол AS Exchange

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

Після цього клієнт посилає в  службу автентифікації центру KDC запит KRB_AS_REQ (Kerberos Authentication Service Request - запит до служби автентифікації Kerberos). Перша частина його повідомлення містить ідентифікатор користувача, тобто Олени, а також ім'я служби, для якої їй потрібно посвідчення, тобто служби видачі білетів. У другій частині вказуються дані попередньої автентифікації (pre-authentication data), які підтверджують, що Олена знає пароль. Зазвичай в якості таких даних використовується мітка часу, зашифрована з довготривалим ключем Олени, хоча Kerberos допускає і інші види предавтентіфікаціонних даних (рисунок 2.5).

 

Рисунок 2.5 - Подпротокол AS Exchange

Отримавши запит KRB_AS_REQ, служба KDC звертається до своєї бази даних  і знаходить у ній довготривалий  ключ Олени, після чого розшифровує дані попередньої автентифікації і оцінює мітку часу, що міститься в них. Якщо перевірка пройшла успішно, служба KDC робить висновок, що дані попередньої автентифікації були зашифровані з довготривалим ключем Олени і, отже, надійшли від клієнта, ім'я якого міститься в першій частині повідомлення.

Після того, як перевірка  особи Олени завершена, служба KDC генерує посвідчення, яке підтверджує, що клієнт Kerberos на її робочої станції має право звернутися до служби видачі білетів. Цей процес виконується в два етапи. По-перше, KDC створює сеансовий ключ реєстрації та шифрує його копію за допомогою довгострокового ключа Олени. По-друге, служба включає ще одну копію сеансового ключа реєстрації у білет TGT. Туди ж заноситься і інша інформація про Олену, наприклад, її дані авторизації. Потім KDC шифрує білет TGT з власним довготривалим ключем і, нарешті, включає зашифрований сеансовий ключ реєстрації разом з білетом TGT в пакет KRB_AS_REP (Kerberos Authentication Service Reply - відповідь служби автентифікації Kerberos), який направляє клієнту.

Отримавши таке повідомлення, клієнт розшифровує сеансовий ключ реєстрації і зберігає його у кеш-пам'яті посвідчень. Після цього з повідомлення витягується білет TGT, який також міститься в цій кеш-пам'ять.

 

• Підпротокол TGS Exchange

Клієнт Kerberos, встановлений на робочій станції Олени, запитує посвідчення на доступ до служби Сергій, для чого посилає в службу KDC повідомлення KRB_TGS_REQ (Kerberos Ticket-Granting Service Request - запит до служби видачі білетів Kerberos). У нього включається ім'я користувача, автентифікатор, зашифрований за допомогою сеансового ключа реєстрації Олени, білет TGT, який був отриманий за допомогою подпротокола AS Exchange, а також ім'я служби, на доступ до якої потрібен білет(рисунок 2.6).

 

Рисунок 2.6 - Подпротокол TGS Exchange

Отримавши запит KRB_TGS_REQ, служба KDC за допомогою власного секретного ключа розшифровує білет TGT і витягує з нього сеансовий ключ реєстрації Олени, який тут же використовує для розшифровки автентифікатором. Якщо вміст автентифікатора витримує перевірку, служба KDC витягує з білета TGT реєстраційні дані Олени і генерує сеансовий ключ, загальний для клієнта Олени та служби Сергій. Одну копію цього ключа KDC шифрує за допомогою сеансового ключа реєстрації Олени, а іншу разом з даними авторизації Олени поміщає у білет, який шифрує за допомогою довгострокового ключа Сергія. Після цього посвідчення Олени включається в пакет KRB_TGS_REP (Kerberos Ticket-Granting Service Reply - відповідь служби видачі білетів Kerberos) і прямує на її робочу станцію.

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

 

• Підпротокол CS Exchange

Клієнт Kerberos, встановлений на робочій станції Олени, звертається до служби Сергій, для чого посилає на неї запит KRB_AP_REQ (Kerberos Application Request - Запит програми Kerberos). Це повідомлення містить автентифікатор Олени, зашифрований за допомогою сеансового ключа для служби Сергій, білет, отриманий за допомогою протоколу TGS Exchange, а також прапор, який вказує про бажання клієнта провести взаємну автентифікацію (рисунок 2.7).

 

Рисунок 2.7 - Подпротокол CS Exchange

Отримавши повідомлення KRB_AP_REQ, служба Сергій розшифровує білет, витягує з нього дані авторизації Олени і сеансовий ключ, за допомогою якого відразу ж розшифровує автентифікатор Олени. Якщо мітка часу, закладена в нього, витримує перевірку, Сергій шукає в запиті прапор взаємної автентифікації. Знайшовши його, Сергій шифрує мітку часу з автентифікатором Олени сеансовим ключем, включає отриманий результат в пакет KRB_AP_REP (Kerberos Application Reply - відповідь додатка Kerberos) і повертає його на робочу станцію Олени.

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

 

• Білети

Перерахування полів білета і описання яке міститься в них  
(таблиця 2.1).

Таблиця 2.1 - Поля білета

Назва поля	Опис
Перші три поля білета не шифруються. Інформація, що міститься тут інформація пересилається відкритим текстом, що дозволяє клієнту використовувати її для управління білетами, що зберігаються в кеш-пам'яті.
tkt-vno	Номер версії формату білета.
Realm	Ім'я області (домену), де згенеровано білет. Служба KDC може створювати білети тільки для серверів власної області, тому тут, по суті, вказується ім'я області, де розташований сервер.
Sname	Ім'я сервера.
Інші поля шифруються за допомогою секретного ключа сервера.
Flags	Прапори білета.
Key	Сеансовий ключ.
Crealm	Ім'я області (домену) клієнта.
Cname	Ім'я клієнта.
Transited	Список областей Kerberos, які брали участь в автентифікації клієнта, якій видано даний білет.
Authtime	Час первісної автентифікації клієнта. Служба KDC заповнює це поле в момент генерації білета TGT. При генерації білетів на основі білета TGT тимчасова мітка з поля authtime білета TGT копіюється в поле authtime генерується білета.
Starttime	Час вступу білета в силу.
Endtime	Час закінчення терміну  дії білета.