Аутентификация по протоколу Kerberos

Краткий обзор

В операционной системе Microsoft® Windows® 2000 аутентификация пользователей производится по умолчанию с помощью протокола Kerberos. Использование этого стандарта создает надежную основу для взаимодействия между различными платформами и при этом значительно повышает безопасность сетевой аутентификации.

В Windows 2000 применяется протокол Kerberos версии 5, дополненный расширениями, связанными с инфраструктурой открытых ключей. Безопасность системы обеспечивает клиент Kerberos с помощью интерфейса Security Support Provider Interface. Первоначальная проверка пользователя производится в рамках процесса Winlogon, которая обеспечивает единую регистрацию пользователей в системе. Центр распределения ключей Key Distribution Center (KDC) Kerberos интегрирован с другими службами безопасности Windows 2000, установленными на контроллере домена. Учетные записи безопасности хранятся в базе данных службы каталогов Active Directory.

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

Введение

Настоящий документ представляет технические аспекты реализации протокола аутентификации Kerberos 5 в операционной системе Microsoft® Windows® 2000. Здесь приводится подробное описание важнейших концепций, архитектурных элементов, а также функций аутентификации по протоколу Kerberos. Первый раздел «Обзор протокола Kerberos» предназначен тем, кто не знаком с этим протоколом. Последующие разделы посвящены более подробному описанию того, как Microsoft реализовала Kerberos в операционной системе Windows 2000. Завершается информационный документ кратким обсуждением вопросов взаимодействия описываемого протокола с другими реализациями Kerberos.

Аутентификация в Windows 2000

Windows 2000 поддерживает несколько протоколов, которые позволяют убедиться в том, что входящий в систему пользователь действительно имеет здесь свою учетную запись. Среди них – протоколы аутентификации удаленных подключений и протоколы аутентификации пользователей, входящих в сеть через Интернет. Однако внутри доменов Windows 2000 для проверки пользовательских данных предусмотрено два метода:

Компьютеры под управлением Windows 3.11, Windows 95, Windows 98 и Windows NT 4.0 смогут использовать протокол NTLM для сетевой аутентификации в доменах Windows 2000. Компьютерам же, работающим под управлением Windows 2000, этот протокол обеспечит аутентификацию на серверах Windows NT 4.0 и откроет доступ к ресурсам доменов Windows NT 4.0. Однако в тех случаях, когда есть выбор, в среде Windows 2000 по умолчанию будет использоваться протокол Kerberos 5.

Преимущества аутентификации по протоколу Kerberos

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

Стандарты аутентификации по протоколу Kerberos

Протокол Kerberos был создан в Массачусетском технологическом институте в рамках проекта Athena[1]. Однако общедоступным этот протокол стал лишь после появления версии 4. После того, как специалисты отрасли изучили новый протокол, его авторы разработали и предложили пользователям очередную версию – Kerberos 5, которая и была принята в качестве стандарта IETF. Реализация протокола в Windows 2000 выполнена в строгом соответствии с требованиями, изложенными в документе RFC 1510[2]. Кроме того, при ее разработке были использованы механизм и формат передачи контекстов безопасности в сообщениях Kerberos, описанные в спецификациях Интернета из документа RFC 1964[3].

Расширения протокола Kerberos

В Windows 2000 нашли применение расширения протокола Kerberos, упрощающие начальную аутентификацию клиентов. Обычно для этой цели используются секретные ключи, которыми должны заранее обменяться между собой участники сеанса, но теперь такую процедуру можно провести с помощью открытых ключей. Благодаря этому появилась возможность интерактивной регистрации пользователя с помощью микропроцессорных карточек. В основу расширений, обеспечивающих аутентификацию с открытым ключом, положена спецификация PKINIT.

Обзор протокола Kerberos

Протокол аутентификации Kerberos предлагает механизм взаимной идентификации клиента и сервера (или двух серверов) перед установлением связи между ними. В протоколе учтено, что начальный обмен информацией между клиентами и серверами происходит в открытой среде, а пакеты, передаваемые по каналам связи, могут быть перехвачены и модифицированы. Другими словами, протокол предназначен для работы в среде, которая очень напоминает сегодняшний Интернет. Здесь злоумышленник легко может имитировать запросы клиента или сервера, перехватывать связь между легитимными клиентами и серверами, даже искажать передаваемую информацию.

