Відмінності між версіями «Kerberos (протокол)»

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
[неперевірена версія][перевірена версія]
 
(Не показані 14 проміжних версій 8 користувачів)
Рядок 1: Рядок 1:
'''Протокол Kerberos''' (з англ. ''Цербер''), орієнтований в основному на клієнт-серверну архітектуру, пропонує механізм взаємної аутентифікації двох співрозмовників (хостів) перед встановленням зв'язку між ними в умовах незахищеного каналу. Kerberos - це також пакет [[Вільне програмне забезпечення|вільного програмного забезпечення]] розробленого в Массачусетському технологічному інституті, що реалізовує цей протокол. Повідомлення протоколу Kerberos захищені проти прослуховування мережі та повторних атак ({{lang-en|replay attack}}).
+
'''Протокол Kerberos''' (з англ. ''Цербер'') — орієнтований в основному на клієнт-серверну архітектуру, пропонує механізм взаємної [[Автентифікація|аутентифікації]] двох співрозмовників (хостів) перед встановленням зв'язку між ними в умовах незахищеного каналу. Kerberos — це також пакет [[Вільне програмне забезпечення|вільного програмного забезпечення]] розробленого в [[Массачусетський технологічний інститут|Массачусетському технологічному інституті]], що реалізовує цей протокол. Повідомлення протоколу Kerberos захищені проти прослуховування мережі та повторних атак ({{lang-en|replay attack}}).
   
 
Kerberos базується на [[Симетричні алгоритми шифрування|симетричних алгоритмах шифрування]] та для своєї роботи потребує довірену третю сторону. Деякі модифікації протоколу можуть використовувати елементи [[Асиметричні алгоритми шифрування|асиметричного шифрування]].
 
Kerberos базується на [[Симетричні алгоритми шифрування|симетричних алгоритмах шифрування]] та для своєї роботи потребує довірену третю сторону. Деякі модифікації протоколу можуть використовувати елементи [[Асиметричні алгоритми шифрування|асиметричного шифрування]].
   
 
== Історія і розвиток ==
 
== Історія і розвиток ==
Протокол Кербер розроблявся інститутом [[Массачусетський технологічний інститут|МІТ]] для забезпечення безпеки сервісів проекту Афіна, метою якого було забезпечення доступності навчальних матеріалів із будь-якої станції. Назва протоколу походить від грецької міфічної триголової потвори [[Кербер|Цербера]], захисника підземного царства. Існує декілька версій протоколу Включно із третьою були доступні лише для внутрішнього користування у МІТ.
+
Протокол Kerberos розроблявся інститутом [[Массачусетський технологічний інститут|МІТ]] для забезпечення безпеки сервісів {{нп5|Проект Афіна|проекту Афіна|en|Project Athena}}, метою якого було забезпечення доступності навчальних матеріалів із будь-якої станції. Назва протоколу походить від грецької міфічної триголової потвори [[Кербер|Цербера]], захисника підземного царства. Існує декілька версій протоколу Включно із третьою були доступні лише для внутрішнього користування у МІТ.
   
Стів Міллер ({{lang-en|Steve Miller}}) та Кліффорд Ньюман ({{lang-en|Clifford Neuman}}), основні архітектори четвертої версії Кербера, опублікували її у кінці [[1980]]-х, хоча вона також розроблялась в основному для проекту Афіна. П'ята версія протоколу, розроблена Джоном Колем ({{lang-en|John Kohl}}) та Кліффордом Ньюманом, з'явилась у 1993 році
+
Стів Міллер ({{lang-en|Steve Miller}}) та Кліффорд Ньюман ({{lang-en|Clifford Neuman}}), основні архітектори четвертої версії Kerberos, опублікували її у кінці [[1980]]-х, хоча вона також розроблялась в основному для проекту Афіна. П'ята версія протоколу, розроблена Джоном Колем ({{lang-en|John Kohl}}) та Кліффордом Ньюманом, з'явилась у 1993 році
 
як рекомендація на стандарт RFC 1510, оновлена 2005 року у RFC 4120.
 
як рекомендація на стандарт RFC 1510, оновлена 2005 року у RFC 4120.
   
 
== Цілі ==
 
== Цілі ==
У своїй основі протокол Кербер ставить перед собою реалізацію таких принципів:
+
У своїй основі протокол Kerberos ставить перед собою реалізацію таких принципів:
 
