8.7.4. Аутентификация при помощи протокола Kerberos
Во многих реально работающих системах (включая Windows 2000 и более поздние) применяется протокол аутентификации Kerberos, основанный на одном из вариантов протокола Нидхэма—Шредера. Он назван по имени трехглавого пса греческих мифов Кербера9, охранявшего выход из Аида. Кербер пропускал в Аид всякого, но не выпускал оттуда никого. Протокол Kerberos был разработан в Массачусетском технологическом институте для обеспечения пользователям рабочих станций надежного доступа к сетевым ресурсам. Его основное отличие от протокола Нидхэма—Шредера состоит в предположении о довольно хорошей синхронизации всех часов в сети. Было разработано несколько последовательных версий протокола. Версия V5 наиболее широко применяется в промышленности и описана в RFC 4120. От более ранней версии, V4, в конец концов отказались, после того как в ней были найдены серьезные недостатки (Yu и др., 2004). V5 улучшена по сравнению с V4 — есть много небольших изменений по отношению к протоколу и несколько улучшенных характеристик, например, она больше не опирается на устаревший DES. Дополнительную информацию см. в (Neumann и Ts'o (1994).
В работе протокола Kerberos, помимо рабочей (клиентской) станции Алисы, принимают участие еще три сервера:
1. Сервер аутентификации (AS, Authentication Server): проверяет личность пользователей при входе в сеть.
2. Сервер выдачи билетов (TGS, Ticket Granting Server): выдает «билеты, подтверждающие подлинность».
3. Боб, то есть сервер, предоставляющий услуги Алисе.
Сервер аутентификации AS аналогичен центру распространения ключей KDC в том, что у него есть общий секретный пароль для каждого пользователя. Работа сервера выдачи билетов TGS состоит в выдаче свидетельств, убеждающих другие серверы в том, что владелец билета действительно является тем, за кого он себя выдает.
Чтобы начать сеанс, Алиса усаживается за клавиатуру произвольной общедоступной рабочей станции и вводит свое имя и название TGS. Рабочая станция посылает введенное имя открытым текстом на сервер аутентификации, как показано на сообщении 1 рис. 8.38. Сервер аутентификации AS возвращает рабочей станции Алисы ключ сеанса и билет KTGS(A, KS, t) для сервера выдачи билетов TGS. Ключ сеанса зашифровывается секретным ключом Алисы, так чтобы только Алиса могла его расшифровать. Только после получения сообщения 2 рабочая станция запрашивает пароль Алисы, и никак не раньше. С помощью этого пароля формируется ключ KA, которым расшифровывается сообщение 2 и из него извлекается ключ сеанса. После расшифровки рабочая станция сразу же уничтожает хранящийся в ее памяти пароль. Если вместо Алисы на рабочей станции попытается зарегистрироваться Труди, введенный ею пароль окажется неверным, что будет обнаружено рабочей станцией, так как стандартная часть сообщения 2 окажется неверной.

Рис. 8.38. Работа протокола Kerberos V5
После регистрации в сети Алиса может сообщить рабочей станции, что она хочет вступить в контакт с файловым сервером, то есть Бобом. При этом рабочая станция посылает серверу выдачи билетов сообщение 3 с просьбой выдать билет для общения с Бобом. Ключевым элементом этого запроса является билет KTGS(A, KS, t), который зашифрован секретным ключом TGS-сервера и используется для подтверждения личности отправителя. Сервер выдачи билетов отвечает созданием ключа сеанса KAB, которым будут пользоваться Алиса и Боб. Он отправляет Алисе две версии этого ключа. Один ключ зашифрован ключом сеанса KS, поэтому Алиса может его прочитать. Второй ключ представляет собой еще один билет, который шифруется ключом Боба KB, что позволяет Бобу его прочитать.
Злоумышленник может скопировать сообщение 3 и попытаться использовать его снова, но ему помешает временной штамп t, отправляемый вместе с этим сообщением.
Злоумышленник не может заменить этот временной штамп на более новый, так как не знает ключа сеанса Kg, которым пользуется Алиса для общения с сервером выдачи билетов. Даже если злоумышленник очень быстро повторит сообщение 3, все равно, единственное, что он получит в ответ, это сообщение 4, которое он не смог расшифровать в первый раз и не сможет расшифровать и во второй раз.
После этого Алиса через новый билет может послать Бобу ключ KAB для установки сеанса с Бобом. Эти сообщения также содержат временные штампы. Сообщение 6, получаемое в ответ (в качестве возможной проверки), подтверждает, что Алиса говорит именно с Бобом, а не со злоумышленником.
Наконец, после этой серии обмена сообщениями Алиса сможет обмениваться с Бобом данными, используя ключ сеанса KAB. Если после этого Алиса решит, что ей необходим другой сервер, например Кэрол (Carol, C), она может просто послать серверу выдачи билетов сообщение, аналогичное третьему, заменив в нем B на C (то есть идентификатор Боба на идентификатор Кэрол). TGS мгновенно ответит сообщением, содержащим билет, зашифрованный ключом KC. Этот билет Алиса пошлет Кэрол, для которой он будет служить гарантией подлинности Алисы.
Достоинство этого протокола состоит в том, что теперь Алиса может получать защищенный доступ к любому серверу сети, и в то же время ее пароль ни разу не передавался по сети. В действительности, он только на несколько миллисекунд появлялся в ее рабочей станции. Однако обратите внимание, что каждый сервер выполняет свою собственную процедуру авторизации. Когда Алиса предъявляет свой билет Бобу, это всего лишь подтверждает Бобу подлинность предъявителя билета. К чему же Алиса может получить доступ на сервере, решает Боб.
Поскольку разработчики системы Kerberos не рассчитывали, что весь мир станет доверять одному-единственному серверу аутентификации, они обеспечили существование нескольких областей (realms), каждая из которых имеет свой собственный сервер аутентификации (AS) и сервер выдачи билетов (TGS). Чтобы получить билет для сервера, расположенного в удаленной области, Алиса должна запросить у своего TGа билет, который будет принят TGм удаленной области. Если удаленный TGр зарегистрировался на локальном TGе (так же, как это делают локальные серверы), локальный TGр выдаст Алисе билет, действительный на удаленном TGе. После этого она может получить у удаленного TGа билеты к серверам данной удаленной области. Обратите внимание, что для того, чтобы две стороны, расположенные в различных областях, могли установить друг с другом защищенный сеанс связи, каждая из сторон должна доверять TGу другой стороны. Иначе они просто не смогут работать вместе.
8.7.5. Аутентификация с помощью шифрования с открытым ключом
Взаимная аутентификация также может выполняться с помощью шифрования с открытым ключом. Для начала Алисе нужно получить открытый ключ Боба. Если инфраструктура PKI реализована на основе сервера каталогов, выдающего сертификаты на открытые ключи, Алиса может потребовать сертификат Боба, что показано в виде сообщения 1 на рис. 8.39. Ответ, содержащийся в сообщении 2, — это сертификат X.509 с открытым ключом Боба. Проверив корректность подписи, Алиса может отправить Бобу сообщение со своим идентификатором и нонсом.
Рис. 8.39. Взаимная идентификация с помощью открытого ключа
Когда Боб получает это сообщение, он не знает, пришло ли оно от Алисы или от Труди (злоумышленника), но он делает вид, что все в порядке и просит сервер каталогов выдать ему открытый ключ Алисы (сообщение 4). Вскоре он его получает (в сообщении 5). Затем он отсылает Алисе сообщение 6, содержащее случайное число Алисы Ra, свой собственный нонс RB и предлагаемый ключ сеанса KS. Алиса расшифровывает полученное сообщение 6 своим закрытым ключом. Она видит в нем свое случайное число RA и очень этому рада: это подтверждает, что сообщение пришло от Боба, так как у Труди не должно быть способа определить значение этого числа. Кроме того, случайное число RA свидетельствует о свежести этого сообщения. Алиса соглашается на установку сеанса, отправляя сообщение 7. Когда Боб видит свое случайное число RB, зашифрованное ключом сеанса, который он сам же сформировал, он понимает, что Алиса получила сообщение 6 и проверила значение RA. Боб счастлив и доволен.