Основные концепции

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

Рассмотрим это на простом примере. Допустим, Алиса часто посылает сообщения Бобу, который использует содержащуюся в них информацию только тогда, когда полностью уверен, что она поступила именно от Алисы. Чтобы никто другой не смог подделать письма, они договорились о пароле, который пообещали никому больше не говорить. Если из сообщения можно будет заключить, что отправитель знает этот пароль, Боб может точно сказать: оно пришло от Алисы.

Теперь Бобу и Алисе остается только решить, каким образом показать свое знание пароля. Можно, скажем, просто включить его в текст сообщения, например, после подписи: «Alice, Our$ecret». Это было бы очень просто, удобно и надежно, если бы Алиса и Боб были уверены, что никто другой не читает их сообщений. Однако почта передается по сети, где работают и другие пользователи, а среди них есть Кэрол, которая очень любит подключать к сети свой анализатор пакетов в надежде выведать чьи-нибудь секреты. И становится совершенно ясно, что Алиса не может просто назвать пароль в тексте письма. Чтобы секрет оставался секретом, о нем нельзя говорить открыто, нужно найти способ только дать знать собеседнику, что он тебе известен.

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

Аутентификаторы

Простой протокол аутентификации с секретным ключом вступает в действие, когда кто-либо стучится в сетевую дверь и просит впустить его. Чтобы доказать свое право на вход, пользователь предъявляет аутентификатор (authenticator) в виде блока информации, зашифрованного с помощью секретного ключа. Содержание этого блока должно меняться при каждом последующем сеансе, в противном случае злоумышленник вполне может проникнуть в систему, воспользовавшись перехваченным сообщением. Получив аутентификатор, привратник расшифровывает его и проверяет полученную информацию, чтобы убедиться в успешности расшифрования. Если все прошло нормально, страж может быть уверен, что человеку, предъявившему аутентификатор, известен секретный ключ. А ведь этот ключ знают всего двое, причем один из них – сам привратник. Таким образом, он делает вывод, что пришелец действительно тот человек, за которого себя выдает.

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

А теперь вернемся к нашему примеру. Предположим, Алиса и Боб договорились: перед тем, как пересылать информацию между своими компьютерами, они с помощью известного только им двоим секретного ключа, будут проверять, кто находится на другом конце линии. В ситуации, когда Алиса играет роль осторожного гостя, а Боб – бдительного привратника, это будет выглядеть так.

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

2.    Боб получает сообщение и видит, что оно пришло от кого-то, кто называет себя Алисой. Он сразу же достает ключ, которым они с Алисой договорились шифровать аутентификатор, и, расшифровав второе поле, узнает время отправки сообщения.

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

Если же время оказывается в пределах допустимого отклонения, можно с большой долей уверенности предположить, что аутентификатор поступил именно от Алисы. Но Бобу этого мало, ему нужна полная уверенность. Ведь, рассуждает он, может быть и так: кто-то перехватил предыдущую попытку Алисы связаться со мной и теперь пытается воспользоваться ее аутентификатором. Впрочем, если на компьютере сохранились записи о времени аутентификаторов, поступивших от Алисы за последние пять минут, Боб может найти последний и отказаться от всех других сообщений, отправленных одновременно с ним или ранее. Но если второе поле свидетельствует, что сообщение ушло в сеть уже после отправки последнего аутентификатора Алисы, то и его автором вполне могла быть Алиса.

3.    Боб шифрует время из сообщения Алисы с помощью их общего ключа и включает его в собственное сообщение, которое направляет Алисе.

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

Алиса получает ответ Боба, расшифровывает его, а затем сравнивает полученный результат со временем, которое было указано в исходном аутентификаторе. Если эти данные совпадают, она может быть уверена, что ее аутентификатор дошел до того, кто знает их с Бобом секретный ключ. Этот человек смог расшифровать сообщение и извлечь из него информацию о времени. Поскольку ни она, ни Боб никому свой ключ не передавали, Алиса делает вывод, что именно Боб получил ее аутентификатор и ответил на него.

Рис. 1. Взаимная аутентификация (Алиса-Боб)

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

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

Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Кербер (или Цербер) – персонаж классической греческой мифологии. Этот свирепый пес о трех головах, по поверьям греков, охраняет врата подземного царства мертвых. Трем головам Кербера в протоколе Kerberos соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет так называемый центр распределения ключей Key Distribution Center  или, сокращенно, KDC.

