Kerberos

Kerberos (RFC 4120) - протокол аутентификации в котором участвуют три стороны: клиент, сервер, доверенное лицо. Отсюда и название - в честь того самого мифического адского пса. Актуальная, пятая версия Kerberos, используется по умолчанию для аутентификации в современных версиях AD, а также во многих других сервисах.

В отличии от 4й версии, протоколом предусмотрен выбор алгоритма шифрования данных. Кроме того, в 5 версии доступно расширение PKINIT которое позволяет использовать ассиметричную криптографию на этапе аутентификации.

В основу работы Kerberos положен принцип того, что если имеется доверенная сторона у которой есть общий секрет между каждым участником переговоров, сделать такие переговоры безопасными для каждой стороны не составляет труда.

Термины

Client - Приложение желающее получить услуги предоставляемые Service-ом

Service - Приложение предоставляющее различные услуги

KDC (Key distribution center) - Сервис поставляемый в составе AD. Cодержит БД логинов/паролей для пользователей и сервисов использующих Kerberos. Выдает TGT, TGS.

AS (Authentication server) - Входит в состав KDC.

TGServ (Ticket granting Service) - Входит в состав KDC. Во многих источничках фигурирует под абревиатурой TGS.

krbtgt (Kerberos ticket granting ticket)- Сервисный аккаунт от имени которого работает KDC. Подробнее на technet.

TGT (Ticket granting ticket) - Билет (мандат) на получение билетов - файл зашифрованный ключем krbtg содержащий в себе следующие сведения: Client ID, Client IP address, копия Session key, KDC Timestamp, Ticket TTL. Используется в качестве подтверждения того, что предъявляющий TGT ранее корректно прошел аутентификацию.

TGS (Ticket granting service) - Билет (мандат) на получение услуги(сервиса) - файл зашифрованный ключом

Client ID/Username/Client principal name - Уникальный идентификатор клиента хранящийся в KDC.

SPN (Service principal name) - Уникальный идентификатор сервера хранящийся в KDC.

Session key - Случайно сгененрированная последовательность для шифрования сообщений на различных этапах взаимодействия. Генерируется KDC в двух экземплярах. Один отдается клиенту, второй помещается в TGT/TGS.

Timestamp - Метка времени. Используется на различных этапах взаимодействия для проверки соответствия времени. Как правило, взаимодействие возможно если разница во времени между меткой и текущим временем не превышает 300 с.

UserHash - Ключ клиента - который является результатом работы хэш функции над паролем клиента. Service owner Hash - Ключ сервера - которая является результатом работы хэш функции над паролем учетной записи сервиса.

Ticket TTL - Время жизни билета. Как правило в пределах 8 - 10 часов.

Краткая аналогия

Краткую аналогию на работу Kerberos можно описать, на примере доступа к режимному объекту:
Работник (Client) который хочет получить доступ к режимному объекту должен предъявить на проходной (Service) пропуск (TGS) который подтверждает личность работника и содержит в себе отметку о разрешении допуска на режимный объект.

На проходной видя пропуск понимают, что он был выдан уполномоченной службой (KDC), доверие к которой не вызывает сомнения, а следовательно пропускают клиента.

Стоит добавить, что перед получением пропуска, работнику нужно подтвердить свою личноcть перед такой уполномоченной службой.

Документом подтверждающим личность является паспорт клиента (TGT), который также был получен им от доверенной стороны - Государства (KDC).

При получении паспорта - работник подтверждает перед Государством (KDC) свою личность путем предъявления сведений которые известны только работнику (Client) и Государству (KDC), к примеру свидетельство о рождении, или ранее выданный паспорт (Client ID + Timestamp + Userhash).

Таким образом выстраивается доверие между всеми сторонами.

Описание работы

Далее поэтапное описание работы протокола.

Этап №1 Аутентификация. Получение Ticket granting ticket (TGT).

Для получения возможности обращатся к KDC без передачи логина/пароля используется TGT.

Клиент передает KDC ClientID/Username и Timestamp который шифруются UserHash-ем.
KDC расшифровывает полученные сведения с помощью хранящегося на нем UserHash, проверяет Timestamp.
В случае прохождения проверок, генерирует 2 копии Session Key. Одну помещает в TGT который шифрует своим ключем (krbtgt hash), вторую копию шифрует ключем клиента.
Отправляет клиенту зашифрованные TGT и копию Session Key.

В результате, клиент получает TGT, по предъявлении которого KDC понимает, что этот клиент уже прошел авторизацию ранее. Также у клиента на руках теперь имеется его копия Session key который будет использоваться для шифрования дальнейших запросов к KDC.

Этап №2 Авторизация. Получение Ticket granting service (TGS)

В случае, если клиент хочет получить доступ к определенному сервису (для примера возьмем MSSQL) ему необходимо получить TGS к этому сервису.

Клиент передает KDC Username и Timestamp зашифрованные копией Session Key которая была получена им на предыдущем этапе(описанный массив информации называется аутентификатором). Так же в посылке содержится полученный на предыдущем этапе TGT и SPN необходимого сервера.
Получив посылку, KDC расшифровывает TGT (который зашифрован его же ключем) в котором находит свою копию Session Key с помощью которого расшифровывает аутентификатор.
Проверив Timestamp, KDC генерирует 2 копии нового случайного Session Key. Одну копию помещает в TGS который шифрует ключем сервиса (Service Owner Hash), вторую копию шифрует ключем клиента.
Отправляет клиенту зашифрованные TGS и копию Session key.

В результате, клиент получает TGS, который может предъявить нужному сервису для получения его услуг. Также у клиента на руках теперь имеется его копия нового Session key который будет использоваться для шифрования дальнейших запросов к целевому сервису.

Этап №3 Запрос сервиса.

После предыдущих этапов, клиент имеет на руках копию Session key для общения с целевым сервисом и TGS который нужно предъявить этому сервису.

Клиент передает сервису Username и Timestamp зашифрованные копией Session Key которая была получена им на предыдущем этапе(описанный массив информации называется аутентификатором). Так же в посылке содержится полученный на предыдущем этапе TGS.
Получив посылку, сервис расшифровывает TGS (который зашифрован его же ключем) в котором находит свою копию Session Key с помощью которого расшифровывает аутентификатор.
Проверив Timestamp, сервис отправляет в адрес клиента подтверждение готовности обслуживания: Timestamp + 1 зашифрованную свой копией Session Key.
Клиент расшифровывает сообщение и увидив Timestamp + 1 начинает посылать запросы серверу.

Важно!

Корректное время у всех участников протокола является крайне важным и должно быть настроено соответствующим образом.
Компроментация пароля krbtgt может привести к выходу всей системы из строя. Такая атака называется Golden Ticket.