Управление ключами

5.2. Цербер

Цербер - протокол установления подлинности и в то же самое время - KDC, который стал очень популярным. Несколько систем, включая Windows 2000, используют протокол Цербер. Он назван в честь трехголовой собаки в греческой мифологии, которая охраняет ворота царства мертвых Аида. Первоначально разработанный в MIT, он прошел несколько версий. Мы обсудим только самую популярную версию 4, и кратко объясним отличия между версией 4 и версией 5 (последней).

Серверы

Протокол Цербер включает в себя работу с тремя серверами: опознавательный сервер (AS - Authentication Server), сервер, предоставляющий билет (TGS - Ticket-Granting Server) и реальный сервер (сервер обработки данных), который обеспечивает услуги. В наших примерах и рисунках Боб - реальный сервер, а Алиса - пользователь, запрашивающий сервер. рис. 5.7 показывает отношения между этими тремя серверами.

Рис. 5.7. Серверы протокола Цербер

Опознавательный сервер (AS)

Опознавательный сервер (AS) - в протоколе Цербер - KDC. Каждому пользователю, зарегистрированному в AS, предоставляют пользовательский идентификационный код и пароль. AS имеет базу данных с этими идентификационными кодами и соответствующими паролями. AS верифицирует пользователя, выдает ключ сеанса, который используется между Алисой и TGS, и передает билет для TGS.

Предоставляющий билет сервер (TGS)

Предоставляющий билет сервер (TGS) вырабатывает билет для реального сервера (Боба). ОН обеспечивает ключ сеанса ( K_AB ) между Алисой и Бобом. Протокол Цербер отделяет верификацию пользователя от выдачи билета.

Этим способом Алиса проверяет свой ID с AS только один раз. В контакт с TGS она может войти много раз, чтобы получить билеты для различных реальных серверов.

Реальный сервер

Реальный сервер (Боб) обеспечивает услуги для пользователя (Алиса). Цербер разработан для взаимодействия с программой "клиент-сервер", такой как, например, протокол передачи файлов FTP (File Transfer Protocol), в котором пользователь использует процесс клиента, чтобы обратиться к процессу сервера. Цербер не используется для установления подлинности "человек-человек".

Работа

Процесс клиента (Алиса) может обратиться к процессу, функционирующему на реальном сервере (Боб) в шесть шагов, как это показано на рис. 5.8.

увеличить изображение
Рис. 5.8. Пример работы Цербера

1. Алиса передает свой запрос AS в открытом тексте, используя свой зарегистрированный код идентификации.
2. AS передает сообщение, зашифрованное постоянным симметричным ключом Алисы, K_A. AS-сообщение содержит два объекта: ключ сеанса, K_A-TGS, который используется Алисой, чтобы войти в контакт с TGS, и билет для TGS, который зашифрован TGS-симметричным ключом (KAS-TGS). Алиса не знает K_A-AS, но когда сообщение прибывает, она печатает (сообщает) свой симметричный пароль. Пароль и соответствующий алгоритм вместе создают K_A-AS, если пароль правильный. Пароль затем немедленно уничтожают; его не передают по сети, и он не остается в терминале. Он используется только на мгновение, чтобы создать K_A-AS. Процесс теперь использует K_A-AS для того, чтобы расшифровывать передаваемое сообщение K_A-TGS и извлечь билет.
3. Алиса теперь передает три объекта TGS. Первый - билет, полученный от AS. Второй - имя реального сервера (Боб), третий - метку времени, которая зашифрована ключом K_A-TGS. Метка времени предотвращает ложный ответ Евы.
4. Теперь TGS передает два билета: каждый содержит ключ сеанса между Алисой и Бобом, K_A-B. Билет для Алисы - зашифрованный K_A-TGS , билет для Боба - зашифрованный с ключом Боба K_TGS-B. Обратите внимание, что Ева не может извлечь K_AB, потому что Ева не знает K_A-TGS или K_TGS-B.

   Она не может ответить на шаг 3, потому что она не может заменить метку времени новой меткой. Она не знает K_A-TGS, и даже если она будет действовать очень быстро и передаст на шаге 3 сообщение прежде, чем истечет метка времени, она все равно получит те же самые два билета, которые она не может расшифровать.
5. Алиса передает билет Боба с меткой времени, зашифрованной ключом K_A-B.
6. Боб подтверждает, что получил эту информацию, прибавляя 1 к метке времени. Сообщение шифруется ключом K_A-B и передается Алисе.

Использование различных серверов

Обратите внимание, что если Алиса должна быть обслужена различными серверами, то первые два шага проверяют идентификационный код Алисы и не повторяются. Повторяя шаги 3-6, Алиса может запросить, чтобы TGS выработал билеты для многих серверов.

Версия 5 Цербер

Незначительные отличия между версией 4 и версией 5 кратко приведены ниже.

1. Версия 5 имеет более длинный указатель времени жизни билета.
2. Версия 5 позволяет возобновлять билеты.
3. Версия 5 может применять любой алгоритм с симметричными ключами.
4. Версии 5 использует различные протоколы для того, чтобы описывать типы данных.
5. Версия 5 имеет большие заголовки, чем версия 4.

Области применения

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