KDC представляет собой службу, работающую на физически защищенном сервере. Она ведет базу данных с информацией об учетных записях всех главных абонентов безопасности (security principal) своей области (области Kerberos в сетях Windows 2000 соответствует домен, поэтому в дальнейшем мы будем применять именно этот привычный термин). Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Данный ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей. В большинстве практических реализаций протокола Kerberos долговременные ключи создаются на основе пароля пользователя.

Когда клиенту нужно обратиться к серверу, он, прежде всего, направляет запрос в центр KDC, который в ответ направляет каждому участнику предстоящего сеанса копии уникального сеансового ключа (session key), действующие в течение короткого времени. Назначение этих ключей – проведение аутентификации клиента и сервера. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера, а направляемая клиенту – долговременного ключа данного клиента.

Рис. 2. Управление ключами (в теории)

Теоретически, для выполнения функций доверенного посредника центру KDC достаточно направить сеансовые ключи непосредственно абонентам безопасности, как показано выше. Однако на практике реализовать такую схему чрезвычайно сложно. Прежде всего, серверу пришлось бы сохранять свою копию сеансового ключа в памяти до тех пор, пока клиент не свяжется с ним. А ведь сервер обслуживает не одного клиента, поэтому ему нужно хранить пароли всех клиентов, которые могут потребовать его внимания. В таких условиях управление ключами требует значительной затраты серверных ресурсов, что ограничивает масштабируемость системы. Нельзя забывать и о превратностях сетевого трафика. Они могут привести к тому, что запрос от клиента, уже получившего сеансовый пароль, поступит на сервер раньше, чем сообщение KDC с этим паролем. В результате серверу придется повременить с ответом до тех пор, пока он не получит свою копию сеансового пароля. То есть, нужно будет сохранить состояния сервера, а это накладывает на его ресурсы еще одно тяжкое бремя. Поэтому на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным. Ее описание приводится ниже.

Сеансовые билеты

В ответ на запрос клиента, который намерен подключиться к серверу, служба KDC направляет обе копии сеансового ключа клиенту, как показано на рис. 3. Сообщение, предназначенное клиенту, шифруется посредством долговременного ключа клиента, а сеансовый ключ для сервера вместе с информацией о клиенте вкладывается в блок данных, получивший название сеансового билета (session ticket). Затем сеансовый билет целиком шифруется с помощью долговременного ключа сервера, который знают только служба KDC и данный сервер. После этого вся ответственность за обработку билета, несущего в себе зашифрованный сеансовый ключ, возлагается на клиента, который должен доставить его на сервер.

Рис. 3. Управление ключами (на практике)

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

Получив ответ KDC, клиент извлекает из него сеансовый билет и свою копию сеансового ключа, которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативной памяти). Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение, состоящее из билета, который по-прежнему зашифрован с применением долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного посредством сеансового ключа. Этот билет в комбинации с аутентификатором как раз и составляет удостоверение, по которому сервер определяет «личность» клиента.

Рис. 4. Взаимная аутентификация (клиент-сервер)

Сервер, получив «удостоверение личности» клиента, с помощью своего секретного ключа расшифровывает сеансовый билет и извлекает из него сеансовый ключ, который затем использует для расшифрования аутентификатора клиента. Если все проходит нормально, делается заключение, что удостоверение клиента выдано доверенным посредником, то есть, службой KDC. Клиент может потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента и в таком виде пересылает ее клиенту в качестве собственного аутентификатора.

Одно из достоинств применения сеансовых билетов состоит в том, что серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений (credentials cache) клиента, который направляет билет на сервер каждый раз, когда хочет связаться с ним. Сервер, со своей стороны, получив от клиента билет, расшифровывает его и извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может просто стереть его из своей памяти.

Такой метод дает и еще одно преимущество: у клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые билеты можно использовать многократно. На случай же их хищения устанавливается срок годности билета, который KDC указывает в самой структуре данных. Это время определяется политикой Kerberos для конкретного домена. Обычно срок годности билетов не превышает восьми часов, то есть, стандартной продолжительности одного сеанса работы в сети. Когда пользователь отключается от нее, кэш-память удостоверений обнуляется, и все сеансовые билеты вместе с сеансовыми ключами уничтожаются.