* Пароль користувача ніколи не повинен передаватись по мережі;
 
* Пароль користувача ніколи не повинен передаватись по мережі;
* Пароль користувача ні в якій формі не повинен зберігатись на клієнтській машині: він має бути ліквідований одразу після використання;
+
* Пароль користувача в жодній формі не має зберігатись на клієнтській машині: він має бути ліквідований одразу після використання;
* Пароль користувача не повинен зберігатись у незашифрованому вигляді навіть у базі даних аутентифікації (authentication server database);
+
* Пароль користувача не має зберігатись у незашифрованому вигляді навіть у базі даних аутентифікації (authentication server database);
 
* Користувач вводить пароль лише раз за сесію. Таким чином, користувачі мають доступ до всіх сервісів, на які вони авторизовані, без потреби заново вводити пароль під час сесії. Ця властивість також відома як '''Single Sign-On''';
 
* Користувач вводить пароль лише раз за сесію. Таким чином, користувачі мають доступ до всіх сервісів, на які вони авторизовані, без потреби заново вводити пароль під час сесії. Ця властивість також відома як '''Single Sign-On''';
 
* Управління аутентифікацією здійснюється централізовано сервером аутентифікації. Прикладні сервери, що надають послуги, не повинні містити аутентифікаційних відомостей користувачів. Це важливо для централізованого адміністрування облікових записів користувачів; не зберігається надлишкова інформація аутентифікації на різних серверах; при зміні користувачем паролю, він одночасно міняється для всіх наданих послуг.
 
* Управління аутентифікацією здійснюється централізовано сервером аутентифікації. Прикладні сервери, що надають послуги, не повинні містити аутентифікаційних відомостей користувачів. Це важливо для централізованого адміністрування облікових записів користувачів; не зберігається надлишкова інформація аутентифікації на різних серверах; при зміні користувачем паролю, він одночасно міняється для всіх наданих послуг.
 
