Сообщения Kerberos версии 5

В Kerberos версии 5 используется пять сообщений (см. Рис. 22 -1):

6. Клиент-Kerberos: c,tgs

7. Kerberos-клиент: {K_c,tgs}K_c, {T_c,tgs}K_tgs

8. Клиент-TGS: {A_c,s}K_c,tgs{T_c,tgs} K_tgs,s

9. TGS-клиент: {K_c,s}K_c,tgs{T_c,s}K_s

10. Клиент-сервер: {A_c,s}K_c,s {T_c,s}K_s

Теперь рассмотрим использование этих сообщений подробно.

Получение первоначального мандата

У клиента есть часть информации, доказывающей его личность - его пароль. Понятно, что не хочется заставлять клиента передавать пароль по сети. Протокол Kerberos минимизирует вероятность компрометации пароля, но при этом не позволяет пользователю правильно идентифицировать себя, если он не знает пароля.

Клиент посылает сообщение, содержащее его имя и имя его сервера TGS на сервер проверки подлинности Kerberos. (может быть несколько серверов TGS.) На практике пользователь, скорее всего, просто вводит свое имя и программа входа в систему посылает запрос.

Сервер проверки подлинности Kerberos ищет данные о клиенте в своей базе данных. Если информация о клиенте есть в базе данных, Kerberos генерирует сеансовый ключ, который будет использоваться для обмена данными между клиентом и TGS. Он называется Мандатом на выделение мандата (Ticket Granting Ticket, TGT). Kerberos шифрует этот сеансовый ключ секретным ключом клиента. Затем он создает для клиента TGT, доказывающий подлинность клиента TGS, и шифрует его секретным ключом TGS. Сервер проверки подлинности посылает эти два зашифрованных сообщения клиенту.

Теперь клиент расшифровывает первое сообщение и получает сеансовый ключ. Секретный ключ является однонаправленной хэш-функцией клиентского пароля, поэтому у законного пользователя не будет никаких проблем. Самозванец не знает правильного пароля и, следовательно, не может расшифровать ответ сервера проверки подлинности. Доступ запрещается, и самозванный клиент не может получить мандат или сеансовый ключ.

Клиент сохраняет TGT и сеансовый ключ, стирая пароль и хэш-значение. Эта информация уничтожается для уменьшения вероятности компрометации. Если враг попытается скопировать память клиента, он получит только TGT и сеансовый ключ. Эти данные важны, но только на время жизни TGT. Когда срок действия TGT истечет, эти сведения станут бессмысленными. Теперь в течение времени жизни TGT клиент может доказывать TGS свою подлинность.

Получение серверных мандатов

Клиенту требуется получить отдельный мандат для каждой нужной ему услуги. TGS выделяет мандаты для отдельных серверов.

Когда клиенту нужен мандат, которого у него пока нет, он посылает запрос к TGS. (На практике программа, скорее всего, делает это автоматически и незаметно для пользователя.)

TGS, получив запрос, расшифровывает TGT своим секретным ключом. Затем TGS использует включенный в TGT сеансовый ключ, чтобы расшифровать удостоверение. Наконец TGS сравнивает информацию удостоверения с информацией мандата, сетевой адрес клиента с адресом отправителя запроса и метку времени с текущим временем. Если все совпадает, TGS разрешает выполнение запроса.

Проверка меток времени предполагает, что часы всех компьютеров синхронизированы, по крайней мере с точностью до нескольких минут. Если время, указанное в запросе, отстоит от текущего момента слишком далеко в прошлое или в будущее, TGS считает запрос попыткой повторения предыдущего запроса. TGS должна также отслеживать правильность сроков действия удостоверений, так как услуги сервера могут запрашиваться несколько раз последовательно с одним мандатом, но разными удостоверениями. Другой запрос с тем же мандатом и уже использованной меткой времени удостоверения будет отвергнут.

В ответ на правильный запрос TGS возвращает правильный мандат, который клиент может предъявить серверу. TGS также создает новый сеансовый ключ для клиента и сервера, зашифрованный сеансовым ключом, общим для клиента и TGS. Оба этих сообщения отправляются клиенту. Клиент расшифровывает сообщение и извлекает сеансовый ключ.