Kerberos

Материал из Википедии — свободной энциклопедии

Текущая версия (не проверялась)

Kerberos - это компьютерный сетевой протокол аутентификации, позволяющий отдельным личностям общаться через незащищённые сети для безопасной идентификации. Так же является набором бесплатного ПО от Массачусетского Технологического Института (Massachusetts Institute of Technology (MIT)), разработавшего этот протокол. Ее организация направлена в первую очередь на клиент-серверную модель и обеспечивает взаимную аутентификацию - оба пользователя через сервер подтверждают личности друг друга. Сообщения, отправляемые через протокол Kerberos, защищены от прослушивания и атак.

Kerberos основан на симметричной криптосистеме и требует третье доверенное лицо (сервер). Расширение Kerberos позволяет использовать открытые ключи в процессе аутентификации.

[править] История и разработка

MIT разработала Kerberos для защиты сетевых услуг, предоставляемых Project Athena (проектом Афина). Этот протокол был назван в честь греческого мифологического существа Kerberos (или Цербер), известного в греческой мифологии как чудовище с тремя собачьими головами, защищавшее вход в царство Аида. Существует несколько версий протокола: только в MIT были разработаны версии 1-3.

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

MIT открывает реализации Kerberos в свободный доступ в рамках авторского права аналогичного правам для BSD. В 2007 году MIT сформировали Kerberos Консорциум (Kerberos Consortium) по содействию дальнейшему развитию.

Органы власти США классифицируют Kerberos как военное оружие и был запрещен его экспорт, потому что в нем применялся криптоалгоритм DES. Неамериканский Kerberos 4 (KTH-KRB), разработанный в Королевском Технологическом Институте (The Royal Institute of Technology) в Швеции, стал доступным за границами США до того как Штаты ввели ограничение на экспорт криптосистем.

Шведская реализация базировалась на версии под названием eBones, которая в свою очередь базировалась на экспортированной версии MIT Bones, основанного на Kerberos 4 patch-level 9 eBones. Kerberos 5 Heimdal разрабатывался в основном той же группой людей, что разработала KTH-KRB

Windows 2000 и более поздние версии используют Kerberos как метод аутентификации по умолчанию
Apple Mac OS X использует Kerberos в своих клиентских и серверных версиях.
Red Hat Enterprise Linux 4 использует Kerberos в своих клиентских и серверных версиях.

С 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)

[править] Протокол

Безопасность протокола в значительной мере основывается на том, что системные часы участников более-менее синхронны и на временных утверждениях подлинности, называемых билетами Kerberos.

Ниже приведено упрощенное описание протокола. Следующие аббревиатуры будут использованы:

AS = Сервер аутентификации
TGS = Сервер предоставления билетов
SS = Ресурс, предоставляющий некий сервис, к которому требуется получить доступ
TGT = Билет для получения билета

В двух словах клиент авторизируется на AS, используя свой долгосрочный секретный ключ, и получает билет от AS. Позже клиент может использовать этот билет для получения дополнительных билетов на доступ к ресурсам SS без необходимости прибегать к использованию своего секретного ключа.

Более детально:

Шаги входа пользователя в систему:

Пользователь вводит имя и пароль на клиентской машине.
Клиентская машина выполняет над паролем одностороннюю функцию (обычно хэш), и результат становится секретным ключом клиента/пользователя.

Шаги аутентификации клиента:

Клиент посылает простым текстом сообщение серверу AS, запрашивая сервисы от имени пользователя. Например так: «Пользователь АБВ хочет запросить сервисы». Обратите внимание, что ни секретный ключ, ни пароль не посылаются на AS.
AS проверяет, есть ли такой клиент в базе. Если есть, то назад AS отправляет следующие два сообщения:
- Сообщение A: Сессионный Ключ Client/TGS зашифрованный секретным ключом клиента/пользователя.
- Сообщение B: TGT (который включает ID клиента, сетевой адрес клиента, период действия билета, и Сессионный Ключ Сlient/TGS) зашифрованный секретным ключом TGS.
Как только клиент получает сообщения A и B, он расшифровывает сообщение A, чтобы получить Сессионный Ключ Client/TGS. Этот сессионный ключ используется для дальнейшего обмена с сервером TGS. (Важно: Клиент не может расшифровать сообщение B, так как оно зашифровано секретным ключом TGS.) В этот момент у пользователя достаточно данных, чтобы авторизироваться на TGS.

Шаги авторизации клиента для получения сервиса:

При запросе сервисов клиент отправляет следующие два сообщения на TGS:
- Сообщение C: Содержит TGT, полученный в сообщении B и ID требуемого сервиса.
- Сообщение D: Аутентикатор (составленный из ID клиента и временного штампа), зашифрованный на Сессионном Ключе Client/TGS.
После получения сообщений C и D, TGS извлекает сообщение B из сообщения C и расшифровывает его используя секретный ключ TGS. Это дает ему Сессионный Ключ Client/TGS. Используя его TGS расшифровывает сообщение D и посылает следующие два сообщения клиенту:
- Сообщение E: Client-to-server ticket (который содержит ID клиента, сетевой адрес клиента, время действия билета и Сессионный Ключ Client/server) зашифрованный секретным ключом сервиса.
- Сообщение F: Сессионный ключ Client/server, зашифрованный на Сессионном Ключе Client/TGS.

Шаги клиента при запросе сервиса:

При получении сообщений E и F от TGS, у клиента достаточно информации для авторизации на SS. Клиент соединяется с SS и посылает следующие два сообщения:
- Сообщение E из предыдущего шага (client-to-server ticket, зашифрованный секретным ключом сервиса).
- Сообщение G: новый аутентикатор, который включающий ID клиента, временной штамп и зашифрованный на client/server session key.
SS расшифровывает билет используя свой секретный ключ для получения Сессионного Ключа Client/Server. Используя сессионный ключ, SS расшифровывает аутентикатор и посылает клиенту следующее сообщение для подтверждения готовности обслужить клиента и показать, что сервер действительно является тем, за кого себя выдает:
- Сообщение H: Временной штамп, указанный клиентом + 1, зашифрованный на Сессионном Ключе Client/Server.
Клиент расшифровывает подтверждение, используя Сессионный Ключ Client/Server и проверяет, действительно ли временной штамп корректно обновлен. Если это так, то клиент может доверять серверу и может начать посылать запросы на сервер.
Сервер предоставляет клиенту требуемый сервис.