* Не лише користувачі зобов'язані підтвердити, що вони є тими, ким заявляють, але й прикладні сервери повинні підтвердити свою ідентичність користувачам. Цей процес називається '''Взаємна аутентифікація''';
 
* Не лише користувачі зобов'язані підтвердити, що вони є тими, ким заявляють, але й прикладні сервери повинні підтвердити свою ідентичність користувачам. Цей процес називається '''Взаємна аутентифікація''';
* Після завершення етапів аутентифікації та авторизації, клієнт та сервер повинні мати можливість встановити зашифрований зв'язок. З цією метою Кербер підтримує генерацію і обмін ключів шифрування.
+
* Після завершення етапів аутентифікації та авторизації, клієнт і сервер мають мати можливість встановити зашифрований зв'язок. Із цією метою Kerberos підтримує генерацію ключів шифрування й обмін ними.
   
 
== Опис протоколу ==
 
== Опис протоколу ==
В основу Кербер покладений [[протокол Нідхема-Шредера]]. У ролі довіреної третьої сторони виступає Центр Розподілення Ключів (ЦРК, {{lang-en|Key Distribution Center}}), що складається із двох логічно розділених частин: Сервера Аутентифікації (ЦА, {{lang-en|Authentication Server}}) і Сервера Видачі Квитків (СВК, {{lang-en|Ticket Granting Server}}). Кербер працює на основі "квитків", які використовуються для підтвердження ідентичності користувачів.
+
В основу Kerberos покладений [[протокол Нідгема — Шредера]]. У ролі довіреної третьої сторони виступає [[Центр Розподілу Ключів]] (ЦРК, {{lang-en|Key Distribution Center}}), що складається із двох логічно розділених частин: Сервера Аутентифікації (ЦА, {{lang-en|Authentication Server}}) і Сервера Видачі Квитків (СВК, {{lang-en|Ticket Granting Server}}). Kerberos працює на основі «квитків», які використовуються для підтвердження ідентичності користувачів.
   
ЦРК зберігає базу даних закритих ключів; закритий ключ учасника мережі відомий лише йому та ЦРК. Знання цього ключа є підтвердженням ідентичності учасника. Для зв’єднання двох учасників, ЦРК генерує ключ сесії, який забезпечує безпеку повідомлень. Безпека протоколу сильно залежить від синхронізації часу учасників мережі та від обмеження часу придатності квитків.
+
ЦРК зберігає базу даних закритих ключів; закритий ключ учасника мережі відомий лише йому та ЦРК. Знання цього ключа є підтвердженням ідентичності учасника. Для з'єднання двох учасників, ЦРК генерує ключ сесії, який забезпечує безпеку повідомлень. Безпека протоколу сильно залежить від синхронізації часу учасників мережі та від обмеження часу придатності квитків.
   
 
Спрощений опис протоколу виглядає таким чином
 
Спрощений опис протоколу виглядає таким чином
   
* СА - Сервер Аутентифікації
+
* СА — Сервер Аутентифікації
* СВК - Сервер Видачі Квитків
+
* СВК — Сервер Видачі Квитків
* ПС - прикладний сервер, надає послуги
+
* ПС — прикладний сервер, надає послуги
* КВК - Квиток Видачі Квитків ({{lang-en|Ticket Granting Ticket}})
+
* КВК — Квиток Видачі Квитків ({{lang-en|Ticket Granting Ticket}})
   
 
Клієнт проходить аутентифікацію у СА з допомогою довготривалого ''спільного секрету'' і отримує квиток від СА. Пізніше клієнт використовує квиток для отримання додаткових квитків для ПС без потреби використання спільного секрету. Ці квитки підтверджують аутентифікацію для ПС.
 
Клієнт проходить аутентифікацію у СА з допомогою довготривалого ''спільного секрету'' і отримує квиток від СА. Пізніше клієнт використовує квиток для отримання додаткових квитків для ПС без потреби використання спільного секрету. Ці квитки підтверджують аутентифікацію для ПС.
 
<!--
 
Вхід в систему Користувача:
 
# Користувач вводить свій логін та пароль на клієнті
 
# Клієнт виконує односторонню функцію (хеш-функцію) над паролем і це стає секретним ключем клієнта.
 
 
Кроки аутентифікації клієнта:
 
#
 
#
 
-->
 
 
<!--
 
What follows is a simplified description of the protocol.
 
The following abbreviations will be used:
 
*AS = Authentication Server
 
*TGS = Ticket Granting Server
 
*SS = Service Server
 
*TGT = Ticket Granting Ticket
 
 
Client Authentication Steps:
 
 
# The client sends a [[cleartext]] message to the AS requesting services on behalf of the user. Sample message: "User XYZ would like to request services". Note: Neither the secret key nor the password is sent to the AS.
 
# The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:
 
#* Message A: ''Client/TGS Session Key'' encrypted using the secret key of the user.
 
#* Message B: ''Ticket-Granting Ticket'' (which includes the client ID, client network address, ticket validity period, and the ''client/TGS session key'') encrypted using the secret key of the TGS.
 
# Once the client receives messages A and B, it decrypts message A to obtain the ''Client/TGS Session Key''. This session key is used for further communications with TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS.
 
 
Client Service Authorization Steps:
 
 
# When requesting services, the client sends the following two messages to the TGS:
 
#* Message C: Composed of the ''Ticket-Granting Ticket'' from message B and the ID of the requested service.
 
#* Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the ''Client/TGS Session Key''.
 
# Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client:
 
#* Message E: ''Client-to-server ticket'' (which includes the client ID, client network address, validity period and ''Client/Server Session Key'') encrypted using the service's secret key.
 
#* Message F: ''Client/server session key'' encrypted with the ''Client/TGS Session Key''.
 
 
Client Service Request Steps:
 
 
# Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages:
 
#* Message E from the previous step (the ''client-to-server ticket'', encrypted using service's secret key).
 
#* Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using ''client/server session key''.
 
# The SS decrypts the ticket using its own secret key to retrieve the ''Client/Server Session Key''. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:
 
#* Message H: the timestamp found in client's Authenticator plus 1, encrypted using the ''Client/Server Session Key''.
 
# The client decrypts the confirmation using the ''Client/Server Session Key'' and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server.
 
# The server provides the requested services to the client.
 
 
-->
 
   
 
== Посилання ==
 
== Посилання ==
 
* [http://www.kerberos.org/software/tutorial.html Опис протоколу]
 
* [http://www.kerberos.org/software/tutorial.html Опис протоколу]
* [http://www.ixbt.com/comm/kerberos5.shtml Kerberos 5, основні концепції]
+
* [http://www.youtube.com/watch?v=kp5d8Yv3-0c How does Kerberos works]
  +
* [http://www.ixbt.com/comm/kerberos5.shtml Kerberos 5, основні концепції]{{ref-ru}}
* [http://technet2.microsoft.com/windowsserver/en/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx?pf=true Опис протоколу Kerberos 5 і його архітектурна реалізація у Windows Server 2003]
+
* [http://technet2.microsoft.com/windowsserver/en/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx?pf=true Опис протоколу Kerberos 5 і його архітектурна реалізація у Windows Server 2003]{{Недоступне посилання|date=червень 2019 |bot=InternetArchiveBot }}
 
{{Доробити}}
 
   
  +
{{Crypto-stub}}{{Computer-security-stub}}
  +
{{refimprove|date=січень 2017}}
  +
{{ВП-портали|Інформаційні технології|}}
  +
{{Автентифікація}}
 
[[Категорія:Вільне програмне забезпечення]]
 
[[Категорія:Вільне програмне забезпечення]]
[[Категорія:Криптографія]]
+
[[Категорія:Криптографічні протоколи]]
  +
[[Категорія:Алгоритми з симетричними ключами]]
  +
[[Категорія:Автентифікація]]

Поточна версія на 18:01, 23 серпня 2019

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

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

Історія і розвиток[ред. | ред. код]

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

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

Цілі[ред. | ред. код]

У своїй основі протокол Kerberos ставить перед собою реалізацію таких принципів:

  • Пароль користувача ніколи не повинен передаватись по мережі;
  • Пароль користувача в жодній формі не має зберігатись на клієнтській машині: він має бути ліквідований одразу після використання;
  • Пароль користувача не має зберігатись у незашифрованому вигляді навіть у базі даних аутентифікації (authentication server database);
  • Користувач вводить пароль лише раз за сесію. Таким чином, користувачі мають доступ до всіх сервісів, на які вони авторизовані, без потреби заново вводити пароль під час сесії. Ця властивість також відома як Single Sign-On;
  • Управління аутентифікацією здійснюється централізовано сервером аутентифікації. Прикладні сервери, що надають послуги, не повинні містити аутентифікаційних відомостей користувачів. Це важливо для централізованого адміністрування облікових записів користувачів; не зберігається надлишкова інформація аутентифікації на різних серверах; при зміні користувачем паролю, він одночасно міняється для всіх наданих послуг.
  • Не лише користувачі зобов'язані підтвердити, що вони є тими, ким заявляють, але й прикладні сервери повинні підтвердити свою ідентичність користувачам. Цей процес називається Взаємна аутентифікація;
  • Після завершення етапів аутентифікації та авторизації, клієнт і сервер мають мати можливість встановити зашифрований зв'язок. Із цією метою Kerberos підтримує генерацію ключів шифрування й обмін ними.

Опис протоколу[ред. | ред. код]

В основу Kerberos покладений протокол Нідгема — Шредера. У ролі довіреної третьої сторони виступає Центр Розподілу Ключів (ЦРК, англ. Key Distribution Center), що складається із двох логічно розділених частин: Сервера Аутентифікації (ЦА, англ. Authentication Server) і Сервера Видачі Квитків (СВК, англ. Ticket Granting Server). Kerberos працює на основі «квитків», які використовуються для підтвердження ідентичності користувачів.

ЦРК зберігає базу даних закритих ключів; закритий ключ учасника мережі відомий лише йому та ЦРК. Знання цього ключа є підтвердженням ідентичності учасника. Для з'єднання двох учасників, ЦРК генерує ключ сесії, який забезпечує безпеку повідомлень. Безпека протоколу сильно залежить від синхронізації часу учасників мережі та від обмеження часу придатності квитків.

Спрощений опис протоколу виглядає таким чином

  • СА — Сервер Аутентифікації
  • СВК — Сервер Видачі Квитків
  • ПС — прикладний сервер, надає послуги
  • КВК — Квиток Видачі Квитків (англ. Ticket Granting Ticket)

Клієнт проходить аутентифікацію у СА з допомогою довготривалого спільного секрету і отримує квиток від СА. Пізніше клієнт використовує квиток для отримання додаткових квитків для ПС без потреби використання спільного секрету. Ці квитки підтверджують аутентифікацію для ПС.

Посилання[ред. | ред. код]