Kerberos использует в качестве основы протокол Needham-Schroeder. Он использует аутентификацию доверенной третьей стороны, известную как "центр распределения ключей (KDC)", которая состоит из двух логически отдельных частей: Сервера аутентификации (AS) и Сервера выдачи билетов (TGS). Kerberos работает на основе "билетов" (называемых билетами Kerberos), которые служат для подтверждения личности пользователей.
База данных Kerberos: Центр распределения ключей (KDC) поддерживает базу данных секретных ключей; каждая сущность в сети - будь то клиент или сервер - делится секретным ключом, известным только себе и KDC. Знание этого ключа служит для подтверждения личности каждого субъекта. Для связи между двумя организациями KDC генерирует ключ сеанса, который они могут использовать для защиты своих коммуникаций.
Термин "сервер Kerberos" обычно относится к KDC. В целях обеспечения надежности можно иметь резервные KDC. Их называют "вторичные серверы Kerberos". Все ведомые устройства синхронизируют свои базы данных с главного сервера Kerberos.
Термин "Керберизованный сервер приложений" обычно относится к Керберизованным программам, с которыми клиенты взаимодействуют, используя билеты Kerberos для аутентификации. Например, телнет-сервер Kerberos является примером Керберизованного сервера приложений . Хотя термин "Kerberized applications" используется для обозначения клиентской стороны сервера приложений Kerberized, например, телнет-клиент Kerberos является примером Kerberized application
Безопасность протокола во многом зависит от него:
- Участники сохраняют слабо синхронизированное время.
- Краткосрочная декларация подлинности: билеты на Керберос.
Упрощенное описание протокола
Будут использоваться следующие сокращения:
· AS = Сервер аутентификации
· TGS = сервер выдачи билетов
· SS или Сервер = Сервер обслуживания (пользователь сервера, запрашивающий свою услугу, например, сервер печати, файловый сервер и т.д...).
· TGT = Предоставление билета (билет на TGS на керберос. Готовится AS, затем используется для разговора с TGS).
Вкратце, клиент аутентифицируется в АО, используя долгосрочный общий секрет, и получает от АО билет. Позже клиент может использовать этот тикет, чтобы получить дополнительные тикеты на SS, используя тот же общий секрет. Эти билеты можно использовать, чтобы доказать подлинность СС.
Протокол более подробно
Шаги входа в систему на основе клиента:
- Пользователь вводит имя пользователя и пароль на компьютере клиента.
- Клиент выполняет одностороннюю функцию (в основном хэш-функцию) по введенному паролю, и это становится секретным ключом клиента/пользователя.
Шаги аутентификации клиента:
- Клиент от имени пользователя посылает АП чистое текстовое сообщение с запросом на услуги.
Образец сообщения: "Пользователь XYZ хотел бы запросить услуги".
Примечание: AS не отправляет ни секретный ключ, ни пароль. - AS проверяет, находится ли клиент в своей базе данных. Если это так, то AS отправляет клиенту следующие два сообщения:
- Сообщение А: Ключ сеанса Client/TGS зашифрован с помощью секретного ключа клиента/пользователя.
- Сообщение B: TGT (которое включает в себя идентификатор клиента, сетевой адрес клиента, срок действия билета и Client/TGS Session Key), зашифрованное с помощью секретного ключа TGS.
- Как только клиент получает сообщения A и B, он расшифровывает сообщение A для получения ключа сеанса Client/TGS. Этот сеансовый ключ используется для дальнейших коммуникаций с TGS. На данный момент клиент имеет достаточно информации для аутентификации в TGS.
Примечание: Клиент не может расшифровать сообщение B, поскольку оно зашифровано с помощью секретного ключа TGS.
Шаги авторизации обслуживания клиентов:
- При запросе услуг клиент отправляет следующие два сообщения в TGS:
- Сообщение C: состоит из TGT из сообщения B и идентификатора запрашиваемой услуги.
- Сообщение D: Аутентификатор (который состоит из идентификатора клиента и метки времени), зашифрованный с помощью Client/TGS Session Key.
- При получении сообщений C и D TGS извлекает сообщение B из сообщения C. Он расшифровывает сообщение B с помощью секретного ключа TGS. Это дает ему ключ сеанса клиент/Т"". Используя этот ключ, TGS расшифровывает сообщение D (Authenticator) и отправляет следующие два сообщения клиенту:
- Сообщение E: Тикет "клиент-сервер" (включающий в себя идентификатор клиента, сетевой адрес клиента, срок действия и сеансовый ключ "клиент-сервер"), зашифрованный с помощью секретного ключа SS.
- Сообщение F: Ключ сеанса клиент/сервер, зашифрованный с помощью ключа сеанса клиент/сервер.
Шаги запроса клиентского сервиса:
- После получения сообщений E и F от TGS, клиент имеет достаточно информации, чтобы удостовериться в подлинности SS. Клиент подключается к SS и посылает следующие два сообщения:
- Сообщение E: с предыдущего шага (билет "клиент-сервер", зашифрованный с помощью секретного ключа SS).
- Сообщение G: новый аутентификатор, включающий идентификатор клиента, временную метку и зашифрованный с помощью Client/Server Session Key.
- SS расшифровывает тикет, используя собственный секретный ключ для получения ключа сеанса клиент/сервер. Используя ключ сеанса, SS расшифровывает Аутентификатор и посылает следующее сообщение клиенту, чтобы подтвердить его истинную идентичность и готовность обслуживать клиента:
- Сообщение H: временная метка, найденная в Аутентификаторе клиента плюс 1, зашифрованная с помощью Client/Server Session Key.
- Клиент расшифровывает подтверждение с помощью Client/Server Session Key и проверяет правильность обновления метки времени. Если да, то клиент может доверять серверу и начать выдачу сервисных запросов к серверу.
- Сервер предоставляет запрошенные услуги клиенту.
